It's critical to recognize JWTs are not encrypted. They are signed, which is what gives us the confidence to trust them, but the contents of JWTs are publicly readable by anyone. JWTs are like an ID card laminated with a hologram. Anyone can read the ID and anyone can print a fake, but we trust that only the issuer could include the hologram so we trust that the information on the card is correct, would be destroyed by modification, and do not need to call the issuer to obtain any information that is printed on the card.
Similarly, you should assume JWTs will become public at some point and never include sensitive information in JWTs. JWTs have a built-in expiration mechanism, which you should always use, so that the authorization granted by the JWT is not permanent.
The "overhead" touched on in the article is twofold:
If you have to talk to your authentication server with every single request, every server has to do a lot more work—your authentication server in particular.
More importantly, the complexity of needing to bake that authorization conversation into every single server, service, and request, means your system is more complicated to build and more sensitive to failures like your authentication server failing.
By using JWTs, you can make authentication a single tiny service that doesn't have to know anything about the rest of your system. Similarly, all of your other systems that need authentication do not need to know anything about your authentication service. All they need to know is that the JWT is valid; they do not care how the JWT was created or acquired.
That means less traffic with your authentication server, but, more importantly, it means far less code has to be written that is coupled to your specific authentication implementation.
There are use cases for both & use cases to Sign then Encrypt tokens. In cases where a client system generates an authentication token via API keys then a Signed token to the server system is appropriate. In the case of a Server passing a post authentication "session" token to a client where the client has no need to read the content it may be advisable to encrypt & sign, such that inadvertent leaks do not identify specific user accounts.
Agreed it is not advisable to put private info into a token, even if encrypted because perfect forward secrecy is unlikely to be maintained.
Oh, interesting. Though I did realize that you could encrypt the values in the payload, I somehow completely missed that encrypted JWTs were a thing that exists. That's for the knowledge bomb!
So, my mistake: JWTs can be encrypted, but you should probably still act like they aren't.
Potentially, there are good reasons not to encrypt JWTs. If your auth server only returns a JWT, then you might rely on information within the payload (such as a user ID) to make additional API requests. This is especially likely with REST APIs you might not control. For example, one API might require a user ID in a URL, but the signed JWT is the only way your code can obtain that user ID.
However, using JWT payload contents leaks implementation details into other parts of your system. If you have a choice in the design, it's a better practice to treat your JWTs as opaque, whether they're signed JWTs or encrypted JWTs. That is, your code shouldn't need to care if JWTs switch from signed to encrypted one day.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It's critical to recognize JWTs are not encrypted. They are signed, which is what gives us the confidence to trust them, but the contents of JWTs are publicly readable by anyone. JWTs are like an ID card laminated with a hologram. Anyone can read the ID and anyone can print a fake, but we trust that only the issuer could include the hologram so we trust that the information on the card is correct, would be destroyed by modification, and do not need to call the issuer to obtain any information that is printed on the card.
Similarly, you should assume JWTs will become public at some point and never include sensitive information in JWTs. JWTs have a built-in expiration mechanism, which you should always use, so that the authorization granted by the JWT is not permanent.
The "overhead" touched on in the article is twofold:
By using JWTs, you can make authentication a single tiny service that doesn't have to know anything about the rest of your system. Similarly, all of your other systems that need authentication do not need to know anything about your authentication service. All they need to know is that the JWT is valid; they do not care how the JWT was created or acquired.
That means less traffic with your authentication server, but, more importantly, it means far less code has to be written that is coupled to your specific authentication implementation.
Thank you for your knowledge sharing 🙏🏻
IMO, while true for many use cases this is not true in the published rfc:-
tools.ietf.org/html/rfc7516 - Defines Encrypted Tokens
tools.ietf.org/html/rfc7515 - Defines Signed Tokens
There are use cases for both & use cases to Sign then Encrypt tokens. In cases where a client system generates an authentication token via API keys then a Signed token to the server system is appropriate. In the case of a Server passing a post authentication "session" token to a client where the client has no need to read the content it may be advisable to encrypt & sign, such that inadvertent leaks do not identify specific user accounts.
Agreed it is not advisable to put private info into a token, even if encrypted because perfect forward secrecy is unlikely to be maintained.
Oh, interesting. Though I did realize that you could encrypt the values in the payload, I somehow completely missed that encrypted JWTs were a thing that exists. That's for the knowledge bomb!
So, my mistake: JWTs can be encrypted, but you should probably still act like they aren't.
Potentially, there are good reasons not to encrypt JWTs. If your auth server only returns a JWT, then you might rely on information within the payload (such as a user ID) to make additional API requests. This is especially likely with REST APIs you might not control. For example, one API might require a user ID in a URL, but the signed JWT is the only way your code can obtain that user ID.
However, using JWT payload contents leaks implementation details into other parts of your system. If you have a choice in the design, it's a better practice to treat your JWTs as opaque, whether they're signed JWTs or encrypted JWTs. That is, your code shouldn't need to care if JWTs switch from signed to encrypted one day.