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

131–140 of 153 posts

Re: Don't use JSON web tokens for sessions

#131

Post by merb »

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.

Eventually JWT has very little Roundtrips.

Our current Implementation is:

- Really short lived JWT of 1 minute - If the JWT is invalid and the user didn't do a request in the last minute it does query the database for a session token (we use session tokens and jwt). if the Token is inside the database/redis/ehcache/whatever the user gets still a new JWT token.

Actually we did that since we needed a "sane" way of revoking tokens fast but still keep the user logged in until the browser is closed.

We don't have a mobile client (yet) but I guess we try to do something like that, too. just not with a session. This works really well and mostly our users won't hang around for more than a minute and when they do its not a problem to have a single backend call.

Re: Don't use JSON web tokens for sessions

#132

Post by arnarbi »

luhn wrote: post #12

This articles doesn't acknowledge where JWTs really shine: Authentication across a cloud of services, esp. a microservice architecture. JWTs allow a session to be shared across all of the services without any shared state.

I don't really see what JWT got to do with it. It's just an encoding format, and whether you put session state in the token is orthogonal.

Re: Don't use JSON web tokens for sessions

#133

Post by SCHiM »

tptacek wrote: post #80
SCHiM wrote: post #67

Earlier quoted context omitted.

You are wrong. It does. It keeps your user's session from being trivially stolen. In practise this makes successfully executing attacks harder. It's not a _nice_ thing to have, it's essential. An example of this is an application that asks you to confirm after a POST or w/e. If your XSS vector is not in the new page, then you can't execute as an attacker automatically. Many, many, applications (not only on the web) i…

It does not. It is the difference between an exploit that yields a root password and one that yields a shell at uid=0. HttpOnly is almost totally cosmetic.

It's not the same, an XSS is not comparable to a shell for the exact reason I outlined above. And a session is not a password.

I'm probably coming over as too offensive, but you really really don't seem to know what you are even talking about. You are wrong wrong wrong.

Re: Don't use JSON web tokens for sessions

#134

Post by mstade »

rahkiin wrote: post #61
vladgur wrote: post #51

Ill chime in with my $0.02 * Inability to invalidate stateless JWT tokens can be more or less be remedied with a short expiration time of the token and a token refresh flow. If a token is only valid for 5 minutes, and you can only refresh the token during that 5 minute window, it greatly reduces the attack vector. If that risk is too high, you should easily implement state with the same Redis setup that author mentio…

If you give the tokens an expiration time of 5 minutes, the application either needs to auto-request a token every 4-5 minutes automatically using a JavaScript timer, or your session times out way too quickly. If you close the tab, you will be logged out within 5 minutes. That may not be desired in many applications.

You don't have to use a timer, you can also do it when you're about to use the token, or after the token has been rejected if you're so inclined. I.e. before you make a request you check the validity of the token and if it's not valid you refresh it; or if you don't do this validation you'd have to deal with the server rejecting your token, doing the refresh, and then trying the original request again.

Re: Don't use JSON web tokens for sessions

#135

Post by mstade »

Kiro wrote: post #10
rahkiin wrote: post #6

Earlier quoted context omitted.

You would do it by adding a Redis server that stores stateful sessions (mentioned in the article). I however disagree with most of the points made in the article, and use stateless JWT myself.

Wouldn't that violate the RESTfulness? I thought stateless was one of the criterias.

The stateless constraint is perhaps the most misunderstood part of REST. Fielding's dissertation states that in a REST system the messages (i.e. requests/responses) must be stateless, but clients and servers are free to keep whatever state they like. What is meant by stateless here is that you don't need additional state than what's described in the message in order to understand the message itself.

For example, a message that's missing the `Content-Type` header, but includes a body, should be rejected because you can't be sure of the body's content type. If you're expected to infer this information, in order to understand the message, the system isn't adhering to the stateless constraint.

Cookies that have session IDs, that are then parsed and mapped to state on the server side, aren't violating the stateless constraint of REST because the message contains all information necessary to understand the message itself.

Re: Don't use JSON web tokens for sessions

#136

Post by mstade »

ForHackernews wrote: post #121
low_key wrote: post #86

Earlier quoted context omitted.

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…

Can you explain this a little bit more? You keep a counter on the user object in the DB? What is the JWT buying you if you still have to hit the DB on every request?

Presumably you can keep counters like these on the server edges, and just push new values out to servers whenever things change, as opposed to query a DB every time. This wouldn't invalidate individual tokens however, but all tokens that have that counter value. It'd also mean there's a window where tokens can still be used while servers are being updated with the new value(s).

These are just some random and half-baked thoughts, I have no idea what OP does, but there are options to limit hitting backing DBs anyway.

Re: Don't use JSON web tokens for sessions

#137

Post by mstade »

EdSharkey wrote: post #16

So, if I'm reading the advice right, then ... * Using JWT for authorization, particularly for one-time use == GOOD * Using JWT to represent long-lived persistent session state == BAD and, always transmit your tokens in all directions over HTTPS. This seems like useful advice given all the reasons put forward. Do I understand correctly or did I miss anything?

Yeah, pretty much. JWT is a very good and useful spec, I think particularly in distributed systems, but it's no panacea.

Re: Don't use JSON web tokens for sessions

#138

Post by njknsdf »

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…

You can store the user info in the JWT so you don't need to hit the database to get user info every time. I usually just store an id in each issued token and store/remove it from redis or memory as needed for invalidating it.

Re: Don't use JSON web tokens for sessions

#139

Post by tptacek »

SCHiM wrote: post #133
tptacek wrote: post #80

Earlier quoted context omitted.

It does not. It is the difference between an exploit that yields a root password and one that yields a shell at uid=0. HttpOnly is almost totally cosmetic.

It's not the same, an XSS is not comparable to a shell for the exact reason I outlined above. And a session is not a password. I'm probably coming over as too offensive, but you really really don't seem to know what you are even talking about. You are wrong wrong wrong.

I'm pretty sure? I do know what I'm talking about here. Sorry. HttpOnly is a joke.

Re: Don't use JSON web tokens for sessions

#140

Post by zeveb »

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?

SPKI (RFC 2692/2693) solved this in 1999, with its timed CRLs. Exactly one CRL is valid for any given period of time: when a token (= certificate) is received, it is invalid if it is referenced in the CRL, and valid otherwise.

Post reply on HN