3 ms·

I don't see how anything you said would refute OPs premise, that if you want proper logout [1] in your app, you can't use JWTs without constantly querying whet

I don't see how anything you said would refute OPs premise, that if you want proper logout [1] in your app, you can't use JWTs without constantly querying whether a particular JWT should be accepted or not, from which it follows that this query mechanism may as well be a traditional database with a "sessions" table. How you organize your data, your services, your middleware, etc. does not change this the slightest, hence are irrelevant. ---- [1] proper logout is instant (this invalidates the "just use a JWT with short timeout!" argument), and prevents session stealing (this invalidates the "just throw away your JWT to logout" argument)

_heimdall 2y ago
> may as well be a traditional database with a "sessions" table. Isn't that kind of the point though? I'm not saying JWTs are a better answer for logout, only that JWTs can still support logout and they both similarly require a database transaction. If logout can work either way, and in all likelihood logout isn't a performance concern as long as its secure, you may have other use cases and requirements in an app that do make JWTs a better fit. I still don't understand how the argument here can be that there are no cases for JWTs, or that the list of "its" in the original article can be bulletproof no matter what else is going on in a project. That's unnecessarily absolute and leaves no wiggle room for competing priorities and constraints.
- meindnoch 2y ago
  >I'm not saying JWTs are a better answer for logout, only that JWTs can still support logout and they both similarly require a database transaction. Because the whole selling point of JWTs was that they eliminate this database transaction!!! As soon as you have logout, your JWTs degrade to nothing but a unique byte sequence that you need to check in the DB whether it's still valid or not. You may as well use unique JPEGs or MP3 files to identify your sessions - it would work just as well (and it would be equally stupid). In fact, in the presence of logout, JWTs are worse than opaque session tokens, because careless programmers developing a new microservice might see that it's a JWT and be tempted to just check the signature and the expiration without consulting the auth database for revocations, thus leaving that microservice accessible with compromised tokens.
  - _heimdall 2y ago
    Ah okay, so that was just the wrong selling point! JWTs can* avoid a database query if the data isn't super important, like if you just want to tack on some session context and aren't worried about invalidating it manually. Session tokens are just a unique ID, there is some value in wrapping up data inside the token like a JWT. That just isn't always suitable. For authentication and authorization there isn't much benefit, but that doesn't make one right and one wrong. They can be useful in certain author scenarios, like if you're using an external author service. If the argument here is simply that JWTs aren't a huge benefit in auth, sure that's fine. I just don't agree that that means they should never be used for auth or that they are universally worse for auth in all scenarios and applications.

_heimdall 2y ago

> may as well be a traditional database with a "sessions" table. Isn't that kind of the point though? I'm not saying JWTs are a better answer for logout, only that JWTs can still support logout and they both similarly require a database transaction. If logout can work either way, and in all likelihood logout isn't a performance concern as long as its secure, you may have other use cases and requirements in an app that do make JWTs a better fit. I still don't understand how the argument here can be that there are no cases for JWTs, or that the list of "its" in the original article can be bulletproof no matter what else is going on in a project. That's unnecessarily absolute and leaves no wiggle room for competing priorities and constraints.

meindnoch 2y ago
>I'm not saying JWTs are a better answer for logout, only that JWTs can still support logout and they both similarly require a database transaction. Because the whole selling point of JWTs was that they eliminate this database transaction!!! As soon as you have logout, your JWTs degrade to nothing but a unique byte sequence that you need to check in the DB whether it's still valid or not. You may as well use unique JPEGs or MP3 files to identify your sessions - it would work just as well (and it would be equally stupid). In fact, in the presence of logout, JWTs are worse than opaque session tokens, because careless programmers developing a new microservice might see that it's a JWT and be tempted to just check the signature and the expiration without consulting the auth database for revocations, thus leaving that microservice accessible with compromised tokens.
- _heimdall 2y ago
  Ah okay, so that was just the wrong selling point! JWTs can* avoid a database query if the data isn't super important, like if you just want to tack on some session context and aren't worried about invalidating it manually. Session tokens are just a unique ID, there is some value in wrapping up data inside the token like a JWT. That just isn't always suitable. For authentication and authorization there isn't much benefit, but that doesn't make one right and one wrong. They can be useful in certain author scenarios, like if you're using an external author service. If the argument here is simply that JWTs aren't a huge benefit in auth, sure that's fine. I just don't agree that that means they should never be used for auth or that they are universally worse for auth in all scenarios and applications.