3 ms·

> The general reason why folks don’t recommend JWTs is because it’s too easy to make mistakes in the validation logic. That isn't why I don't recommend JWTs, a

> The general reason why folks don’t recommend JWTs is because it’s too easy to make mistakes in the validation logic. That isn't why I don't recommend JWTs, and it's not why this article is not recommending JWTs. > Logout doesn’t really log you out! > Blocking users doesn’t immediately block them. > Could have stale data ^ JWTs fundamentally are not compatible with server-side authentication revocation. Your typical developer is like, "Well, I don't care much, I'll use JWTs anyway", but then some poor soul has to deal with the ticket titled "Blocked user still able to access service", or "User still able to access service after logout", or "session never expires!" (oo... look, you configured it incorrectly). I've been on the other side of having to deal with screwed up JWT implementations other folk have built. It's not fun. ...and yes yes, there are work arounds, you can have rotating short lived tokens and long lived refresh tokens and a database of revoked tokens...but you've just reimplemented server side session authentication yourself, and it's probably wrong. > I think you have to either assume competence... I think that's terrible advice. You should never assume developers are competent to implement authentication. It's a Hard Problem, like, writing a database, and frankly, only specialists are competent to do this correctly. Anyone can writing some kind of data store, but it's a bit harder having it ACID and concurrently multiuser. > or you have to suggest that developers use identity proxies... ...but yes, this is probably the only useful piece of advice to give to people: If you use a 3rd party authentication provider, you can delegate responsibility for doing the hard work of making sure they have a solution for the hard things; at which point, you don't really care if its JWT or cookies, or whatever. I still wouldn't recommend people use JWTs.

cameronh90 5y ago
"database of revoked tokens...but you've just reimplemented server side session authentication" There's one important difference between session authentication and JWT+revocation: the revocation list can be distributed asynchronously, whereas a session list needs at least read-after-write consistency. It's a minor point for most use cases, but occasionally can be very significant.
- lstamour 5y ago
  That said, the primary problem with distributed authentication and distributed revocation is either it slows down your processing as you wait for confirmation of new entries on the list, or you have a risk that actions might be allowed when another part of the system has tried to block them. We generally think of distributing authorization data asynchronously in the positive: adding a new user permission, rolling the list out to every authz server. But when you’re trying to block access immediately, it can be difficult. Not to be negative—if your JWT expires after 15 minutes and your list updates every 10 seconds, you’ve improved your reaction time quite a bit for revocations. Also, you can have an eventually consistent session store if you don’t mind that sometimes users might see a 403 they shouldn’t, if your app can cover it up such as by requesting content from a different region or waiting a bit. Similar to the idea of using a load balancer to pin sessions to particular servers.
deleted 5y ago
[deleted]

cameronh90 5y ago

"database of revoked tokens...but you've just reimplemented server side session authentication" There's one important difference between session authentication and JWT+revocation: the revocation list can be distributed asynchronously, whereas a session list needs at least read-after-write consistency. It's a minor point for most use cases, but occasionally can be very significant.

lstamour 5y ago
That said, the primary problem with distributed authentication and distributed revocation is either it slows down your processing as you wait for confirmation of new entries on the list, or you have a risk that actions might be allowed when another part of the system has tried to block them. We generally think of distributing authorization data asynchronously in the positive: adding a new user permission, rolling the list out to every authz server. But when you’re trying to block access immediately, it can be difficult. Not to be negative—if your JWT expires after 15 minutes and your list updates every 10 seconds, you’ve improved your reaction time quite a bit for revocations. Also, you can have an eventually consistent session store if you don’t mind that sometimes users might see a 403 they shouldn’t, if your app can cover it up such as by requesting content from a different region or waiting a bit. Similar to the idea of using a load balancer to pin sessions to particular servers.

deleted 5y ago

[deleted]