4 ms·

Active user logouts, deletions, permission changes are rare, so the size of revocations lists is extremely small compared to number of tokens in existence. You

Active user logouts, deletions, permission changes are rare, so the size of revocations lists is extremely small compared to number of tokens in existence. You can keep revocations in a very fast lookup system (eg broadcasts + in-memory store), combined with reasonably short token renewals, like 5-60 minutes. Massively cuts down the number of token validity checks, and makes the system tolerant to downtimes of the auth system. That's less relevant for basic apps where the auth data is in the same DB as all the other data, but that is rarely the case in larger systems.

rafaelmn 1y ago
And when building distributed systems a bunch of systems don't really care about those changes immediately anyway so the propagation delay is acceptable, or you can push the burden of refreshing to the client for privilege expansion cases, etc.
CafeRacer 1y ago
Is there a proposed rfc for revocation lists?
- pwlb 1y ago
  You may have a look at this (still a Draft): https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/ https://datatracker.ietf.org/doc/draft-ietf-oauth-status-lis...
  - unscaled 1y ago
    I don't think status lists solve the requirement for near-realtime revocations. The statuslist itself has a TTL and does not get re-loaded until that TTL expires. This is practically similar to the common practice of having a stateful refresh token and a stateless access token. The statuslist "ttl" claim is equivalent to the "exp" claim of the access token in that regard, and it comes with the same tradeoffs. You can have a lower TTL for statuslist, but that comes at the cost of higher frequency of high-latency network calls due to cache misses. The classic solution to avoid this (in the common case where you can fit the entire revocation list in memory) is to have a push-based or pub/sub-based mechanism for propagating revocations to token verifiers.
    - brok3nmachine 1y ago
      For this reason, I use a LaunchDarkly config flag for the revocation list. Updates to the config are pushed to all LD clients in near real time.
    - motorest 1y ago
      > The statuslist itself has a TTL (...) If you read the draft, the TTL is clearly specified as optional. > (...) and does not get re-loaded until that TTL expires. That is false. The draft clearly states that the optional TTL is intended to "specify the maximum amount of time, in seconds, that the Status List Token can be cached by a consumer before a fresh copy SHOULD be retrieved." > You can have a lower TTL for statuslist, but that comes at the cost of higher frequency of high-latency network calls due to cache misses. The concept of a TTL specifies the staleness limit, and anyone can refresh the cache at a fraction of the TTL. In fact, some cache revalidation strategies trigger refreshes at random moments well within the TTL. There is also a practical limit to how frequently you refresh a token revocation list. Some organizations have a 5-10min tolerance period for basic, genera-purpose access tokens, and fall back to shorter-lived and even one-time access tokens for privileged operations. So if you have privileged operations being allowed when using long-lived tokens, your problem is not the revocation list.
      - unscaled 1y ago
        In that case, when and how would you reload the statuslist? Again, it doesn't matter if TTL and caching is optional, what matters is that this specification has NOTHING to do with a pub/sub-based or push-based mechanism as described by GGGP. This draft specifies a list that can be cached and/or refreshed periodically or on demand. This means that there will always be some specified refresh frequency and you cannot have near-real-time refreshes. > There is also a practical limit to how frequently you refresh a token revocation list. Some organizations have a 5-10min tolerance period for basic, genera-purpose access tokens, and fall back to shorter-lived and even one-time access tokens for privileged operations. So if you have privileged operations being allowed when using long-lived tokens, your problem is not the revocation list. That's totally cool. Some organizations are obviously happy with delayed revocations for non-sensitive operations, which they could easily achieve them with stateful refresh tokens, without the added complexity of revocation lists. Stateful and revokable refresh tokens are already supported by many OAuth 2.0 implementations such as Keycloak and Auth0[1]. All you have to do is to set the access token's TTL to 5-10 minutes and you'll get the same effect as you've described above. The performance characteristics may be worse, but many ap which are happy with delayed revocation are happy with this simple solution. Unfortunately, there are many products where immediate revocation is required. For instance, administrative dashboards and consoles where most operations are sensitive. You can force token validity check through an API call for all operations, but that makes stateless access tokens useless. What the original post above proposed is a common pattern[2] that lets you have the performance characteristics (zero extra latency) of stateless tokens together with the security characteristics of a stateful access token (revocation is registered in near-real-time, usually less than 10 seconds). This approach is supported by WSO2[3], for instance. The statuslist spec does nothing to standardize this approach. [1] https://auth0.com/docs/secure/tokens/refresh-tokens/revoke-refresh-tokens https://auth0.com/docs/secure/tokens/refresh-tokens/revoke-r... [2] See "Decentralized approach" in https://dzone.com/articles/jwt-token-revocation https://dzone.com/articles/jwt-token-revocation [3] https://mg.docs.wso2.com/en/latest/concepts/revoked-tokens/#methods-to-detect-jwt-token-revocation https://mg.docs.wso2.com/en/latest/concepts/revoked-tokens/#...
