Should jwt web token be encrypted?

Question

I was reading article on JWT web token as an access token that is being sent to the user. Some of it mentions that the web token should be able to be decoded by the user.

Does that mean it is bad practice to decrypt the entire web token? For example, suppose I return the following JWT web token where this piece of information can be decoded.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

However, I feel that I do not want to let user able to decode his/her access token, so I use another encryption algorithm to encrypt everything into another form as follows and pass back to user.

So, I would decrypt this new text when I get the access token in the server and decode it.

Is it recommended to do it this way, if I do not wish to expose some of the value available in claim (such as user id) to the user? If not, what are the alternatives?

Dorsey

If not encrypted (just signed), wouldn't it be a security vulnerability? With enough such tokens, wouldn't the the hashing be eventually compromised by doing a lot of try-fails? – Army

Vincent, what's the article you were reading? – Army

Answer 1

JWT (RFC7519) is just a compact way to safely transmit claims from an issuer to the audience over HTTP.

JWT can be:

• signed (JWS - RFC7515)
• encrypted (JWE - RFC7516)
• signed then encrypted (the whole JWS is the payload of the JWE)
• encrypted then signed (the whole JWE is the payload of the JWS)

Note that, whetever you do with tokens, one of the current security best practices is to validate all cryptographic operations.

It makes sense to encrypt a JWS if you want to keep sensitive information hidden from the bearer (client) or third parties.

The real questions are: does the audience support JWE? If yes, which algorithms are supported?

Sclerotomy

Third bullet is incorrect: it's recommended to sign-then-encrypt, but encrypt-then-sign is also possible. See tools.ietf.org/html/rfc7519#section-11.2 – Intertwine

You are right: even if it is not recommended, this order is not forbidden. I updated the answer accordingly. – Sclerotomy

The recommendation makes no sense discussing “ This prevents attacks in which the signature is stripped, leaving just an encrypted message”. This is a silly assertion because if your system is actually doing its job i.e. verifying signatures; I don’t see how this attack could work. A missing signature is invalid. – Bonitabonito

Thank you Sam. Your comment has been taken into account with a reference to the RFC8725 section 3.3. – Sclerotomy

Answer 2

JWT are "signed" and therefore its contents are protected from tampering: you cannot change its contents without invalidating them.

You can optionally "encrypt" the contents and therefore turn them visible only to issuer (the entity creating the token) and the consumer (the entity that is destined to use its contents after verification).

There's a standard for that: JWE

Lox

To put it simple, it is wrongful to encrypt the entire JWT so that the consumer do now know the content at all? What i mean here is to Encrypt the entire jwt token again with own algorithm instead of optionally encrypt the content. – Dorsey

It is not wrong. It might not always be necessary. Often, it is required if the information is sensitive. But that not always is the case. I would stick with standards. – Lox

I think the callout here, to be very clear for other visitors reading this, is that the JWT is protected from tampering by way of its signature, but the payload is still visible to anyone that gets hold of it. If you have sensitive data in that payload, then encrypting it might be a good idea. The challenge is that you need be sure that whichever system is receiving that token can decrypt that token if it needs to read the payload (e.g. claims) – Bellbottoms

Why would you have sensitive data in a JWT? That would scare me as a user. – Gustavogustavus

@DarrylWagonerWA1GON You can have sensitive data anywhere. The JWT is encrypted, and only the server can decrypt it. Suppose you have integrated with an OAUth provider for some automated tasks that don't require user interaction but do require a user's OAuth token. You can either encrypt the token and store it in the database using a master key for all users, or use the user's password, decrypt it when the user successfully authenticates, and store it in the ecnrypted JWT. – Ortega

Answer 3

A token contains user data and acts like a temp storage. It is not good to store sensitive data in a token.

At the first level, you should store the user name and maybe role or something like that. You should not include passwords, so it does not need to be encrypted. Nevertheless, you can encrypt it if you want.

Ronn

Answer 4

Yes, the best practice is use the JSON Web Encryption (JWE) RFC, the claims in the JWT after decode it are in plain text, so if the user lost the token, the sensitive information as email, username, access permissions can be visible and can be used as a the initial information of any attack.

Ikey

Where does it say that JWE is best practice, or that JWE is recommended? – Caudillo

Answer 5

JSON Web Token Best Current Practices, RFC 8725 highlights how to properly architect a JWT implementation from scratch, but there is no recommendation from an authoritative body such as IEEE, W3C, or IETF regarding whether or not one should encrypt the JWT payload.

Note: If you follow Google and Bing's web recommendations then you are responding over a secure transport, e.g., HTTPS.

In terms of nailing stateful information such as an access token to the stateless HTTP protocol, see cookies: Restrict access to cookies.

Provided you have implemented JWT properly, your signed JWT shall be considered ironclad, i.e., it is practically impossible as a matter of physics to forge the payload returned to the server.

Caudillo