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

111–120 of 153 posts

Re: Don't use JSON web tokens for sessions

#111

Post by mcherm »

lynndylanhurley wrote: post #69
merb wrote: post #39

You cannot invalidate JWT tokens This is simple not true. You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it. They are less secure Compared to what? Actually JWT will have the same secureness like Bearer Tokens or Cookies, wherever you store it, its not `less` secure. Horrible article points here. They are less secure They take the same amount of s…

You cannot invalidate JWT tokens This is simple not true. You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it. I think one of the benefits of some (most?) JWT implementations is that it doesn't hit the database on every request - the token is only validated against a global secret. So you can't invalidate a single user's session without invalidating…

Yes you can. The system I built uses a revocation list (propagated to all servers in the cluster) to invalidate the session.

Just as if you were storing state on the server, it still requires a means of propagating the user's state to every server. But we only need to propagate a single ID once per session (at logout) instead of propagating all the session data to all the servers on every request.

Re: Don't use JSON web tokens for sessions

#112

Post by mwpmaybe »

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.

I read this wrong the first time. That makes sense. Thank you.

Re: Don't use JSON web tokens for sessions

#113

Post by brndn »

mcherm wrote: post #111
lynndylanhurley wrote: post #69

Earlier quoted context omitted.

You cannot invalidate JWT tokens This is simple not true. You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it. I think one of the benefits of some (most?) JWT implementations is that it doesn't hit the database on every request - the token is only validated against a global secret. So you can't invalidate a single user's session without invalidating…

Yes you can. The system I built uses a revocation list (propagated to all servers in the cluster) to invalidate the session. Just as if you were storing state on the server, it still requires a means of propagating the user's state to every server. But we only need to propagate a single ID once per session (at logout) instead of propagating all the session data to all the servers on every request.

Out of curiosity, how are you propagating the IDs to other systems in the cluster? I am building something which could benefit from pushing config data across a cluster.

Re: Don't use JSON web tokens for sessions

#114

Post by sb8244 »

mcherm wrote: post #111
lynndylanhurley wrote: post #69

Earlier quoted context omitted.

You cannot invalidate JWT tokens This is simple not true. You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it. I think one of the benefits of some (most?) JWT implementations is that it doesn't hit the database on every request - the token is only validated against a global secret. So you can't invalidate a single user's session without invalidating…

Yes you can. The system I built uses a revocation list (propagated to all servers in the cluster) to invalidate the session. Just as if you were storing state on the server, it still requires a means of propagating the user's state to every server. But we only need to propagate a single ID once per session (at logout) instead of propagating all the session data to all the servers on every request.

Do you ever worry that, in the case of failure or some other event, your revocation list could be lost and allow old hacked sessions to be used?

Is there a way around this? I like the idea of a revocation list, but this seems to be a pretty big concern.

Re: Don't use JSON web tokens for sessions

#115

Post by Negative1 »

This article is deeply troubling from a factual standpoint and I hope people do more research when considering JWT.

Points; 1) His terms are confusing and just plain wrong. Backwards even. For example, he calls storing an id in the token and session data server-side as stateful. That is incorrect; there is no state stored on the client, it is all server-side. That is by definition a stateless session token. 2) A lot of his claims of why people recommend JWT are unsubstantiated and frankly, I've never heard them before (like JWT is better for mobile... what)? Maybe I would feel better if he provided references but a lot of those points are just plain misinformed (or imo, made up). 3) "You will not need stateless sessions" is like saying O(n) performance is usually good enough. Well ok, until it isn't. Don't assume some worst case performance on your site won't occur. Build defensively, knowing where you might have a bottleneck (DB I/O for instance). It's not just 'future proofing". It's good engineering, damnit. 4) It's hard? Give me a break. 5) It's inflexible? You can store an entire JSON object in a JWT. That is incredible flexibility. 6) It's not that secure (whereas cookies in his opinion are)? This is just blatantly false.

