Hacker News Reader

Comment by csours | Hacker News Reader

We have a requirement that users be logged out after 30 minutes of inactivity, so JWTs are perfect for our use case.

Users may wish to log out sooner than 30 minutes too.

Except cookies are quite literally perfect for that - set the expiration to 30 minutes from issuance and it will automatically be expired with inactivity. Or bumped on activity.

You shouldn't be trusting the client to expire your sessions for you. (That is, relying on a cookie's expiration to actually expire the session.)

(Now, if you mean looking up a session token in a database and checking that for expiry, then yes, that works, but the only real difference between JWT and tokens then is the latter requiring a database query.)

The more important difference between JWT and tokens is that the former requires you to trust that your encryption mechanism is foolproof, whereas the latter doesn't.

Session tokens (an unguessable identifier that identifies server-side stored session data), while they don't need to be encrypted or signed, the identifier should usually be cryptographically random, however, so you can still get into trouble there.

JWTs don't have to be encrypted. (And IME, typically aren't.) They need to be signed, but the algorithms that do this are common, well-understood algorithms. Some of them are likely being used by TLS to protect your session anyways. If they're not foolproof, you have bigger issues than JWT.

If you are referring to the implementation, then sure, but the same concerns exist about your implementation of TLS, and the same advice applies: use a well-known, hopefully well tested library.

Cookies are implementation dependent. It's quite possible that a user agent doesn't honour what you instructed it to do regarding the expiration of a cookie.

JWT however... your server side can validate its own token in whatever ways it wants (including expiration). You can't get more secure than that.

If you checking the session on the server, you might as well just use a token in a cookie. The point of the JWT complexity is to avoid that.

JWT tokens being passed via cookies is a valid use case.

What about a stolen user password and an actor, who already uses your token? Can the targeted user kick him out by resetting his / her password?

Sure why not? Each user account has a counter or timestamp on it in the user registry. If the JWT token in the request passes crypto validation but it has an older counter/timestamp than held in the user registry then it is deemed invalid and the user must re-authenticate. This is still a horizontally scalable design.

Then you are back to statefulness if you need to check this magic "count" every request.

You can horizontally scale counters with CRDTs, specifically the G-Counter. Whereas it is harder to scale a (usually) opaque blob of application state a.k.a. session state.

This “user registry” of yours sounds an awful lot like a traditional session table in a central DB.

Could you elaborate a bit on that in terms of horizontal scalability please?

User registry can scaled however you want it to be. It is simply the service that manages user accounts, passwords, permissions, and of course issues the JWT tokens. Equally it can be a horizontally scaled micro service.

No, but that's 3 systems away upstream anyway - thus the 30 minute timeout.

Reply on news.ycombinator.com