[seandoe]

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 session and use a jwt and not use cookies. Etc etc

[echelon]

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 expire.

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), so if someone steals the JWT, they can continue to redeem it until expiry.

This is what the article is trying to warn against.

[wokwokwok]

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

[acaloiar]

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

JWTs are a cryptographically sound means of conveying identity between systems, assuming the implementation doesn't allow `algorithm: none`. I'm genuinely curious why you perceive JWTs as useless when they're stateful. It's a common opinion, so I assume there's something to it. My best guess is that it stems from JWTs being "sold" as a stateless means of conveying identity. In which case, I think they fall short of that promise. I just don't equate that with useless. I'm using the word useless, which I interpreted your statement "no reason to use JWT" to mean, but feel free to correct me on that.

[EE84M3i]

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?

[geraldwhen]

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

[acaloiar]

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

[klodolph]

You can trade for complexity—you can use revocation lists if you want to revoke JWTs. The revocation list of unexpired but revoked JWTs will generally be much shorter than the list of valid JWTs. You can push these lists to your front-ends, if that’s where you authenticate requests.

Far from trivial to implement, but it gives you some amount of performance and security at the same time.

[Moneysac]

In a single page application you have to access the JWTs with JavaScript. When we use cookies to implement sessions we have attributes like HttpOnly to prevent the cookie from being referenced by JavaScript code. In this case a XSS vulnerability would not be able to simply access the cookie and take over another users session.

What I am trying to say here is that JWTs used in single page applications are dangerous because you have no layer of protection against XSS attacks.

[seandoe]

> In a single page application you have to access the JWTs with JavaScript.

Who says you _have_ to? You could set a jwt as an httponly cookie and use it to exclusively validate API requests in your backend.

[emj]

> > ...utilize JSON Web tokens (JWTs) for session handling instead of cookies.

I read that as JWTs in a cookie as a replacement for session cookies with data stored on a server. There are nice things about that, but with a fail safe logout mechanism via server side revocation lists JWTs are not that stateless anymore.

EDIT: I do agree that the article misses the point a bit, but I also agree with the article that sessions cookies are wonderful and you almost always should use that instead. It all depends on your environment. One thing I can say: never use Active Directory as a token server the amount of glue you need is insane.

[richbell]

Presumably they mean session cookies.

[ehutch79]

Then why do people keep sending JWTs with only session tokens, which on the backend they treat like session cookies?