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

Stop Using JWTs

gist.github.com

Post reply on HN
Print view View original

51–60 of 335 posts

Re: Stop Using JWTs

#51

Post by littlecranky67 »

vidarh wrote: post #46
littlecranky67 wrote: post #40

In sessions vs. JWT revocation lists, there is an argument in favor of JWT revocation lists. JWTs have a limited expiry timestamp, so you only ever need to maintain a revocation list for tokens not expired yet. Given that you probably only have a fraction of JWTs revoked compare to valid JWTs in circulation, you only need to query a very small dataset for each request. When using sessions, your list of valid sessions…

The moment you have to look up the user object, you've lost the primary advantage of JWT, and might as well ditch it.

Depends on the system. If you use JWTs for authentication only, they still serve a purpose. Sessions also only serve as authentication, not authorization. Authorization is independent of the both systems, and it depends how you implement that.

There are systems where the authorization is done in the JWT too (i.e. scopes/permissions in the token) - in that case you are right.

Re: Stop Using JWTs

#52

Post by hparadiz »

tracker1 wrote: post #48
hparadiz wrote: post #21

Earlier quoted context omitted.

You can make a JWT invalid after 30 seconds or even 1 second. You should set an aud (audience) when creating the JWT. Otherwise the signature is crypto-graphically sound. Validate every single JWT every single time with a short lifetime. OIDC tokens are all JWTs btw.

If your talking about a browser context, where the authority is separate from the requesting body, then expiring even at 30s is excessive for user context, let alone every 1s or every request... you're effectively then inflating every single API request into 2 requests... one for a new token, then another to the API being called. This is irresponsible for not much gain in a user-facing context.

You should not be using them for user contexts at all. The cookie should be the session token and the sessions should be stored on the server side where you can simply delete them and the user's login becomes invalid. Using JWTs for this use case is just plain wrong.

Re: Stop Using JWTs

#53

Post by littlecranky67 »

jpalomaki wrote: post #45
littlecranky67 wrote: post #40

In sessions vs. JWT revocation lists, there is an argument in favor of JWT revocation lists. JWTs have a limited expiry timestamp, so you only ever need to maintain a revocation list for tokens not expired yet. Given that you probably only have a fraction of JWTs revoked compare to valid JWTs in circulation, you only need to query a very small dataset for each request. When using sessions, your list of valid sessions…

Session data lookup is one select to database that gives 0..1 rows and uses index. In most cases this is not something you need to worry about.

I agree. The storage space, however, is a different story. Your session DB can grow huge, depending on your session lifetime and your users logout behaviour. Plus, it is a concern in a distributed system (i.e. a token can be validated on every node, vs. a session lookup must be globally in sync)

Re: Stop Using JWTs

#54

Post by matt-p »

jpalomaki wrote: post #45
littlecranky67 wrote: post #40

In sessions vs. JWT revocation lists, there is an argument in favor of JWT revocation lists. JWTs have a limited expiry timestamp, so you only ever need to maintain a revocation list for tokens not expired yet. Given that you probably only have a fraction of JWTs revoked compare to valid JWTs in circulation, you only need to query a very small dataset for each request. When using sessions, your list of valid sessions…

Session data lookup is one select to database that gives 0..1 rows and uses index. In most cases this is not something you need to worry about.

Can even put it in redis too, if you have performance issues from looking for it in memory then you have probably have more users than google.

Re: Stop Using JWTs

#55

Post by tptacek »

solatic wrote: post #3

Necessary qualifier: for browser-based user sessions. Plenty of good uses for JWTs for service-to-service communication. edit: I read some of the linked stuff, e.g. https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... . Please, if JWTs are such a horrifically insecure standard, go ahead and publish your means for hacking AWS STS's AssumeRoleWithWebIdentity , or don't publish and just exploit it by launchin…

There is in fact a long lineage of vulnerabilities caused by JWTs in real applications.

Re: Stop Using JWTs

#56

Post by tptacek »

kyrra wrote: post #13
solatic wrote: post #3

Necessary qualifier: for browser-based user sessions. Plenty of good uses for JWTs for service-to-service communication. edit: I read some of the linked stuff, e.g. https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... . Please, if JWTs are such a horrifically insecure standard, go ahead and publish your means for hacking AWS STS's AssumeRoleWithWebIdentity , or don't publish and just exploit it by launchin…

JWT used to be bad due to libraries with poor defaults. Downgrade attacks were fairly common a number of years ago. Since most of the common libraries across all languages have gotten more sane defaults, it actually is pretty secure nowadays.

If we stipulate that, we're still left wondering what the utility is of a standard that creates affordances for the insecure defaults, as opposed to just designing it right from the beginning.

Re: Stop Using JWTs

#57

Post by joshmarlow »

vidarh wrote: post #46
littlecranky67 wrote: post #40

In sessions vs. JWT revocation lists, there is an argument in favor of JWT revocation lists. JWTs have a limited expiry timestamp, so you only ever need to maintain a revocation list for tokens not expired yet. Given that you probably only have a fraction of JWTs revoked compare to valid JWTs in circulation, you only need to query a very small dataset for each request. When using sessions, your list of valid sessions…

The moment you have to look up the user object, you've lost the primary advantage of JWT, and might as well ditch it.

It definitely violates DRY but if you keep passing the JWT down the call chain, you can do redundant permission checking in your business layer.

Now the reasonable response to the above is that this should be happening in a dedicated authn/z concern - and that is correct! But when paranoia is called for, it's not unreasonable to have redundant checks in logic where authz is critical.

Re: Stop Using JWTs

#58

Post by littlecranky67 »

matt-p wrote: post #54
jpalomaki wrote: post #45

Earlier quoted context omitted.

Session data lookup is one select to database that gives 0..1 rows and uses index. In most cases this is not something you need to worry about.

Can even put it in redis too, if you have performance issues from looking for it in memory then you have probably have more users than google.

What if you have two servers, one in japan and one in central europe? Where do the sessions live?

With JWTs, you would only need to replicate your revocation list of the last X hours (X being your JWT default lifetime) and probably be in the megabytes for the total list. Easy to replicate that ever 5-10seconds to all your locations.

Re: Stop Using JWTs

#59

Post by doctorpangloss »

littlecranky67 wrote: post #49
zsoltkacsandi wrote: post #44

Earlier quoted context omitted.

> JWTs have a limited expiry timestamp, so you only ever need to maintain a revocation list for tokens not expired yet. Sessions have expiration timestamps too, and you can configure them however you like.

Yeah of course, but how does that relate to my point? With JWTs you don'T have a list of valid tokens as state, but only a list of invalid ones (revoked). But the list of revoked tokens in the last X hours (where X is your token lifetime) is always going to be smaller than the list of active sessions given a large enough user base. Hence my original point stands, that the lookup and storage costs are lower than on se…

isn't it that you must have a revocation list in many cases? if you cannot get from N to 1 or 1 to 0 states, if you're just going from N to N-1>1, you haven't materially decreased your statefulness
Post reply on HN