- mooreds 1y ago
  https://datatracker.ietf.org/doc/html/rfc7009 https://datatracker.ietf.org/doc/html/rfc7009 handles generic revocation without specifying implementation details. Some auth servers implement it. Keycloak does[0]. Auth0 doesn't as far as I can tell[1]. FusionAuth (my employer) has had it listed as a possible feature for years[2] but it never has had the community feedback to bubble it up to the top of our todo list. 0: https://www.keycloak.org/securing-apps/oidc-layers#_token_revocation_endpoint https://www.keycloak.org/securing-apps/oidc-layers#_token_re... 1: https://auth0.com/docs/secure/tokens/revoke-tokens https://auth0.com/docs/secure/tokens/revoke-tokens 2: https://github.com/fusionAuth/fusionauth-issues/issues/201 https://github.com/fusionAuth/fusionauth-issues/issues/201
mattmanser 1y ago
This makes it sound like you've only worked in an extremely narrow domain. It's not rare, it happens constantly in enterprise software, project managemment software, anything where you have collaboration. What is so frustrating about tech like JWTs is that it fits the fairly rare, high profile, websites like Reddit, netflix, etc. but doesn't fit ANYTHING else. Everyone else wants immediate revocation of rights, not waiting for a token to expire. And yet we all have to suffer this subpar tech because someone wrote a blog post about it and a bunch of moronic software "architects" made it the only option. If you don't JWT somehow you're doing it wrong, even though it should in fact be an extremely niche way of doing Auth at scale. Simple cookie based tokens were and still are a much better choice for many applications.
- konha 1y ago
  > It's not rare, it happens constantly in enterprise software, project managemment software, anything where you have collaboration The number of revoked tokens compared to all active tokens should still be tiny in those systems, wouldn’t you agree? > Everyone else wants immediate revocation of rights, not waiting for a token to expire. With a revocation list you can still have that. Once you propagated your revocation to all relying parties the token effectively expires early.
  - zaphar 1y ago
    The size of the revocation list is irrelevant. As soon as you have to do a call to get the revocation list you might as well just include the rest of it in the call as well.
- bandoti 1y ago
  It’s important to consider that JWT is a series of specs and folks can choose to use any of them to suit their needs. In fact, it can be used to create simple tokens—even if you store them in a database in a traditional authentication sense. But it is also helpful to be able to use OIDC, for example, with continuous delivery workflows to authenticate code for deployment. These use JWT and it works quite well I think. Note: technically JWT is only one of the specs so it’s not exactly correct how I’m referring to it, but I think of them collectively as JWT. :)
nextaccountic 1y ago
> makes the system tolerant to downtimes of the auth system You mean the system that handles revocations? If so, your own system will be vulnerable if you continue to do business as usual while it's down

rafaelmn 1y ago

And when building distributed systems a bunch of systems don't really care about those changes immediately anyway so the propagation delay is acceptable, or you can push the burden of refreshing to the client for privilege expansion cases, etc.

CafeRacer 1y ago

Is there a proposed rfc for revocation lists?

