[WirelessGigabit]

You're still stuck with a delay of you fetching the list of revoked tokens and someone getting to your service.

And that delay allows someone to come in with a compromised token.

However, with short expiration dates you achieve the same. You shorten the duration that a token is valid for.

Assume a token is revoked. It can be used against any target until they refresh their revocation list.

Same goes with just tokens with a short expiration date. It can be used against any target until it expires.

I guess the difference is users extending their token lifetime more often (more load for your signing server) vs offering an API that you can use to share revoked tokens which needs to be checked every time (in which case it's no longer stateless) or checked every once in a while.

Pick your poison.

[kevincox]

You can do something like the True time trick. Services refresh the revocation list every 1s. If they can't refresh for more than 10s they reject authorization. Then on revocation you just need to wait for 15s or so to ensure that the token will no longer be accepted.

This of course means that your downtime tolerance for the token distribution is quite low, but still better than checking revocation on each request.

You can also flip it and track the state of every app server, revocation waits until they have all updated (or been confirmed dead) but now revocation time is unbounded. (And you are tracking more mutable state)

[meindnoch]

Unless you push the revocation list changes immediately to the service instances.

[WirelessGigabit]

Which makes it stateful, but instead of a punch of systems pulling your revocation list you're pushing it.

[cratermoon]

How about short-lived access tokens and refresh tokens?

[WirelessGigabit]

Depends on your usecase. On a device it's harder to steal a token, especially on iOS when you put all that stuff in the secured enclave.

Fortify that with certificate pinning on your application and it suddenly becomes REALLY hard to intercept traffic.