Comment by yashap | Hacker News Reader

Comment by yashap | Hacker News Reader

Parent Full thread

Not sure why you’re being downvoted, but agreed. Tonnes of apps want to support SSO, and most modern SSO systems use Open ID Connect, where the id tokens are JWTs. If you want to let your users login via Google, Facebook, Okta, whatever, then you’ll be dealing JWTs.

And once you’re doing that, it’s a small step to say:

“even if my users want to signup/login via username and password, I’d rather not manage that myself. I’d rather use a 3rd party system to store the passwords, implement MFA and password recovery and signup/login forms and whatnot, and just trust the id tokens from that system.”

Auth0, Keycloak, FusionAuth, etc. And again you’ll be dealing with OIDC and JWTs.

If you want to manage your own usernames, passwords, signup/login pages, password reset flows, MFA flows, etc., then yeah, I’d go with traditional sessions stored in a db/cache that you manage, and auth tokens are just session ids. But if you want to outsource all of that, plus support SSO, then the id token you deal with will not be traditional session tokens, they’ll most likely be JWTs issued by someone else, where you just verify the signature.

And how do you log out?

The token is short lived (or should be!) and lost to the client. If that is good enough or not depends on the use case.

For example, if you don‘t trust the client you also cannot trust the logout button or know that the login credentials are not compromised.

So you would need a scenario where you get a token (let‘s say valid for an hour) and you use it on a computer that you trust and then someone can copy the token but afterwards you somehow trust the device again.

What am I missing?

Additionally most people never actively log out (especially on personal devices which are like 99%) so it’s practical to push a small list of invalidated and not yet expired tokens to all service caches in the rare case someone actually presses that logout button. Certainly much cheaper than checking them on each request or updating a cache of all sessions.

>So you would need a scenario where you get a token (let‘s say valid for an hour) and you use it on a computer that you trust and then someone can copy the token but afterwards you somehow trust the device again.

Wrong. You need to be able to invalidate tokens to other devices. (Lost device / revoked access use-case)

Ah, you want to logout everywhere. That‘s not how most logout buttons work. (I can logout of practically all my accounts only on one device.)

If you want to logout everywhere that‘s extremely rare and as I said such a table to capture this information would be tiny.

Additionally these tokens are short-lived. So even without token invalidation, the „logout everywhere“ can just invalidate the refresh tokens and all device are logged out within one hour.

It’s not about the “logout button”. It’s basic security to handle the “stolen device” use case.

Is that a practical use case? For a token that‘s valid for one hour? And the device is presumably locked. Is it really realistic that a user realizes quickly that the device is stolen and worried that it will be unlocked quickly and then actually logs in on another device to revoke the session of some website they were using (I wouldn‘t even know this is possible, how would a user know!) and that just to invalidate the token that would expire anyway within 30 minutes on average? Is that even remotely realistic to say nothing about „basic“?

I had (fully encrypted) devices stolen, of course, and I did revoke keys and changed passwords (just in case). But I never managed to do this within one hour and there was never a risk of anyone unlocking the device anyway.

You can validate whether the token is valid with issuer on each request if you want, furthermore issuers support log out functionality - so say auth0, has an endpoint that will kill the session. It’s probably a bit expensive to check the token on each call, but if your security model requires it....

Really not seeing the problem. In most non trivial apps authentication infrastructure is it’s own service anyway, so hitting auth0 on each call in practice works very similarly, up until certain amount of traffic, which I’ll never reach.

Then there’s no point in using JWT. You may as well use an UUID to hit auth0’s endpoint on each request. You really don’t get the article? Did you read it?

I’ve read it and even bookmarked it, because I thought it explains JWT well. But perhaps you’ll need to restate your concerns to get me on board.

JWT is a standard that comes with all of the benefits I described above and is used by many services that I can take advantage of. If the article tells me to switch back to some session id based scheme because it is supposedly smaller, I think I’ll pass.

Any infrastructure required to support log out - is far less complicated than one required to support secure password storage, login, changes, resets, recovery, etc. If it such simplicity comes at the cost of using JWT I think the tradeoff is very worth it.

With SSO, you don’t really control login/logout at all, that’s the whole point. For delegating authentication and whatnot to a system like Auth0, Keycloak, etc., for logout on a single device, you just clear the header holding the JWT. To invalidate the tokens completely, often you can’t, but you’re probably doing short lived refresh tokens, and you can make it so they can’t refresh. So at least they don’t maintain access for too long. i.e. https://auth0.com/docs/tokens/revoke-tokens

It’s a trade-off you make for not having to handle password persistence, and getting free-ish login/logout pages, SSO, MFA, password reset, etc. For many companies it’s a good trade-off.

Keycloak actually has user session management. You can call an admin api to logout a user from all devices and session. There is a draft proposal of session management in OpenID Connect.

Reply on news.ycombinator.com