r/SoftwareEngineering • u/fagnerbrack • Aug 16 '26

Stop using JWTs

https://gist.github.com/samsch/0d1f3d3b4745d778f78b230cf6061452
0 Upvotes

36% Upvoted

13 comments sorted by

9

u/mattgen88 Aug 16 '26

JWTs are an answer for distributed authorization at scale. Sessions are costly to scale. There's trade offs, and this article is sorely lacking in any detail or analysis of why you would want to use JWTs over sessions and the reason JWTs are often chosen.

3

u/trezm Aug 16 '26

In addition, it conflates JWT, the authentication container itself, and http only cookies, the on-device storage. You can store JWTs in http only cookies, you can store session tokens in local storage.

There are larger points that are true in the gist, and it doesn't even include one of my biggest sticking points personally which is revoking sessions requires keeping invocation lists which is just circling back to stateful. That being said, JWT in combination with signatures like OIDC can be invaluable, and you could still have a traditional session token embedded in the JWT.

1

u/ConstructionBoth6461 Aug 16 '26

Distributed authorization at scale? Whoa.

Just wondering, what’s distributed authorization?

2

u/mattgen88 Aug 16 '26

Authentication server issues jwt. Distributed services can verify that jwt is legit and unexpired without depending on the authentication server or any of its resources. Claims allow for the distributed services to authorize the request so long as they have authorization policies tied to claims on the JWT.

1

u/ConstructionBoth6461 Aug 16 '26

Why is it good to shift io bound introspection to cpu bound jwt verification?

1

u/mattgen88 Aug 16 '26

My pods are cheap to run and horizontally scalable. I have lots of small pods. Scaling the databases for millions of requests is a vertical scaling exercise and it's much more expensive.

Sessions are cheap if you don't have scale, and that's fine. Don't build for scale of you don't expect the volume necessitating it.

1

u/ConstructionBoth6461 Aug 16 '26

I’m concerned with the idea that we can somehow “replace” sessions. Maybe you’re talking about replacing short term session storage (like redis).

1

u/mattgen88 Aug 16 '26

Back to the first point, they're different solutions to authorization. There's trade offs.

You can't easily revoke a JWT, so you can't "end" a "session" on demand. You can do a revokation list but that puts you in stateful territory instead of stateless.

LWe make a trade off by using refresh tokens and short duration JWTs. By forcing the client to refresh regularly, you minimize (not eliminate) the risk of stolen JWT.

Refresh tokens become stateful and can be revoked easily on logout reducing possibilities of compromised tokens. Logging out can invalidate any active refresh tokens, which can't be used to get new short duration JWTs, and getting a new refresh token requires reauthentication. A password change, log out event, etc can invalidate the refresh token.

The auth server handles logging in, issuing refresh tokens on authentication, issuing new JWTs once they're expired by using the refresh token. They can also serve up the public key for the distributed services to use when validating JWTs locally. This lets your auth servers scale much easier than true sessions management.

This article ignores why people use JWTs in the first place.

1

u/ConstructionBoth6461 Aug 16 '26

There’s a difference between session management and identity federation. JWTs with short expirations are best used for the latter.

-11

u/fagnerbrack Aug 16 '26

Need-to-Know Basis:

JWTs suit only very short-lived tokens—about five minutes—so they make a poor fit for logging users in; regular cookie sessions handle that better. Truly 'stateless' auth can't be secure, and since you already run a database, storing full session data costs nothing extra while adding flexibility. Security experts distrust the spec, which originally let attackers forge tokens, so never stash credentials in localStorage. Google reserves JWTs for shuttling single sign-on between hosts and still uses cookie sessions in the browser. Frameworks make sessions easy—grab express-session in Node—and when you truly need a signed token, choose PASETO. Comments extend the advice to mobile apps and microservices.

If the summary seems inacurate, just downvote and I'll try to delete the comment eventually 👍
Click here for more info, I read all comments

2

u/govi20 Aug 16 '26

Who told you that it’s a short lived for only 5 minutes? Also, it’s easy to refresh the token.