Ok, I'm tired of debunking this article. Plain and simple, this article is not just misinformed but dangerously wrong. I appreciate Sven trying to share his insight with the community of developers but most of what he says is wrong.

I use JWT for stateless session management backed by some clever database optimizations (at least I like to think so). If you want to know more ask, but please, do not use this article to guide your decision on whether to use JWT (or a similar secure token scheme).

Re: Don't use JSON web tokens for sessions

#116

Post by homakov »

kelson wrote: post #109
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".…

> Would this "nonce" in the database?

Only in revoked list=1,2,5,7 etc. Unlike storing all sessions, you only store revoked integers which takes way less space and achieves same revocation you wanted.

> That's optimistic

Nobody should store

> leaving themselves vulnerable to old attacks

Every new line of code is probably a vulnerability. That's life. BTW JWT indeed had some super stupid bug with alg=NONE before, and I would simply throw away "header" from JWT

Re: Don't use JSON web tokens for sessions

#117

Post by zeckalpha »

necubi wrote: post #100
merb wrote: post #39

You cannot invalidate JWT tokens This is simple not true. You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it. They are less secure Compared to what? Actually JWT will have the same secureness like Bearer Tokens or Cookies, wherever you store it, its not `less` secure. Horrible article points here. They are less secure They take the same amount of s…

There are two common mechanisms for invalidating tokens: * Store the invalidated tokens in some fast store, in memory store and check that before accepting tokens. * Have auth tokens be very short lived (e.g., 1 minute) and require the use of a "refresh token" to get a new auth token when it's expired. This is the mechanism used by OAuth 2 (which strangely is never mentioned in the article). The refresh tokens should…

The second one is recommended by the article. They are differentiating between session and auth tokens, however.

Re: Don't use JSON web tokens for sessions

#118

Post by RhodesianHunter »

sb8244 wrote: post #114
mcherm wrote: post #111

Earlier quoted context omitted.

Yes you can. The system I built uses a revocation list (propagated to all servers in the cluster) to invalidate the session. Just as if you were storing state on the server, it still requires a means of propagating the user's state to every server. But we only need to propagate a single ID once per session (at logout) instead of propagating all the session data to all the servers on every request.

Do you ever worry that, in the case of failure or some other event, your revocation list could be lost and allow old hacked sessions to be used? Is there a way around this? I like the idea of a revocation list, but this seems to be a pretty big concern.

"old hacked sessions to be used"

JWTs generally contain an expiration timestamp.

Re: Don't use JSON web tokens for sessions

#119

Post by snikch »

low_key wrote: post #86
lynndylanhurley wrote: post #69

Earlier quoted context omitted.

You cannot invalidate JWT tokens This is simple not true. You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it. I think one of the benefits of some (most?) JWT implementations is that it doesn't hit the database on every request - the token is only validated against a global secret. So you can't invalidate a single user's session without invalidating…

I keep a counter in the JWT to at least mostly get around this issue. When processing a request, the counter is checked for the user, which isn't a big deal since all of the requests already require looking up the user. A counter increment invalidates all of that user's existing tokens. If a user changes their password, their roles change, etc, then the counter gets incremented so all tokens issued up to that point w…

Yep ^ This is what I often do too. Simple, but effective.

Re: Don't use JSON web tokens for sessions

#120

Post by sk5t »

brndn wrote: post #113
mcherm wrote: post #111

Earlier quoted context omitted.

Yes you can. The system I built uses a revocation list (propagated to all servers in the cluster) to invalidate the session. Just as if you were storing state on the server, it still requires a means of propagating the user's state to every server. But we only need to propagate a single ID once per session (at logout) instead of propagating all the session data to all the servers on every request.

Out of curiosity, how are you propagating the IDs to other systems in the cluster? I am building something which could benefit from pushing config data across a cluster.

In most cases it shouldn't matter; revocation lists ought to be trimmed to the lifetime of the issued tokens--when they are used at all, revoking a JWT rather than just letting it expire is likely not extremely common--so you could stuff them anywhere at all that is convenient to your other technology selections.
Post reply on HN