34

I can't understand the reasoning for making the claims/payload of a JWT publicly visible after base64 decoding it.

Why?

It seems like it'd be much more useful to have it encrypted with the secret.

Can someone explain why, or in what situation, keeping this data public is useful?

Laiv
  • 14,283
  • 1
  • 31
  • 69
ineedhelp
  • 451
  • 1
  • 4
  • 5
  • when you write JWT, you probably mean JWS. Because JWE (which is also "subclass" of JWT) is actually encrypts it content. – Alexey Oct 26 '17 at 10:42

3 Answers3

33

You choose not to encrypt the payload for the same reasons that you choose not to encrypt anything else: the cost (however small it is) exceeds the benefit, and a lot of data simply doesn't need to be secured that way.

What you mostly need protection against is people tampering with the data so that the wrong record gets updated, or someone's checking account gets money in it that it's not supposed to have. The JSON Web Token's signature accomplishes that, because changing any part of the header/payload/signature combination invalidates the packet.

Note that you can still secure the packets at the Transport Layer by using SSL.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • Ah I see, so essentially JWT is a new CSRF token. Thanks for your explanation, it has cleared the confusion. – ineedhelp Apr 28 '15 at 21:37
  • 8
    No JWT isn't a new CSRF token. Those are 2 different things. – Ashley Dec 10 '16 at 03:02
  • @ash if the details of an operation are stored in the JWT and validated on the server, isn't the JWT essentially playing the role of CSRF prevention in that scenario? I understand the primary purpose of a vanilla JWT is authentication, that is very clear from this answer. I think I was imagining adding more data and accomplishing two things at once. – ineedhelp Mar 30 '17 at 06:26
  • @RobertHarvey, you are using JWT incorrectly. JST is an "umbrella" term for JWS and JWE. JWS is to authenticate, JWE is to encrypt. So "The purpose of a JSON Web Token is to authenticate" should be actually "JWS is to authenticate". – Alexey Oct 26 '17 at 10:40
  • @Alexey: I made a slight change in my answer to accomodate. – Robert Harvey Oct 26 '17 at 15:02
  • as alternative to securing by SSL/TLS, one can secure secure content by nested JWTs (JWS in JWT, see https://connect2id.com/products/nimbus-jose-jwt/examples/signed-and-encrypted-jwt), or JWE with authenticated encryption (e.g. using A256CBC_HS512 encryption method of JWE + direct JWE algorithm). – Alexey Oct 26 '17 at 15:37
5

The use of the term signature in the RFC is analogous to a digital signature in asymmetric cryptography. In asymmetric cryptography if the sender encrypts a message with their private key, anyone who has the message can decrypt it with the sender's public key. So the goal with the term signature isn't to keep a message secret, but to verify the integrity/sender of the message, that is hasn't been altered.

In the case of JWTs the sending system is both the creator and consumer of the message (see diagram below), and the goal is to make sure the token passed to the user wasn't tampered with (e.g. given elevated privileges).

And as @Robert mentioned, the JWTs can/should still be encrypted with TLS.

Here is a good explanation of JWTs and signatures from which the below image is sourced. 5 Easy Steps to Understanding JSON Web Tokens (JWT)

asdfasdf

belwood
  • 105
  • 4
Micah B.
  • 159
  • 1
  • 3
  • 2
    Link in answer is dead - *"410 Deleted by author."* – Pang Aug 03 '20 at 07:35
  • 1) The signature isn't "analogous to" a digital signature, it **is** a digital signature. 2) While it's sometimes true that "the sending system is both the creator and consumer", the diagram shows an example where that is **not** the case, with separate "Authentication" and "Application" servers. – IMSoP Mar 09 '21 at 14:05
2

To add to Robert Harveys answer, there is a significant disadvantage to encrypting the payload - it means that the recipient of the service needs share a secret with the authentication server (the encryption key) to understand whether or not the bearer of the token is authorised or not. In contrast anyone can validate a JWT using only the public key published by the authentication server.

This is a key part of the openid connect specification as it allows client applications to validate identity tokens issued by the auth server, it also makes it easier to deploy resource servers (as they don't need to be deployed with access to the secret encryption key) and also helps when trying to diagnose any problems with an issued JWT.

Justin
  • 1,728
  • 10
  • 16
  • You're trying to compare asymmetric and symmetric encryption mechanisms, jwt is an implementation of RSA encryption. – TheAnimatrix Jan 15 '19 at 20:59
  • 1
    @TheAnimatrix FWIW, you're _both_ making wrong assumptions: JWT (or, strictly, JWE) can use _various_ encryption algorithms, including both symmetric and asymmetric mechanisms. The initially standardised list is here: https://tools.ietf.org/html/rfc7518#section-4.1 – IMSoP Mar 09 '21 at 19:41
  • yeah it's been a couple years since my comment, agree to what you say now – TheAnimatrix Mar 14 '21 at 18:00