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

Stop using JSON Web Tokens for user sessions

ds-security.com

Post reply on HN
Print view View original

111–120 of 145 posts

Re: Stop using JSON Web Tokens for user sessions

#111

Post by poxrud »

Aldipower wrote: post #54

Just do not store JWTs in LocalStorage or any JavaScript accessible location. Use secured httpOnly cookies. Validate the JWT on server-side _stateless_. No need for a database. This idea is so good and it works! Just follow best security practice. If you don't, it is not the fault of the JWT. Bad blog article.. Yes, things like Keycloak and such follow _bad practice_. Still not the fault of JWT.

You do need a database if you want the ability to log users out server side. This is usually done through a second refresh token.

Re: Stop using JSON Web Tokens for user sessions

#113

Post by klodolph »

vulcanash999 wrote: post #79
kaoD wrote: post #20

As a side question (or rather, what I expected the central point of the article to be instead): how are you supposed to actually use JWT? The point of JWT vs opaque tokens is that you can just inspect the token itself to derive permissions without hitting any sessions in DB, right? This means we need a short-lived access token (5 min or so?) so that sessions are revoked in a reasonable time if the token is stolen som…

You could use the access token for each request. The advantage is that it is a simpler approach, and does away with the 5-minutes restriction you refer to, as the logout/invalidation would be immediate and not in 0-X minutes where X is the access token life in minutes. The disadvantage is that serving each request will involve making a round-trip with the auth service. This means at the minimum a DB read for every re…

You can revoke tokens before they expire by distributing a token revocation list to front-ends. This involves some extra work, but presumably, the list of unexpired but revoked tokens will normally be short.

Re: Stop using JSON Web Tokens for user sessions

#114

Post by uxp8u61q »

sam_lowry_ wrote: post #59
andybak wrote: post #15

Earlier quoted context omitted.

Cookie based session logins like everyone used to use?

I work for ab EU government, and cookies are a no-go because of cookies directive, so we use JWT and auth the javscript engine, not the browser. This leads to a multitude if problems, but who cares?

That's bullshit. Even ec.europa.eu (the European Commission's website - I have to login there from time to time) sets session cookies on my browsers. Either you've misunderstood what's asked of you, or your manager has, or someone higher up in your organization. But the "cookie directive" has never prevented anyone from using cookies altogether. You don't even need to ask for consent for a session cookie.

Re: Stop using JSON Web Tokens for user sessions

#115

Post by wokwokwok »

echelon wrote: post #107
seandoe wrote: post #99

It's articles like these that make things more confusing for folks who are learning about auth/session security. It's obvious the author has developed strong convictions without really understanding the subject. I can't make it past the first sentence: > ...utilize JSON Web tokens (JWTs) for session handling instead of cookies. One has nothing to do with the other. You can use a jwt and cookies. You can use a db sess…

This article can't explain what it's trying to hit at! JWTs are stateless. JWTs reduce the distributed system complexity of having every microservice talk to an auth system in the flow of every request. But with that, there are tradeoffs. You cryptographically sign JWTs, then you don't have to check them against a session/authc/authz system. JWTs come with an expiry, and your systems statelessly trust them until they…

> A problem is that a user can't revoke a JWT.

Bluntly, this.

If you need need this functionality, for example, when you log out of a banking app... and if you've implemented token revocation, eg. by storing a list of 'revoked' tokens in a database somewhere when someone 'logs out' or gets banned.

...then, in most cases you should not be using JWT.

Once you make your JWT stateful, by storing it in a database there is no reason to use JWT.

...and since that is the only way to implement that functionality using JWT, there are many times when JWT is not a suitable choice.

Re: Stop using JSON Web Tokens for user sessions

#116

Post by muldvarp »

7sidedmarble wrote: post #82
muldvarp wrote: post #47

Earlier quoted context omitted.

> so all it takes is a little injected script If you can inject javascript, it's game over anyway. > HTTPOnly cookies are safe from XSS attacks. No, you can still do pretty much anything that cookie enables you to do. You just can't get the actual cookie string.

> If you can inject javascript, it's game over anyway. Yeah, but as you pointed out the one thing you can't do is get the cookie. Having the auth token yourself as the attacker is a way different story then just having XSS vulnerabilities. You can still "do" a lot, but you still have to get another user with the token you want to interact with the page with your XSS to "do" what you want.

