Hacker News Reader

Comment by ridethebike | Hacker News Reader

Does JWT always imply statelessness?

We use JWT to send bunch of public claims around, one of which is session_id which refers to session in backend cache. Are we doing it wrong?

View on HN

https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-...

The benefit of JWT is only if you are using it in stateless manner. If you are storing a session_id which need to be verified for each call, you can as effectively reusing it as a normal session cookie, with unnecessary overhead and payload cost. JWT is useful only if you trust it.

This is something I’ve gotten into fights with coworkers over when I proposed doing a similar thing. It was a weird circular argument and I’m very curious if someone here has a better opinion than, “JWTs can’t store state because they’re stateless!”

Without offering an alternative solution I'm not sure what your co-workers are trying to accomplish.

The article doesn't offer much of a solution either.

The only valid criticism I see in these threads are unless you are tracking a revoke list then the JWT is still valid on a user initiated logout until it expires.

If you're going to roll your own tokens you're probably going to end up some form of tamper proof encryption even if you're storing additional session information on the backend.

Without specific comparison to other styles of session management this is just all FUD to me.

The whole point of a JWT is that it is stateless, and the information is (cryptographically signed) in the client. The advantages and disadvantages of JWT both derive from that.

If you want a session, just use an opaque session cookie. Then all information is safely handled in the server.

While it's certainly technically possible to use a JWT like a session cookie (or store session information in it), what you then get is a solution that combines the disadvantages of both approaches: All the complexity of making "visible" client-handled information safe, with the additional overhead of also having it in the server, while you loose the advantages of a JWT in integrating third-party services.

So, either use one, or use the other, depending on your requirements. Don't combine them.

Yes, you’re doing it wrong. You could store these “claims” in the same backend cache, keyed by the session_id.

But maybe it’s useful to have some metadata in the jwt as well that doesn’t need to be verified by the backend?

That's more or less what we ended up with. We could choose one the following two extremes:

a) Store sessionId as a cookie on the browser, pull all details on backend from cache server - requires network call every time when any tiny user detail is needed, not a showstopped and it worked for us for quite a while but we wanted something more convenient.

b) Fully stateless backend, keep entire session in JWT - our user's session is on the huge, plus user's session has private data (we declined this option rather quickly)

Instead we ended up with JWT which contains sessionId + bunch of most commonly accessed user properties (various identifiers, roles, login time, etc).

Now it seems like that somehow I missed this "JWT means stateless" thingy, well, let's see what people say.

So if a user’s role changes (e.g. some privileges are revoked), they can still act in their old role until their token expires? Sounds like you have a security issue. Which website is this again?

Privileges for doing anything serious (e.g. perform payments or change security preferences) are not stored in JWT, all checks done on server side. In case of emergency (e.g. we suspect user session has been taken over) we lock user account and purge session from the backend. Without session on backend - JWT won't do much.

It's a fintech consumer website (sorry, can't disclose the name).

A JWT still needs to be verified by the backend, it just doesn't need to do a database lookup to do so.

But if you're statefully storing sessions anyway...

Of course, trusting JWT without verifying it first would be madness

Sure, but that’s independent from the session_id, which has no place in the JWT.

Reply on news.ycombinator.com