Hacker News Reader

Comment by Znafon | Hacker News Reader

At least those are well known, no common web framework will save password in clear text, and there is comprehensive literature on how to use SQL and many well written ORMs that will make it very hard to shoot yourself in the foot.

For JWT, it's essentially promises of easy authentication process (rarely talking about the hard things like logout) spread like landmines over Medium and blogs, waiting to blow your foot and all your application with it.

View on HN

Regarding logout, I think that's a fundamental issue with a stateless solution like JWTs. I mean, the whole point is that it is a self encapsulated token, so you don't have to go back to a central server to check if someone's login session is still valid. So how on earth do you invalidate it?

My boss wrote up this article on different ways to revoke JWTs: https://fusionauth.io/learn/expert-advice/tokens/revoking-jw... which examines a few interesting methods.

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

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

>rarely talking about the hard things like logout

Why hard?

You can always black list them

But then you have have make a database call to check the blacklist, so you might as well use sessions

I'm not sure about it, but what if Logout just removed token from client meanwhile "Logout from all devices" black lists token?

I tend to believe that it could be used by gmail, but it's just a guess

If you're blacklisting tokens at any point in your application, you then need to check this blacklist.

Reply on news.ycombinator.com