It's really trying to solve a problem they created by statlessly handing out tokens instead of keeping session state on the backend - they have no way to revoke a token once issued, so long lived tokens are a liability. Solution? More complexity! Hand out very short lived tokens, along with a slightly longer lived refresh token, which only allows you get a new bearer/access token.

Don't they still require some state to be able t invalidate refresh tokens?

Yes, but checking refresh tokens will occur much less frequently than checking access tokens. So you can imagine, for example, access tokens being JWT, so they are cheap to check. But every so often you have to validate the refresh token against MySQL (or BigQuery or what-have-you), which is more expensive.

That's all clear to me. But technically there exists a method to revoke an issued token. It's just that long lived tokens mean potentially lots of them == increased storage cost. It would be pretty silly not to check for revocation. How would one implement logout otherwise? Relying on just clearing session cookies? What if I obtained those cookies using something else than a browser and I can hold on to the cookie jar? Not checking for revocation == doing it wrong.

The purpose of a refresh token to allow the app to short circuit the login process. Regardless of how long the token is issued for. It's perfectly okay to ignore refresh tokens altogether, if one wants to.

The whole point of access tokens is to not do expensive checks on every request. Signature checks out and isn't expired - you are free to go. This is a core design thing of OAuth, once access tokens are out the door they are very hard to stop, so only let them last for 5 or 10 mins and use refresh tokens to get new access tokens.

Refresh tokens are your chance to do all the expensive checks - maybe you are IP restricted or want to step up with MFA etc etc. Check revocation etc

Login state for the identity provider and for the client application are different. Cookies are a reasonable way to implement it. Cookies + session storage backend will allow you delete sessions on the server side if you are worried about users keeping themselves logged in (?).

Your app is also responsible for deciding who has access. The identity provider is just handling the “is this person who they say they are” part.

Checking for revocation is checking whether the IdP still thinks that token identifies the user correctly. I don’t think it’s universally true or desirable that refresh tokens get revoked on logout. I don’t necessarily want logging out of Gmail to log out of Spotify just because I used Google auth for both.

You're free to handle a billion qps in authentication requests if you want. I don't suggest it.

Greatly reducing hosting costs at the expense of making someone else do a little more work sounds like a win to me.

Don't the clients have to do a billion qps as their retrieve access/refresh tokens from their data stores?

Yeah, but it's a negligible rounding error of cpu time for each client.

Distributing this work ironically makes it much easier to centralize the authentication.

Very simple, actually. Access tokens are short-lived and are irrevocable - google services only check validity and expiration of those tokens.

Refresh tokens are more like session tokens/cookies - those get checked every time. At Google scale, checking it probably expensive, so they are using refresh tokens.

These aren't for end-user or development experience, those are for AS performance.

That just pushes the problem around, yes?

So now the client servers have store/check the lifetime of tokens rather than resource servers.

Even without refresh tokens, clients need to check lifetime. If the token is opaque and the lifetime is unknown, it is no different from a session cookie.

> Does that actually improve OAuth as a whole?

Like I said, this is an improvement for whoever is validating tokens and only them. Refresh tokens are not hard to use, not sure what's the confusion here:

`token = token.is_expired ? refresh_token() : token`

That's all. Even in wordy rust, it doesn't take much:

https://docs.rs/yup-oauth2/6.5.1/src/yup_oauth2/authenticato...

Are you mad that, unlike with opaque token, you know ahead of time when it's expired for sure rather than when you got 401?

> Why? I have not a flipping idea.

https://www.rfc-editor.org/rfc/rfc6749.html contains everything you might want to know about OAuth in great detail :)

There's the issue of scale, but also the issue of reducing the scope of a compromise.

If a short-lived token gets leaked the damage is limited to the TTL of the short-lived token.

If you were to pass around the long-lived token you would need to do forensics on the entire life of the token to figure out how/if the credential was used.

Just think very pragmatically about the probability to keep a short-lived token secret across all the places it's being transmitted vs. keeping the single API that exchanges the refresh token for a short-lived token super secure.