Token revocation

Defeats the purpose of a token. You've just reinvented the session cookie.

> It is now recommended to have a refresh token with an expiration date, that can be long, and have that refresh token be single use. When it is sent to the authorization server to get a new access token, the authorization server will revoke the old refresh token and issue new refresh and access tokens.

I've been wondering briefly about this specific flow. It seems prone to a problem: if the refresh request gets sent successfully (and then invalidated), but the reply is not received for any reason, then the authorization chain is broken. There's no way to get a new token. Is there a good 'standard' way to handle this problem?

On brief reflection, while writing this comment, it seems like the only solution is to fall back to some other (long-lived) identity (from which the original OAuth token was derived). But that can be an inconvenient fallback.

> The interesting property here is that if the authorization server sees the same refresh token twice, it means that the token was stolen: either the thief or the legitimate client already used the refresh token, and the other one is now requesting an access token too. In that case, the authorization server must revoke all current refresh and access tokens for this client.

That seems like an invalid conclusion to draw though. Multiple requests could simply be caused by failures (including race conditions). Should the refresh token really be single-use?

One alternative that I could imagine is that the refresh token can be used multiple times, but whenever it's used, then only the most-recently created tokens remain valid -- with all prior tokens (that were created from it) being invalidated. This would enable token refresh to survive failures, while also making any tampering evident (due to the appearance of unexpectedly invalidated tokens).

Edit: Another strategy might be to link together all access tokens into one "session": whenever a refresh token is used to create new tokens, those all count as the same "session" and the session is what's invalidated. (The 'session' would be established during the process issues the first tokens).

One threat model that people worry about is whether credentials can be lifted from a compromised machine once and then used to have permanent ongoing access -- without requiring ongoing access to the compromised machine.

If you have ongoing access to a compromised machine, then all bets are off. However, one security goal in these kinds of situations is to be able to rapidly "lock down" and quarantine a suspected breach; which in this case means revoking all of the credentials that the machine had access to. You want to be able to do this, and then once you've done this, be confident that the attacker has no further access.

If an attacker can lift a 'refresh token' from the machine, and use it to generate their own unlimited number of new credentials (that can be periodically refreshed indefinitely), then the challenge of revoking compromised credentials is more difficult; by the time you add a compromised token to a refresh list, it may have already been used to create another.

So you can't just say: "What credentials were on the machine? Revoke them all." That's not enough if the attacker can create their own new credentials using the refresh token.

If access tokens can be used to create additional access credentials, then it's more difficult to track and revoke all of them -- you'd need to revoke some kind of 'session' that all of the access tokens can be attributed to.

A blacklist checker is also a single point of failure.

What do we call a token that's stored in a cookie, sent via the HTTP 'Authorization' header to the API with each request, and Redis-cached on the server for say 5 minutes after looking it up in the users/token service? I still call it a token, just not a JWT. Maybe I should change my terminology?