7 ms·

And also GitHub, Gitlab, Auth0, OKTA, login.gov, Atlasssian, Kubernetes, Hashicorp, etc… OIDC seems to be the de-facto standard today.

by 0xEFF 5y ago

cmeacham98 5y ago
My understanding is the use of JWTs for session management is 99% of the time bad (tldr: you think you get "stateless" sessions but in reality you still need server side state for useful features like logging out); but its use for auth (i.e. via OIDC) is a normal and good use case.
- holtalanm 5y ago
  > in reality you still need server side state for useful features like logging out im curious about this. normally 'logging out' just involves deleting the secure http-only cookie where the jwt was stored. is there something I'm missing here?
  - pcstl 5y ago
    I believe they are mentioning the fact that the server cannot unilaterally log the user out in a "naive" JWT-based implementation without storing and checking a token blocklist - which makes the session no longer stateless.
    - holtalanm 5y ago
      I can see that. I suppose when people say they need 'server-side session storage' I start thinking of app state, but in reality it could be as simple as storing a jwt refresh token that would be considered valid.
      - IggleSniggle 5y ago
        It matters in the context of folks that are trying to do a serverless architecture, sold on the idea that JWTs don’t require anything more than a function to issue auth
  - tuyiown 5y ago
    Access revocation: sometimes it's critical to block access to an issued token, without trusting the client to comply with revocation, especially for malicious cases. Enforcing this implies to implement access control on each (critical) request, giving little advantage to a self contained token compared to a pure stateful signed session token.
    - holtalanm 5y ago
      Yeah, if you need that kind of control over token access, then im not certain a jwt is the right tool for the job. For most use-cases a short-lived jwt is fine, as it expires in a matter of minutes, or even seconds, depending on configuration.
      - cmeacham98 5y ago
        The ability to logout existing sessions (typically either via a manual user action or automatically upon changing/resetting their password) is a desirable feature in essentially all applications where user accounts can be compromised. You can kind of fake this by using a short-lived JWT and constantly refreshing it, but this: 1. Massively increases server strain and bandwidth usage 2. Has problems with users less reliable connections (they'll be randomly logged out all the time) 3. Makes "Remember Me" style features impossible (unless you use a server-side store for that, which brings us back to it not being stateless) Here's a good graph on why $method to make JWTs work for sessions is bad: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo... (note: for some reason the website doesn't support HTTPS :( )
        endiangroup 5y ago
        AD: I wrote a library that can deal with this for JWT https://github.com/endiangroup/compandauth https://github.com/endiangroup/compandauth The skiny is that you place a copy of some monotonic counter inside every JWT you issue, you keep track of the counter server side and compare with each request's JWT copy + some delta (which is the equivalent of maximum number of concurrent sessions you wish the user to have).
  - hn_throwaway_99 5y ago
    This conversation comes up all the time when discussing JWTs, and unfortunately I think the issue is usually way overblown: 1. I don't believe there are any real security issues regarding logout if JWTs have a sufficiently short expiration time. 2. The reason this issue comes up is because of compliance audits, who demand that as soon as the user logs out, that the supplied token becomes invalid. However, if the JWT is adequately discarded from the client, the fact that the JWT is still valid for another ~5-10 minutes or so is only a security risk if the token has already been stolen. The fact of the matter here is you really aren't protecting against a new attack vector with this "must immediately revoke tokens on logout" rule. 3. Despite my beliefs with #2 (and I'd love to hear an argument why this isn't valid), good luck trying to convince an auditor about that fact, who often love finding minor/mundane issues to justify their existence. So you'll still need to maintain a small blocklist, but the data in that list is usually very small (most users never log out these days) and can often be replicated in memory to each server.
    - coding123 5y ago
      I'm sure there are employees out there that have their self destruct scripts ready to go. If they are ever terminated they have 10 minutes of token validation time to blow everything up.
      - holtalanm 5y ago
        that would be insanely illegal.
    - numbsafari 5y ago
      This is solved with a revocation list, which only needs to contain the tokens issued within the last ~5-10m for which there is a reason for revocation. Add to that a revocation list for access tokens, which are typically 24h. The sum of both lists is vastly smaller and easier to manage than distributing session state and maintaining it server side for every single user.
    - IggleSniggle 5y ago
      I agree with your assessments, and your reply makes sense in the context of the above comments. Simply so that any readers arriving here that didn’t read the article arrive here, I just want to remind that these are not the fundamental complaints of the actual article itself, and are also unrelated to the proposed solution.
GoblinSlayer 5y ago
So you say it spreads like PHP?

And also GitHub, Gitlab, Auth0, OKTA, login.gov, Atlasssian, Kubernetes, Hashicorp, etc… OIDC seems to be the de-facto standard today.

by 0xEFF 5y ago

And also GitHub, Gitlab, Auth0, OKTA, login.gov, Atlasssian, Kubernetes, Hashicorp, etc… OIDC seems to be the de-facto standard today.

cmeacham98 5y ago

My understanding is the use of JWTs for session management is 99% of the time bad (tldr: you think you get "stateless" sessions but in reality you still need server side state for useful features like logging out); but its use for auth (i.e. via OIDC) is a normal and good use case.

holtalanm 5y ago
> in reality you still need server side state for useful features like logging out im curious about this. normally 'logging out' just involves deleting the secure http-only cookie where the jwt was stored. is there something I'm missing here?
- pcstl 5y ago
  I believe they are mentioning the fact that the server cannot unilaterally log the user out in a "naive" JWT-based implementation without storing and checking a token blocklist - which makes the session no longer stateless.
  - holtalanm 5y ago
    I can see that. I suppose when people say they need 'server-side session storage' I start thinking of app state, but in reality it could be as simple as storing a jwt refresh token that would be considered valid.
    - IggleSniggle 5y ago
      It matters in the context of folks that are trying to do a serverless architecture, sold on the idea that JWTs don’t require anything more than a function to issue auth
- tuyiown 5y ago
  Access revocation: sometimes it's critical to block access to an issued token, without trusting the client to comply with revocation, especially for malicious cases. Enforcing this implies to implement access control on each (critical) request, giving little advantage to a self contained token compared to a pure stateful signed session token.
  - holtalanm 5y ago
    Yeah, if you need that kind of control over token access, then im not certain a jwt is the right tool for the job. For most use-cases a short-lived jwt is fine, as it expires in a matter of minutes, or even seconds, depending on configuration.
    - cmeacham98 5y ago
      The ability to logout existing sessions (typically either via a manual user action or automatically upon changing/resetting their password) is a desirable feature in essentially all applications where user accounts can be compromised. You can kind of fake this by using a short-lived JWT and constantly refreshing it, but this: 1. Massively increases server strain and bandwidth usage 2. Has problems with users less reliable connections (they'll be randomly logged out all the time) 3. Makes "Remember Me" style features impossible (unless you use a server-side store for that, which brings us back to it not being stateless) Here's a good graph on why $method to make JWTs work for sessions is bad: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo... (note: for some reason the website doesn't support HTTPS :( )
      - endiangroup 5y ago
        AD: I wrote a library that can deal with this for JWT https://github.com/endiangroup/compandauth https://github.com/endiangroup/compandauth The skiny is that you place a copy of some monotonic counter inside every JWT you issue, you keep track of the counter server side and compare with each request's JWT copy + some delta (which is the equivalent of maximum number of concurrent sessions you wish the user to have).
- hn_throwaway_99 5y ago
  This conversation comes up all the time when discussing JWTs, and unfortunately I think the issue is usually way overblown: 1. I don't believe there are any real security issues regarding logout if JWTs have a sufficiently short expiration time. 2. The reason this issue comes up is because of compliance audits, who demand that as soon as the user logs out, that the supplied token becomes invalid. However, if the JWT is adequately discarded from the client, the fact that the JWT is still valid for another ~5-10 minutes or so is only a security risk if the token has already been stolen. The fact of the matter here is you really aren't protecting against a new attack vector with this "must immediately revoke tokens on logout" rule. 3. Despite my beliefs with #2 (and I'd love to hear an argument why this isn't valid), good luck trying to convince an auditor about that fact, who often love finding minor/mundane issues to justify their existence. So you'll still need to maintain a small blocklist, but the data in that list is usually very small (most users never log out these days) and can often be replicated in memory to each server.
  - coding123 5y ago
    I'm sure there are employees out there that have their self destruct scripts ready to go. If they are ever terminated they have 10 minutes of token validation time to blow everything up.
    - holtalanm 5y ago
      that would be insanely illegal.
  - numbsafari 5y ago
    This is solved with a revocation list, which only needs to contain the tokens issued within the last ~5-10m for which there is a reason for revocation. Add to that a revocation list for access tokens, which are typically 24h. The sum of both lists is vastly smaller and easier to manage than distributing session state and maintaining it server side for every single user.
  - IggleSniggle 5y ago
    I agree with your assessments, and your reply makes sense in the context of the above comments. Simply so that any readers arriving here that didn’t read the article arrive here, I just want to remind that these are not the fundamental complaints of the actual article itself, and are also unrelated to the proposed solution.

GoblinSlayer 5y ago

So you say it spreads like PHP?