pwlb 1y ago
You may have a look at this (still a Draft): https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/ https://datatracker.ietf.org/doc/draft-ietf-oauth-status-lis...
- unscaled 1y ago
  I don't think status lists solve the requirement for near-realtime revocations. The statuslist itself has a TTL and does not get re-loaded until that TTL expires. This is practically similar to the common practice of having a stateful refresh token and a stateless access token. The statuslist "ttl" claim is equivalent to the "exp" claim of the access token in that regard, and it comes with the same tradeoffs. You can have a lower TTL for statuslist, but that comes at the cost of higher frequency of high-latency network calls due to cache misses. The classic solution to avoid this (in the common case where you can fit the entire revocation list in memory) is to have a push-based or pub/sub-based mechanism for propagating revocations to token verifiers.
  - brok3nmachine 1y ago
    For this reason, I use a LaunchDarkly config flag for the revocation list. Updates to the config are pushed to all LD clients in near real time.
  - motorest 1y ago
    > The statuslist itself has a TTL (...) If you read the draft, the TTL is clearly specified as optional. > (...) and does not get re-loaded until that TTL expires. That is false. The draft clearly states that the optional TTL is intended to "specify the maximum amount of time, in seconds, that the Status List Token can be cached by a consumer before a fresh copy SHOULD be retrieved." > You can have a lower TTL for statuslist, but that comes at the cost of higher frequency of high-latency network calls due to cache misses. The concept of a TTL specifies the staleness limit, and anyone can refresh the cache at a fraction of the TTL. In fact, some cache revalidation strategies trigger refreshes at random moments well within the TTL. There is also a practical limit to how frequently you refresh a token revocation list. Some organizations have a 5-10min tolerance period for basic, genera-purpose access tokens, and fall back to shorter-lived and even one-time access tokens for privileged operations. So if you have privileged operations being allowed when using long-lived tokens, your problem is not the revocation list.
    - unscaled 1y ago
      In that case, when and how would you reload the statuslist? Again, it doesn't matter if TTL and caching is optional, what matters is that this specification has NOTHING to do with a pub/sub-based or push-based mechanism as described by GGGP. This draft specifies a list that can be cached and/or refreshed periodically or on demand. This means that there will always be some specified refresh frequency and you cannot have near-real-time refreshes. > There is also a practical limit to how frequently you refresh a token revocation list. Some organizations have a 5-10min tolerance period for basic, genera-purpose access tokens, and fall back to shorter-lived and even one-time access tokens for privileged operations. So if you have privileged operations being allowed when using long-lived tokens, your problem is not the revocation list. That's totally cool. Some organizations are obviously happy with delayed revocations for non-sensitive operations, which they could easily achieve them with stateful refresh tokens, without the added complexity of revocation lists. Stateful and revokable refresh tokens are already supported by many OAuth 2.0 implementations such as Keycloak and Auth0[1]. All you have to do is to set the access token's TTL to 5-10 minutes and you'll get the same effect as you've described above. The performance characteristics may be worse, but many ap which are happy with delayed revocation are happy with this simple solution. Unfortunately, there are many products where immediate revocation is required. For instance, administrative dashboards and consoles where most operations are sensitive. You can force token validity check through an API call for all operations, but that makes stateless access tokens useless. What the original post above proposed is a common pattern[2] that lets you have the performance characteristics (zero extra latency) of stateless tokens together with the security characteristics of a stateful access token (revocation is registered in near-real-time, usually less than 10 seconds). This approach is supported by WSO2[3], for instance. The statuslist spec does nothing to standardize this approach. [1] https://auth0.com/docs/secure/tokens/refresh-tokens/revoke-refresh-tokens https://auth0.com/docs/secure/tokens/refresh-tokens/revoke-r... [2] See "Decentralized approach" in https://dzone.com/articles/jwt-token-revocation https://dzone.com/articles/jwt-token-revocation [3] https://mg.docs.wso2.com/en/latest/concepts/revoked-tokens/#methods-to-detect-jwt-token-revocation https://mg.docs.wso2.com/en/latest/concepts/revoked-tokens/#...
mooreds 1y ago
https://datatracker.ietf.org/doc/html/rfc7009 https://datatracker.ietf.org/doc/html/rfc7009 handles generic revocation without specifying implementation details. Some auth servers implement it. Keycloak does[0]. Auth0 doesn't as far as I can tell[1]. FusionAuth (my employer) has had it listed as a possible feature for years[2] but it never has had the community feedback to bubble it up to the top of our todo list. 0: https://www.keycloak.org/securing-apps/oidc-layers#_token_revocation_endpoint https://www.keycloak.org/securing-apps/oidc-layers#_token_re... 1: https://auth0.com/docs/secure/tokens/revoke-tokens https://auth0.com/docs/secure/tokens/revoke-tokens 2: https://github.com/fusionAuth/fusionauth-issues/issues/201 https://github.com/fusionAuth/fusionauth-issues/issues/201

mattmanser 1y ago

This makes it sound like you've only worked in an extremely narrow domain. It's not rare, it happens constantly in enterprise software, project managemment software, anything where you have collaboration. What is so frustrating about tech like JWTs is that it fits the fairly rare, high profile, websites like Reddit, netflix, etc. but doesn't fit ANYTHING else. Everyone else wants immediate revocation of rights, not waiting for a token to expire. And yet we all have to suffer this subpar tech because someone wrote a blog post about it and a bunch of moronic software "architects" made it the only option. If you don't JWT somehow you're doing it wrong, even though it should in fact be an extremely niche way of doing Auth at scale. Simple cookie based tokens were and still are a much better choice for many applications.

konha 1y ago
> It's not rare, it happens constantly in enterprise software, project managemment software, anything where you have collaboration The number of revoked tokens compared to all active tokens should still be tiny in those systems, wouldn’t you agree? > Everyone else wants immediate revocation of rights, not waiting for a token to expire. With a revocation list you can still have that. Once you propagated your revocation to all relying parties the token effectively expires early.
- zaphar 1y ago
  The size of the revocation list is irrelevant. As soon as you have to do a call to get the revocation list you might as well just include the rest of it in the call as well.
bandoti 1y ago
It’s important to consider that JWT is a series of specs and folks can choose to use any of them to suit their needs. In fact, it can be used to create simple tokens—even if you store them in a database in a traditional authentication sense. But it is also helpful to be able to use OIDC, for example, with continuous delivery workflows to authenticate code for deployment. These use JWT and it works quite well I think. Note: technically JWT is only one of the specs so it’s not exactly correct how I’m referring to it, but I think of them collectively as JWT. :)

nextaccountic 1y ago

> makes the system tolerant to downtimes of the auth system You mean the system that handles revocations? If so, your own system will be vulnerable if you continue to do business as usual while it's down