4 ms·

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
      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.
      - layoutIfNeeded 5y ago
        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?
        VincentEvans 5y ago
        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.
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.

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
    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.
    - layoutIfNeeded 5y ago
      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?
      - VincentEvans 5y ago
        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.

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.