One reason is that the protocol itself is more complicated than you've described.
For example, Google won't give you a long-lived access token. You need a refresh token, and then you use that to retrieve access tokens, and continue doing that as they expire.
Why? I have not a flipping idea. Please, HN enlighten me how refresh/access token dichotomy improves the API.
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.
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.
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.
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:
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.
For example, Google won't give you a long-lived access token. You need a refresh token, and then you use that to retrieve access tokens, and continue doing that as they expire.
Why? I have not a flipping idea. Please, HN enlighten me how refresh/access token dichotomy improves the API.