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

61–70 of 255 posts

Re: Stop using JWT for sessions (2016)

#61

Post by vegardx »

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…

The reality is that hardly anything needs to be instant. You're powerless in the time period that you're setting.

You don't need to have Reddit-scale traffic to have to consider this, but when you deal with a lot of backend systems it can reduce complexity a lot.

Re: Stop using JWT for sessions (2016)

#62

Post by the_af »

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.

Re: Stop using JWT for sessions (2016)

#63

Post by [deleted] »

scient wrote: post #41
jesseb wrote: post #23

From my time browsing HN, the consensus seems to be "don't use JWTs". What is the preferred method of client authentication for simple APIs these days?

OAuth access tokens? The difference being that JWTs contain information directly, as well as an access token to hit any APIs, while an access token contains no information on its own - thus solving the revocation issue. Now I don't think anyone really uses JWTs for API authentication, or they should not at least. APIs should still be gated by access tokens.

[deleted]

Re: Stop using JWT for sessions (2016)

#64

Post by jrochkind1 »

tehlike wrote: post #24
lvh wrote: post #16

Earlier quoted context omitted.

So you're saying you can have sane sessions as long as you have some server-side storage? :-)

Yes, of course, jwt can facilitate that. Using it as a replacement is not good, i agree.

But what value is it adding over ordinary 'bearer token' sessions in that case?

Re: Stop using JWT for sessions (2016)

#65

Post by gravypod »

nbevans wrote: post #55
drinchev wrote: post #9

Earlier quoted context omitted.

What about a stolen user password and an actor, who already uses your token? Can the targeted user kick him out by resetting his / her password?

Sure why not? Each user account has a counter or timestamp on it in the user registry. If the JWT token in the request passes crypto validation but it has an older counter/timestamp than held in the user registry then it is deemed invalid and the user must re-authenticate. This is still a horizontally scalable design.

Then you are back to statefulness if you need to check this magic "count" every request.

Re: Stop using JWT for sessions (2016)

#67

Post by nine_k »

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

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 practical reasons.

Re: Stop using JWT for sessions (2016)

#68

Post by abledon »

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?

Re: Stop using JWT for sessions (2016)

#69

Post by nine_k »

indeyets wrote: post #29

It's an interesting reading (together with second part), but should be taken with a grain of salt. Stateless sessions are useful under load and not necessarily under reddit-size load. I like 2-layered setup actually with long-expiration (1 year) "session" cookie kept on `auth.example.com` domain and short-lived (1 hour) JWT-cookie kept on `example.com` domain. JWT can optionally include permission for dangerous opera…

I generally agree, but to me "short-lived" would be below a minute. The point of the short-lived token is to make many clustered requests (as when a page loads a lot of assets) cheap because you only need to check a token. Any other human interaction, which takes longer, should go through the server-persisted session logic.

Re: Stop using JWT for sessions (2016)

#70

Post by enraged_camel »

drinchev wrote: post #51
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.

What's the point of having a token if you need to check it with a database on every request? Instead of `SELECT isValid from tokens where token=" "`, why not `SELECT user from sessions where session=" "`?

Exactly, the moment you add statefulness you've basically reinvented session authentication.
Post reply on HN