[gusbremm]

Once I worked on a team that none of the engineers knew that jwt payload was readable on the frontend. They were in shock when I extracted the payload and started asking questions about the data structure.

[lmc]

It's kinda baffling that JWTs are unencrypted by default, to be fair.

[bpicolo]

It's the whole point - they're signed, not encrypted.

You should use opaque tokens instead if you don't want the frontend or other services that have access to the token to read it.

[lmc]

In many cases, the front end doesn't need to read the JWT, just pass it on to some API.

An encrypted JWT is still convenient as it can be decrypted and deserialized into a common data structure using existing libraries.

[bpicolo]

One benefit of JWT as specced is that those APIs you pass it on to don't need to share an encryption key, which makes rolling the key without causing downtime impractical. With OIDC, for example, frequent key rotation helps you create a better security posture.

The benefit of signing versus encryption is many services are able to verify the authenticity without needing a shared secret. That includes untrusted services, which is frequently the case with OAuth 2.

You can encrypt a JWT token, but at that point it's not semantically a JWT anymore. It can be any JSON at all and doesn't need to match the JWT structure. The first and last parts of a JWT are a signing algorithm and signature, respectively.

[mosdave]

I, for one, enjoy not needing to coordinate an encryption key between my service and my IdP.

[lmc]

I also enjoy not worrying about how the next field I add to my JWT can be exploited after a base64 decode :-)

[bornfreddy]

How else could frontend read them? If you don't need this then regular cookies are better.

[lmc]

It's the other way round - the front-end shouldn't need to read JWTs, just pass them on.

[mosdave]

if your frontend is interrogating the jwt you're doing it wrong

[nijave]

Isn't it pretty common to read the expiration so you know when to refresh tokens?

[bornfreddy]

It is, among other things like username or user e-mail address.

This is also, together with backend scalability, a major selling point for JWTs. Otherwise one might just as well use regular session ids in cookies.

[samhw]

I mean, I'd be rather surprised too. What were you using JWTs for, if not asymmetric crypto? Presumably you weren't using it to sign the tokens, if they were surprised the client could access them? And I can't see many contexts where you would use it with a shared secret, where just sending JSON over HTTPS wouldn't suffice. (I'm assuming 'frontend' here denotes a client on the other side of the trust boundary.)

[FlorianRappl]

I'm not getting your comment. The payload is not encrypted. I think you refer to the signature. The payload can always be decoded. It's just JSON into base64.

[samhw]

Ah, sorry, that was what I was referring to when I said "Presumably you weren't using it to sign the tokens, if they were surprised the client could access them?". I classed that as too obvious for it to be what you meant.

[chrisandchris]

For SSO? The biggest advantage (besides being stateless) about a JWT is that it is signed with an asymetric key and the client can validate the authenticity of the content. You can encrypt the content of the token, but that does not make to much sense (because the client anyway needs to decrypt it).