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


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?

  • when you write JWT, you probably mean JWS. Because JWE (which is also "subclass" of JWT) is actually encrypts it content.
    – Alexey
    Commented Oct 26, 2017 at 10:42

3 Answers 3


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.

  • Ah I see, so essentially JWT is a new CSRF token. Thanks for your explanation, it has cleared the confusion.
    – ineedhelp
    Commented Apr 28, 2015 at 21:37
  • 8
    No JWT isn't a new CSRF token. Those are 2 different things.
    – Ashley
    Commented Dec 10, 2016 at 3: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
    Commented Mar 30, 2017 at 6: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
    Commented Oct 26, 2017 at 10:40
  • @Alexey: I made a slight change in my answer to accomodate. Commented Oct 26, 2017 at 15:02

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)


  • 2
    Link in answer is dead - "410 Deleted by author."
    – Pang
    Commented Aug 3, 2020 at 7: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
    Commented Mar 9, 2021 at 14:05

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.

  • You're trying to compare asymmetric and symmetric encryption mechanisms, jwt is an implementation of RSA encryption. Commented Jan 15, 2019 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: tools.ietf.org/html/rfc7518#section-4.1
    – IMSoP
    Commented Mar 9, 2021 at 19:41
  • yeah it's been a couple years since my comment, agree to what you say now Commented Mar 14, 2021 at 18:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.