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?
1
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.
6
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
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.
3