Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't use JSON web tokens for sessions

cryto.net

Post reply on HN
Print view View original

101–110 of 153 posts

Re: Don't use JSON web tokens for sessions

#101

Post by numbsafari »

mwpmaybe wrote: post #65
merb wrote: post #64

Earlier quoted context omitted.

one way would be: - generate the salt - generate the jwt - use the header base64 string as the key for your database - store the salt with the header base64 as the key in your database maybe? just one idea, basically when you are > 100.000 users you barely invalidate a single token. mostly you would kill of your secret which will invalidate any token anyway. but there are numerous ways of doing so. Edit: to the poste…

Invalidating the site secret is my go-to strategy right now, but I have wondered how to sign out a single user across all their logged-in devices. Anyway, this idea is interesting and would be pretty straightforward to implement. Thanks!

The point is to avoid all the database updates. So, I would recommend not going that route.

If you need to sign out a user across all logged-in sessions, use a revocation list based on UID, rather than token-id.

Re: Don't use JSON web tokens for sessions

#102

Post by numbsafari »

mwpmaybe wrote: post #56
numbsafari wrote: post #50

Earlier quoted context omitted.

You can (and should) use a revocation list. This is really no different than doing invalidation/revocation of stored sessions because you have the same job of sending the session/token ID out to all dependencies. But, instead of keeping a giant memory store of all sessions in sync across clusters, you only have to keep a short lived list of revoked tokens. Less noise, less memory, same difference.

What does the revocation list look like? "Reject all tokens for user X issued before timestamp Y?" Or do you assign UUIDs to your tokens?

I assign a unique ID for each token (the `jti` claim). So each token has a unique identifier and can be invalidated that way, and every token has the user's ID (the `sub` claim), and can be invalidated that way, if that fits your use case.

Re: Don't use JSON web tokens for sessions

#103

Post by [deleted] »

numbsafari wrote: post #102
mwpmaybe wrote: post #56

Earlier quoted context omitted.

What does the revocation list look like? "Reject all tokens for user X issued before timestamp Y?" Or do you assign UUIDs to your tokens?

I assign a unique ID for each token (the `jti` claim). So each token has a unique identifier and can be invalidated that way, and every token has the user's ID (the `sub` claim), and can be invalidated that way, if that fits your use case.

[deleted]

Re: Don't use JSON web tokens for sessions

#104

Post by cortesoft »

This part:

"In practice, however, it's fairly trivial to replace the session mechanism at a later point, with the only cost being logging out every user once, when you make the transition."

Is not true in terms of needing to log everyone out once. It is pretty easy to write transition code, to accept the old style session and return the new style. You might not be able to transition everyone (if they don't use the session in the time you have your conversion code running), but you will get MOST people, and certainly most active users.

Re: Don't use JSON web tokens for sessions

#105

Post by homakov »

>You are essentially powerless, and cannot 'kill' a session without building complex (and stateful!) infrastructure to explicitly detect and reject them, defeating the entire point of using stateless JWT tokens to begin with.

just autoincrement nonce=123 and revoke it any time. Nothing complex about it.

>it can also mean somebody has a token with a role of admin, even though you've just revoked their admin role.

nobody stores user mode in session, that's what DB for.

>but without the battle-tested implementations.

"I don't know what's wrong but I'm kinda afraid to try".

Best argument so far is that it's indeed longer.

Bottom line: Use JWT for sessions, they are awesome! In Rails we're using similar mechanism for years already.

Re: Don't use JSON web tokens for sessions

#107

Post by homakov »

mythz wrote: post #70

This article seems opinionated without much substance and I disagree with many of the points listed. It also doesn't address using a JWT Token in a Cookie for Web Apps as recommended at: https://stormpath.com/blog/where-to-store-your-jwts-cookies-... And ignores usage of refresh tokens: https://auth0.com/docs/refresh-token Easier to use JWT's are simpler when your System is composed of multiple Services as only a sin…

What's refresh token for?

Re: Don't use JSON web tokens for sessions

#108

Post by kelson »

NathanKP wrote: post #83
tym0 wrote: post #76

Earlier quoted context omitted.

Wait. You have individual salt for each user that you store in your DB?

More than that. A salt for each "session". Each JWT contains two pieces of info: user ID, and salt. This stops the JWT from being a deterministic token that is always the same each time a token is generated for a specific user. It also allows invalidation. On each request a middleware checks validity of the salt from the JWT. A Redis cache layer here makes this a 1-2ms operation and easy to scale. If you need to inva…

Salt is random data used to cryptographically sign or encrypt data. It sounds like your JWT consists of a userID and a sessionID (stored in Redis).

Why not just store your sessionID in a cryptographically signed HttpOnly cookie? In most use cases, it'd be less ambiguous, better protected from JS attacks, and equal-or-less vulnerable to CSRF.

https://en.wikipedia.org/wiki/Salt_(cryptography)

Re: Don't use JSON web tokens for sessions

#109

Post by kelson »

homakov wrote: post #105

>You are essentially powerless, and cannot 'kill' a session without building complex (and stateful!) infrastructure to explicitly detect and reject them, defeating the entire point of using stateless JWT tokens to begin with. just autoincrement nonce=123 and revoke it any time. Nothing complex about it. >it can also mean somebody has a token with a role of admin, even though you've just revoked their admin role. nobo…

> just autoincrement nonce=123 and revoke it any time.

Does that revoke all tokens (shared "nonce") or update the token on next authentication? Would this "nonce" be stored in the database?

> nobody stores user mode in session

That's optimistic: https://github.com/akagadovskiy/ng-admin-jwt-auth/blob/maste...

> > but without the battle-tested implementations. > "I don't know what's wrong but I'm kinda afraid to try".

Battle-tested implementations have dealt with (at least some of) these threats previously. New approaches often miss the lessons of past efforts, leaving themselves vulnerable to old attacks.

Re: Don't use JSON web tokens for sessions

#110

Post by gcommer »

DelaneyM wrote: post #91
dandelany wrote: post #84

Earlier quoted context omitted.

Sure, but that's expiration , not invalidation , ie. we're talking about the ability to declare "this particular token is invalid now ". Incidentally, this limitation isn't too surprising to me... Is there any possible token-based authentication scheme that is both stateless (ie. no round trip to the database on every call) AND invalidate-able? Seems like any form of invalidation would require storing the "is valid"…

> Is there any possible token-based authentication scheme that is both stateless (ie. no round trip to the database on every call) AND invalidate-able? I suspect this is provably impossible. There are all sorts of things you can do at the protocol/platform level if you have a shared secret, but with only the constraints of an open authentication scheme you lack the tools to do this.

If you're willing to delve into the fun world of CRLs you can sorta do it. This isn't truly stateless of course, but for some design constraints it could be "practically" stateless since you're eliminating auth server round trips, which is probably why you were aiming for statelessness in the first place.

CRLs of course introduce lots of replication complexity and timing bounds to consider, and you probably want to pair them with short lived tokens to keep the CRL size manageable. (and then delve into refresh tokens)

As the OP points at, you most likely don't need any of this.

Post reply on HN