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

Stop using JWT for sessions (2016)

cryto.net

Post reply on HN
Print view View original

71–80 of 255 posts

Re: Stop using JWT for sessions (2016)

#71

Post by jehlakj »

drinchev wrote: post #11

Top reason for me always was : > You cannot invalidate individual JWT tokens And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecti…

Invalidation isn’t hard to do at all. Simply check every half an hour or so. It does slightly undermine the benefit if using jwt tokens, but it’s better than checking against a server for each request.

This is why it usually takes some websites 30-60min to completely revoke your password. This may be a concern for highly secure apps, but for most apps I think this will suffice.

Re: Stop using JWT for sessions (2016)

#72

Post by vegardx »

nine_k wrote: post #67
mschuster91 wrote: post #27

Earlier quoted context omitted.

Or, implement a "master token" scheme: have a long-lived master token, which is used only for generating short-lived (e.g. 5 min) tokens that are actually used for authentication/authorization at the API endpoint. User gets banned or privileges revoked? Fine, revoke the master token on the authentication server and after 5 minutes at the latest, the user is locked out as he cannot get new valid short-lived tokens. Se…

> Fine, revoke the master token This is exactly the ability which JWT lacks. You can, of course, combine a session ID (checked against a DB) with a short-lived token (stateless, with expiration time encoded). This will allow to only check the session against a DB if, say, more than 30 seconds has passed since the previous check. It helps with spiky traffic, and still allows to invalidate a session soon enough for pra…

And this reduces complexity of all backend systems, as they only have to deal with one mechanism for authentication and authorization.

Re: Stop using JWT for sessions (2016)

#73

Post by martin-adams »

mschuster91 wrote: post #27
tehlike wrote: post #14

Earlier quoted context omitted.

Not true. Encode a token and validate it against a constant, which you change in case of a compromise.

Or, implement a "master token" scheme: have a long-lived master token, which is used only for generating short-lived (e.g. 5 min) tokens that are actually used for authentication/authorization at the API endpoint. User gets banned or privileges revoked? Fine, revoke the master token on the authentication server and after 5 minutes at the latest, the user is locked out as he cannot get new valid short-lived tokens. Se…

>> Fine, revoke the master token on the authentication server and after 5 minutes at the latest

That might be fine for a lot of use cases. But anything that can steal money using that token and 5 minutes is a very long time indeed.

Re: Stop using JWT for sessions (2016)

#74

Post by justaaron »

justaaron wrote: post #6

what about setting a secure cookie with a jwt, and expiring it when you log-out? what is the utility in server-sessions? (aside from the ability to revoke it at any time from the server.)

so, what about a single-use token you exchange for another token (or not)?

Re: Stop using JWT for sessions (2016)

#75

Post by nbevans »

the_af wrote: post #62
nbevans wrote: post #36

JWT is an authentication token - it isn't session state. Session state changes during the lifetime of a session. Whereas the authentication token does not - other than for renewals. Overloading the authentication token to also store unrelated domain concepts such as shopping basket items is a gross abuse of its purpose. Given that generating a JWT token is computationally expensive I really doubt that many people are…

I think by payload they mean the JWT can "store" actual permissions. Not state such as a shopping cart, but a payload composed of permissions granted to this client to do this or that in this app.

Storing security claims i.e. permissions in the JWT token is a valid use. This isn't session state. Those permissions don't change, they are in fact cryptographically immutable, until the next renewal of the token. Whereas by definition "state" does change.

Re: Stop using JWT for sessions (2016)

#76

Post by yen223 »

deathanatos wrote: post #52
scient wrote: post #37

Earlier quoted context omitted.

Except cookies are quite literally perfect for that - set the expiration to 30 minutes from issuance and it will automatically be expired with inactivity. Or bumped on activity.

You shouldn't be trusting the client to expire your sessions for you. (That is, relying on a cookie's expiration to actually expire the session.) (Now, if you mean looking up a session token in a database and checking that for expiry, then yes, that works, but the only real difference between JWT and tokens then is the latter requiring a database query.)

The more important difference between JWT and tokens is that the former requires you to trust that your encryption mechanism is foolproof, whereas the latter doesn't.

Re: Stop using JWT for sessions (2016)

#77

Post by intothemild »

abledon wrote: post #68
drinchev wrote: post #11

Top reason for me always was : > You cannot invalidate individual JWT tokens And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecti…

How the heck did JWT get such a following with issues like these?

Because front-end engineers always fall for whatever cult is hyped right now.

They usually don’t understand the issues around the things they want to build, they do it because it’s cool and new, and don’t stop to ask or research anything.

Re: Stop using JWT for sessions (2016)

#78

Post by joshstrange »

anonymousJim12 wrote: post #15
tehlike wrote: post #14

Earlier quoted context omitted.

Not true. Encode a token and validate it against a constant, which you change in case of a compromise.

How do you encode it in such a way that you can invalidate individual tokens? How do you distribute that information among your services?

The way we do it is with a long lived JWT (LLJWT) and short lived jwt (SLJWT). Our LLJWT lasts for a long time (think years) and is only able to to request a SLJWT, it alone has no abilities. Inside the LLJWT we store a UUID that we also store in the DB. The SLJWT is only valid for 1hr (we are testing on bringing that down to like 10min or so) and when it expires you have to use the LLJWT to request a new SLJWT. If at anytime we determine that there is abuse going on or someone wants to "remotely sign out" of a device they can invalidate the LLJWT and the next time it is used to request a new SLJWT it will be rejected.

Re: Stop using JWT for sessions (2016)

#79

Post by SiempreViernes »

dperfect wrote: post #50
the_af wrote: post #44

Earlier quoted context omitted.

Doesn't the author cover this in their rebuttal ( http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo... ), "Your blacklisting/revocation server goes down, now what?". Everything from there goes to "Congratulations! You've just re-invented sessions (only with a less battle-tested implementation) and gained nothing in the process" (Sarcasm is from the author's post, not mine!)

I don’t think of JWT as a replacement for db lookups or storage, but they do provide a convenience in not having to store and manage all sessions in the database[1]. I’ve done it both ways, and as long as you’re careful about a few of the potential security issues with JWT (solve it once, put it in a reusable module), it actually does save a considerable amount of code and complexity on the server side. Also, in my c…

The author is pretty clearly comparing using jwts with using some framework provided session solution, not having you implement sessions from scratch.

So just use a session library with expiration implemented, don’t take one without and add it on yourself.

Re: Stop using JWT for sessions (2016)

#80

Post by caiob »

dpark wrote: post #39
caiob wrote: post #35

Earlier quoted context omitted.

Seriously?

I would like to know what you mean. “Invalidating the client” seems almost nonsensical since you don’t control the client.

You do control what clients (think client_id/secret) can use your APIs. Don't you? You figure it out from there.
Post reply on HN