6 ms·

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 JW

by yashap 5y ago

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.

layoutIfNeeded 5y ago
And how do you log out?
- quonn 5y ago
  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.
  - layoutIfNeeded 5y ago
    >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)
    - quonn 5y ago
      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.
      - layoutIfNeeded 5y ago
        It’s not about the “logout button”. It’s basic security to handle the “stolen device” use case.
        quonn 5y ago
        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.
      - VincentEvans 5y ago
- VincentEvans 5y ago
  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.
- yashap 5y ago
  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 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.
- yannikyeo 5y ago
  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.

by yashap 5y ago

layoutIfNeeded 5y ago

And how do you log out?

quonn 5y ago
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.
- layoutIfNeeded 5y ago
  >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)
  - quonn 5y ago
    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.
    - layoutIfNeeded 5y ago
      It’s not about the “logout button”. It’s basic security to handle the “stolen device” use case.
      - quonn 5y ago
        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.
    - VincentEvans 5y ago
VincentEvans 5y ago
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.
yashap 5y ago
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 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.
yannikyeo 5y ago
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.