Hacker News Reader

Comment by dathinab | Hacker News Reader

For many applications "slow" logouts are enough, i.e. basically do what is common in OAuth2 setups:

- Have a refresh token which is only usable with the (right) auth server and can only be used to generate new access tokens. As it's only usable with the auth server it's easy to revoke (it's kinda like a session cookie).

- Keep validity of access tokens short.

So by revoking the refresh token the logout will be done in at most highest_refresh_token_start_time + refresh_token_validity.

Through sadly any "faster" logout method on a distributed system is indeed quite complex. (Like propagating bloom filter headed blacklists of early revoked access tokens).

View on HN

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

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

Doing regular, boring authentication using user/password just supports logout out of box.

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

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

Reply on news.ycombinator.com