Stop using JWT for sessions (2016) • Hacker News Board

Re: Stop using JWT for sessions (2016)

#251

Post by nbevans » Fri, Nov 02, 2018, 1:13 PM UTC

aaaaaaaaaab wrote: post #156

nbevans wrote: post #55

Earlier quoted context omitted.

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.

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.

Re: Stop using JWT for sessions (2016)

#252

Post by nbevans » Fri, Nov 02, 2018, 1:14 PM UTC

gravypod wrote: post #65

nbevans wrote: post #55

Earlier quoted context omitted.

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.

Re: Stop using JWT for sessions (2016)

#253

Post by nbevans » Fri, Nov 02, 2018, 1:16 PM UTC

icebraining wrote: post #149

nbevans wrote: post #58

Earlier quoted context omitted.

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.

Re: Stop using JWT for sessions (2016)

#254

Post by jcadam » Fri, Nov 02, 2018, 1:25 PM UTC

wheresvic1 wrote: post #236

jcadam wrote: post #114

I use JWT for authentication on my current project. And I eventually ended up having to check the user's 'role' in the database for authorization before I let them do anything anyway (and consequently, revoking someone's user role or suspending their account has immediate effect). I saw many examples on the net of people putting role/authorization and various other types of session information within the JWT and it j…

> I saw many examples on the net of people putting role/authorization and various other types of session information within the JWT and it just looked insane to me. Why is this crazy? If you encrypt your JWT with a private key that is only known to the server, then any modification to the JWT will lead to an invalid token. The only thing here is that the list of roles granted is visible to the user if they were to de…

I suppose it depends on the application. I wanted to be able to revoke a user's permissions and not have to wait until token expiration for them to be locked out.

Re: Stop using JWT for sessions (2016)

#255

Post by finder83 » Fri, Nov 02, 2018, 3:53 PM UTC

anon1252 wrote: post #197

redbeard0x0a wrote: post #130

Earlier quoted context omitted.

Traversing a list of 100,000 users/sessions in a db to pull up the session is a different beast compared to traversing an in memory list of 10-100 revoked JTIs in redis. It is a lot less data to store and optimize (the full session vs. a small list of revoked JTIs)

> Traversing a list of 100,000 users/sessions in a db to pull up the session is a different beast compared to traversing an in memory list of 10-100 revoked JTIs in redis. It is a lot less data to store and optimize (the full session vs. a small list of revoked JTIs) I don't see why one can't use redis to persist sessions at first place and why your list of revoked token would be limited to 100.

It does depend on how many users you have and your TTL for the JWT, but if you have a 10 minute time to live, you only need to store the revocations for 10 minutes in redis since otherwise the tokens themselves expire. (Just an example, sub 10 minutes with 24 hours or whatever)