3 ms·

In Google's sort of environments, access tokens have to be interpreted by the world (e.g. a zillion geographically distributed Google nodes), so it makes sense

by dwaite 3y ago

In Google's sort of environments, access tokens have to be interpreted by the world (e.g. a zillion geographically distributed Google nodes), so it makes sense for them to be self-contained bundles of authorization policy decisions and quick-need attributes, with a time limit. This is the sort of thing that RFC 9068 was made for. Exchanging an access token for a new one using a refresh token is a seldomly done operation (in comparison), with whatever amount of business logic that the company needs, evaluated in a more centralized environment belonging to a single business unit (e.g. the auth team). So you'd expect access tokens to have some shorter-lived (6-60 minute) fixed lifetime to an expiry instant and to be non-revocable on their own, while refresh tokens are opaque to any software other than the central OAuth service. They might be good for a day or year, or each refresh may be a risk calculation based on signals received from elsewhere (such as a password change event). In the case of a password rotation or signal from other parties that the password has been compromised, you would expect that the current access token would continue to work for some short period of time, after which the refresh would result in a failure (typically sending the user back to a login page in their browser).

motohagiography 3y ago
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.

by dwaite 3y ago

motohagiography 3y ago

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.