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

91–100 of 153 posts

Re: Don't use JSON web tokens for sessions

#91

Post by DelaneyM »

dandelany wrote: post #84
DelaneyM wrote: post #77

Earlier quoted context omitted.

You include the time created in the object before signing, and invalidate based on that as a timeout.

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.

Re: Don't use JSON web tokens for sessions

#92

Post by beachy »

andrewstuart2 wrote: post #47

I'm not quite sure the author of the article has a solid grasp of JWT, or identity federation in general given that he compares JWT to cookies (it's more like SAML than anything else). I'd highly recommend giving the RFC [1] a once-over to see what the spec is really about. > The correct comparisons are "sessions vs. JWT" and "cookies vs. Local Storage". This is somewhat true, but flawed. The better comparison is "SA…

Agreed, SAML to JWT is an excellent comparison.

But IMO it is fair to say you can't invalidate JWTs.

More precisely, if you want the ability to invalidate individual JWTs (oops, John's been hacked), then you'll need some kind of per-request check against an authorization server. And if you're doing that, why bother with JWTs in the first place, rather than pack information into the token you might as well pull it from the auth server.

But there are several use cases where you want to - and can easily - invalidate an entire group of JWTs.

For example, we have multi-tenant apps, and it could be you want to invalidate all the JWTs for a single tenant (oops, Fred's Fruit Barn has been hacked). That can be done in different ways, the simplest being that all JWTs issued prior to some date are invalidated.

Re: Don't use JSON web tokens for sessions

#93

Post by slapresta »

chrisfosterelli wrote: post #20

I disagree with his argument that JSON web tokens are "less secure". He even quotes this: > The only way to retrieve data out of local storage is by using JavaScript, which means any attacker supplied JavaScript that passes the Content Security Policy can access and exfiltrate it. In my opinion, it is MUCH easier to get a CSRF vulnerability than it is to bypass the Content Security Policy. Unless you can get around t…

The crucial point is that XSS vulnerabilities are an application level issue. If you have an XSS vulnerability, your application is broken. Good development practices prevent XSS vulnerabilities.

Your application does not have a CSRF vulnerability; HTTP cookies have a CSRF vulnerability. Your application may depend on HTTP cookies, which exposes this vulnerability through your application. The so-called "CSRF protection" is a hack that patches a protocol vulnerability at the application level.

Re: Don't use JSON web tokens for sessions

#94

Post by seangrogg »

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…

I hit the database on requests - I keep their identity in the JWT but not their permissions. And if they're hitting a protected route (the only time their identity is necessary anyways) you best be sure I'm checking their canonical permissions.

Re: Don't use JSON web tokens for sessions

#95

Post by biznickman » 

  Somewhat related to this issue, and yet another potential security issue. Like in a cache, the data in a stateless token will eventually 'go stale', and no longer reflect the latest version of the data in your database.

  This can mean that a token contains some outdated information like an old website URL that somebody changed in their profile - but more seriously, it can also mean somebody has a token with a role of admin, even though you've just revoked their admin role.
Umm, if you are storing the roles of a user in a JWT token, I think you are doing things wrong. The point of the JWT token is not to store ALL information of a user. It's simply a way of identifying the user (their ID) and potentially offering an expiration on the token.

Personally, I use tokens to make authenticated API calls but the API still verifies that the user has the required roles to take the specified action. You can then request user data when they login at the same time the token is issued to reduce request volume and then cache any user data locally (should you not want to ping the API server for user data on every request).

Locally they may be displayed as an admin while the cache says so but on the API server, there's no way for them to make such requests if the role has been revoked.

The greatest flaw that this article assumes is that everybody loads their JWT tokens with all sorts of personal info. This is a horrible practice. While theoretically JWT tokens support this, it's by no means a best practice. In essence, he's arguing against an anti-pattern which is already a known anti-pattern.

Re: Don't use JSON web tokens for sessions

#96

Post by seangrogg »

dandelany wrote: post #84
DelaneyM wrote: post #77

Earlier quoted context omitted.

You include the time created in the object before signing, and invalidate based on that as a timeout.

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"…

> stateless (ie. no round trip to the database on every call)

AFAIK, Stateless is about independent request/response and not needing a server to retain session information through the course of multiple requests. It has nothing to do with whether or not you're checking a database to cross-reference credentials - and I wouldn't keep anything more than an ID/name in a JWT... ever.

https://en.wikipedia.org/wiki/Stateless_protocol

Re: Don't use JSON web tokens for sessions

#97

Post by alanh »

biznickman wrote: post #95

Somewhat related to this issue, and yet another potential security issue. Like in a cache, the data in a stateless token will eventually 'go stale', and no longer reflect the latest version of the data in your database. This can mean that a token contains some outdated information like an old website URL that somebody changed in their profile - but more seriously, it can also mean somebody has a token with a role of…

Please, for quotes, use a > and/or asterisks, but not a leading space. That triggers formatting that doesn’t wrap.

> This is much nicer

Re: Don't use JSON web tokens for sessions

#98

Post by numbsafari »

pbz wrote: post #85
numbsafari wrote: post #52

Earlier quoted context omitted.

Your first point is mostly dead on. I see a number of people stating that you cannot revoke a token, and it's simply not true. The approach I use is to replace the shared session store (which is large, grows linearly with your user base, and hard to sync across clusters if you need that) with a shared revocation list. The revocation list is small, easy to check, only contains IDs and a TTL, much less cumbersome to re…

The point of using a stateless token is that you don't have to hit a central server / service to verify each token. If you need to do that in order to check for revoked tokens (for each request) then that defeats the purpose. At that point you may as well just check the original token / key for validity. The difference in speed between checking for a token in the big pool (all tokens) vs the small pool (revoked token…

Sorry if that wasn't clear, but I absolutely agree you should use a distributed revocation list. As each request comes in, you need to check the list. But you do need to check the list, and you do need to distribute it widely.

Depending on your situation, managing a revocation list in memory at each edge node might be feasible, reducing the overhead of a network call to a per-cluster store, which is another advantage of using a short revocation list instead of a large session store that can't feasibly be shared like that.

(Edit: looking back at my comment, I shouldn't have said a "shared" revocation list, but a distributed one. Whoops!)

Re: Don't use JSON web tokens for sessions

#99

Post by cortesoft »

seangrogg wrote: post #94
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 hit the database on requests - I keep their identity in the JWT but not their permissions. And if they're hitting a protected route (the only time their identity is necessary anyways) you best be sure I'm checking their canonical permissions.

You might be, but many people use signed cookie sessions in order to avoid having to check the DB.

Re: Don't use JSON web tokens for sessions

#100

Post by necubi »

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 be random strings stored in a db, and they can be simply deleted on invalidation.

Post reply on HN