Just to be a little bit pedantic about the article. Do not contain any sensitive data in a JWT. If there's nothing sensitive in the JWT then why might we

Just to be a little bit pedantic about the article. Do not contain any sensitive data in a JWT. If there's nothing sensitive in the JWT then why might we encrypt it? Sometimes the whole purpose of a JWT is to pass some sensitive auth information whether as a session cookie or an authentication token that a service uses. If you worried about replay attacks, include a nonce (jti claim), expiration time (exp claim), and creation time (iat claim) in the claims This isn't always the case... One of the reasons JWT is so powerful is the asymmetric key operations built in to the spec. If some JWT generation and signing body signs a JWT and someone else steals the JWT, all consumer services of the signing service are vulnerable to a replay attack. The JWT is valid for use at ALL consumer services. If you have symmetric keys and are encrypting/signing a JWT to communicate, and you want to prevent replay attacks with a JTI and EXP, you've lost the stateless property of JWT in order to do it correctly, and you haven't solved the problem of using the JWTs at OTHER services. It only works for 1 to 1 communication. If you're preventing replay attacks inside of a JWT you've chose the wrong battle and you've decided to design a cryptographic protocol on top of JWTs. Don't pick this fight. Just go home. The secret signing key should only be accessible by the issuer and the consumer This won't be the case for asymmetric keys. Services that create JWTs and sign them for other services to verify should not share the private key with other services. This is basic crypto but if someone reads this ONLY this article they may not know.