4 ms·

Revoking a bearer token for multiple services is an open loop problem, where you can't know if all services have revoked it unless each service builds in some k

Revoking a bearer token for multiple services is an open loop problem, where you can't know if all services have revoked it unless each service builds in some kind of guarantee signal, which would remove a lot of the integration efficiency of using bearer tokens in the first place. That leaves threads to pull like the ones implied in the exploit. I've seen refresh tokens set to 6mo to a year in enterprise environments where they were reducing the number of 2FA logins required. We're all speculating on the actual exploit still, I can see how something like this happened. Federating logins federates risk and aggregates it into something users can't reason about and is difficult to unwind. It's just the cost of progress.

dwaite 3y ago
> Revoking a bearer token for multiple services is an open loop problem, where you can't know if all services... What is a service here? A bearer token is meant solely for the AS. Revocation of a bearer token only means something in the context of the AS. Now if one wants to build some AS feature to go tell every protected resource "there's an access token good for another 15 minutes - I revoked its bearer token so don't honor that access token" one can build such a thing, but it is going to be some particular custom aspect of the implementation shared between the AS and resource servers. Since OAuth only really profiled two patterns for interoperability between the two (stateless sharing via JWT, stateful endpoint via introspection service), the only real interoperable approach is to make a introspection call each time you evaluate the access token. At a massive distributed scale like with someone like Google, such introspection decisions would have to be pushed closer to the nodes as a distributed system itself, which means it becomes eventually consistent. You have to decide whether a complex stateful system is worth it considering natural access token expiry on its own also essentially makes revocation eventually consistent.

dwaite 3y ago

> Revoking a bearer token for multiple services is an open loop problem, where you can't know if all services... What is a service here? A bearer token is meant solely for the AS. Revocation of a bearer token only means something in the context of the AS. Now if one wants to build some AS feature to go tell every protected resource "there's an access token good for another 15 minutes - I revoked its bearer token so don't honor that access token" one can build such a thing, but it is going to be some particular custom aspect of the implementation shared between the AS and resource servers. Since OAuth only really profiled two patterns for interoperability between the two (stateless sharing via JWT, stateful endpoint via introspection service), the only real interoperable approach is to make a introspection call each time you evaluate the access token. At a massive distributed scale like with someone like Google, such introspection decisions would have to be pushed closer to the nodes as a distributed system itself, which means it becomes eventually consistent. You have to decide whether a complex stateful system is worth it considering natural access token expiry on its own also essentially makes revocation eventually consistent.