> You can still "do" a lot, but you still have to get another user with the token you want to interact with the page with your XSS to "do" what you want.

You need to do this in both cases.

Re: Stop using JSON Web Tokens for user sessions

#117

Post by geraldwhen »

wokwokwok wrote: post #115
echelon wrote: post #107

Earlier quoted context omitted.

This article can't explain what it's trying to hit at! JWTs are stateless. JWTs reduce the distributed system complexity of having every microservice talk to an auth system in the flow of every request. But with that, there are tradeoffs. You cryptographically sign JWTs, then you don't have to check them against a session/authc/authz system. JWTs come with an expiry, and your systems statelessly trust them until they…

> A problem is that a user can't revoke a JWT. Bluntly, this. If you need need this functionality, for example, when you log out of a banking app... and if you've implemented token revocation, eg. by storing a list of 'revoked' tokens in a database somewhere when someone 'logs out' or gets banned. ...then, in most cases you should not be using JWT. Once you make your JWT stateful , by storing it in a database there i…

This is exactly how many banks handle auth because 1.) jwt is mandated and 2.) so is session revocation.

Re: Stop using JSON Web Tokens for user sessions

#118

Post by roetlich »

klodolph wrote: post #109
roetlich wrote: post #56

The general idea of the blog post is correct, but so many things are worded in slightly incorrect ways. I think this blog post needs a few edits. > JSON Web tokens (JWTs) for session handling instead of cookies. JWT and cookies aren't mutually exclusive, you can put a jwt in a cookie, unless it's too big. There are two issues: Where do you store a sessions key, and how you create the session key. The author correctly…

Agreed. I hate to word it this way, but the problem is that JWTs are misused. The reason I hate to word it this way because the natural step after “X is misused” is “X is prone to misuse”. Which is usually right. But the reason why JWTs are prone to misuse is partly because the underlying problem is hard (security, authentication, the web) and partly because some of the libraries which work with JWTs provide applicat…

Yes!

> but spend some time understanding the underlying problem space.

This is the most important point, but you're other points are also very true. And less one-sided. :)

Re: Stop using JSON Web Tokens for user sessions

#119

Post by acaloiar »

echelon wrote: post #107
seandoe wrote: post #99

It's articles like these that make things more confusing for folks who are learning about auth/session security. It's obvious the author has developed strong convictions without really understanding the subject. I can't make it past the first sentence: > ...utilize JSON Web tokens (JWTs) for session handling instead of cookies. One has nothing to do with the other. You can use a jwt and cookies. You can use a db sess…

This article can't explain what it's trying to hit at! JWTs are stateless. JWTs reduce the distributed system complexity of having every microservice talk to an auth system in the flow of every request. But with that, there are tradeoffs. You cryptographically sign JWTs, then you don't have to check them against a session/authc/authz system. JWTs come with an expiry, and your systems statelessly trust them until they…

> A problem is that a user can't revoke a JWT by logging out or changing their password (unless you build extra infra to store the invalidations and fail closed)

Applications should both invalidate JWTs on logout and validate JWTs haven't been revoked for every request. Yes, it's performance overhead and increases infrastructure demands.

The problem is that people want JWTs to be both secure and fast. But the reality is they can only have one of these qualities at a time. They can sacrifice a bit of speed and get security, or sacrifice a bit of security for speed.

Re: Stop using JSON Web Tokens for user sessions

#120

Post by EE84M3i »

wokwokwok wrote: post #115
echelon wrote: post #107

Earlier quoted context omitted.

This article can't explain what it's trying to hit at! JWTs are stateless. JWTs reduce the distributed system complexity of having every microservice talk to an auth system in the flow of every request. But with that, there are tradeoffs. You cryptographically sign JWTs, then you don't have to check them against a session/authc/authz system. JWTs come with an expiry, and your systems statelessly trust them until they…

> A problem is that a user can't revoke a JWT. Bluntly, this. If you need need this functionality, for example, when you log out of a banking app... and if you've implemented token revocation, eg. by storing a list of 'revoked' tokens in a database somewhere when someone 'logs out' or gets banned. ...then, in most cases you should not be using JWT. Once you make your JWT stateful , by storing it in a database there i…

I guess it depends on how fast revoked sessions need to stop working and how many you have.

If eventual consistency is good enough, presumably you could use something that looks like a bloom filter of revoked tokens and only check ones that match against the revocation service, right?

Post reply on HN