Under RFC 7009, what does revoking an OAuth 2.0 refresh token also invalidate, and how does revoking an access token differ?

## The setting Picture a set-top box in a hotel room that lets a guest sign in to their own media account. The room's occupant changes every few nights, so at checkout everything that box holds has to stop working — and "everything" is the operative word, because during the stay the box will have exchanged its refresh token for several access tokens. That is precisely the case RFC 7009's cascade addresses: one revocation call, and the question of how far its effect reaches. ## The unit is the authorization grant When a resource owner authorises a client, the result is an **authorization grant** — the standing permission. The credentials that flow from it are its instruments: one refresh token representing the grant over time, and a succession of short-lived access tokens minted from it. The cascade is defined in terms of that grant, not in terms of a session or a user. | you revoke | the specification's word | what else goes | |---|---|---| | a refresh token | **SHOULD**, where the server supports revoking access tokens at all | every access token issued under the same authorization grant | | an access token | **MAY** | the refresh token of that grant, at the server's discretion | Two details in that table are easy to lose and both are load-bearing. The strong direction is a **SHOULD**, not a MUST, and it is further **conditioned** on the server supporting access-token revocation in the first place. The weak direction is a plain **MAY**, which means a conforming server may do nothing beyond killing the one token it was given. ## Why the asymmetry is the right way round - **The refresh token is the grant's handle.** While it lives, the client can keep minting access tokens, so revoking access tokens while leaving it alive accomplishes almost nothing — the client simply refreshes. - **Revoking the refresh token is an intent statement.** It is what "remove this application's access" means in practice, so honouring it half-way, with live access tokens still circulating, would contradict the user's action. - **An access token is one of many.** A client may legitimately hold several, for different resources; discarding one because it leaked need not end the relationship, so the specification declines to force that. ## What this means when you are the one calling 1. **To end an application's access, revoke the refresh token.** That is the call whose defined consequence reaches the grant's access tokens. 2. **Do not enumerate access tokens.** Revoking them one by one is both incomplete — the client refreshes — and unnecessary. 3. **Do not rely on the reverse direction.** If you revoke an access token because it leaked, assume the refresh token is still alive and revoke it explicitly. 4. **Budget for the tail.** The strong direction is a SHOULD and it is conditional, so plan on the possibility that a live access token outlives the call until its own expiry. ## The honest caveat about timing A success answer says the authorization server has recorded the revocation. In a deployment spread across several servers, agreement is not always instantaneous, so a short propagation delay between the call and universal effect is normal rather than a defect. Treat the endpoint as a fast containment control with a measurable lag, not as an atomic switch — and let that lag, rather than optimism, set how long your access tokens are allowed to live. ## Reversals to check yourself against This material stays grammatical when stated backwards, so read your own sentence in the direction you wrote it: - It is **not** "revoking an access token MUST kill the refresh token". That direction is the weak one, and it is a MAY. - It is **not** "both directions are MUST". Neither is. - The cascade reaches tokens of **the same authorization grant**, not every token the user ever had. A second grant, from a different client or a different consent, is untouched. - Revoking a refresh token does **not** withdraw the user's consent record at the authorization server. It ends the credentials; whether the standing consent survives is a separate matter the endpoint does not speak to. ## The interview version If you remember one sentence, remember the asymmetry with its qualifier: **refresh to access is a SHOULD, where the server revokes access tokens at all; access to refresh is a MAY.** Everything else in this answer is the reasoning that makes that pair memorable.