4 ms·
> For many applications "slow" logouts are enough Why? I understand it might be acceptable for the next "Uber for Cats" SaaS but if you protect an account that
by Znafon 6y ago
> For many applications "slow" logouts are enough
Why? I understand it might be acceptable for the next "Uber for Cats" SaaS but if you protect an account that is actually important, not being able to revoke an access key is an issue.
> Keep validity of access tokens short.
But then you are actually spamming your authentication service and it even starts to blur the distinction between access token and refresh token.
I understand that there is many specific use cases where JWT makes sense like when you have to delegate authentication but for other case which shouldn't be recommending it, not being able to properly logout is not a security practice we should have in 2020 and later.
- user5994461 6y agoWhat better tool do you suggest that can handle logout? It's 2020 and there are none. OpenID Connect with JWT handles logout just fine if you really want it. Call the /oidc/tokeninfo to check the token is valid instead of verifying the signature offline. Of course this doesn't have the benefits of a decentralized token anymore. Can't have the cake and eat it too.
- nextaccountic 6y agoDoing regular, boring authentication using user/password just supports logout out of box.
- poxrud 6y agoSo regular cookie session based auth? There are drawbacks such as managing session state on the server, and increased latency and cpu load, since you now have to have a db call on every action.
- closeparen 6y agoThe argument is that this DB call, or something much like it, is inherently necessary to support logout. It's not something unnecessary that can be optimized away; getting rid of it entails losing functionality.