Token revocation
The calendar has arrived, and you would rather the printer did not keep access to your photos for another year. On the printer's account page, you select Disconnect photo account.
The printer could simply delete the tokens it stored. You would see the connection disappear, but nothing would change at the photo service. The grant would still exist, and a copy of the refresh token anywhere else, in an old backup or in a thief's hands, would still work. Disconnecting properly means telling the authorization server that the printer has finished with its access.
Telling the server you are done
The printer sends its refresh token to the photo service's revocation endpoint, authenticating exactly as it does at the token endpoint. All domains, credentials, and tokens in these examples are fictional.
POST /revoke HTTP/1.1
Host: auth.photos.example
Authorization: Basic cGhvdG8tcHJpbnRlcjpkZW1vLW9ubHktbm90LWEtcmVhbC1zZWNyZXQ=
Content-Type: application/x-www-form-urlencoded
token=demo-refresh-token-4
&token_type_hint=refresh_tokenThe body names the token and, optionally, hints at its type, which helps the server look it up. The printer sends its refresh token because that is the credential that keeps the connection alive. The server checks that the token was issued to the client making the request, then invalidates it at once.
The answer carries nothing beyond its status:
HTTP/1.1 200 OKThe server returns 200 when it revoked the token, and also when the token was unknown, expired, or already revoked. That is not carelessness. The client wanted the token to stop working, and it has, so an error would give the client nothing useful to do. It also makes the request safe to repeat. If the printer's first attempt times out, it sends the same request again without needing to know what happened to the first.
Real errors are few. invalid_client means client authentication failed, as it would at the token endpoint. A token issued to a different client is refused with an error rather than revoked, because one client may not end another's access. unsupported_token_type means the server does not revoke that kind of token, which can happen when a client tries to revoke an access token at a server that only revokes refresh tokens. A 503 means the server could not handle the request right now, and the client must assume the token still works and try again later.
That last case shapes the order of the printer's own work. It marks the connection as disconnected straight away and stops using its tokens. It keeps the refresh token only in a queue of pending revocations and deletes it once the server has answered 200. Deleting first would leave a working token at the photo service and no way left to revoke it.
What revocation reaches
Revoking the refresh token ends the printer's ability to obtain new access tokens. What happens to access tokens already issued depends on the server and on the token format.
When a refresh token is revoked and the server supports revoking access tokens, the specification says it should also invalidate the access tokens issued under the same grant. The reverse is weaker. Revoking an access token may leave the refresh token working, and the server is only permitted, not required, to revoke that too. A client that wants to end everything sends the refresh token, and it can send its current access token as well, which does no harm.
Even then, revocation only reaches tokens that someone checks:
| Token | After revocation |
|---|---|
| Refresh token | Refused at the token endpoint from that moment. |
| Reference access token | Reported as inactive by introspection at once. An API that caches answers accepts it until its cached answer expires. |
| JWT access token validated locally | Still accepted until its exp, because the API never asks the authorization server. |
The last row is the cost of local validation that the Token formats and validation lesson described. If the printer's newest access token was issued at 09:00 with a ten-minute lifetime and you disconnect at 09:04, an API that validates it locally will accept it until 09:10. Short lifetimes keep that window small. For operations where six minutes is too long, such as deleting photos, an API can introspect even JWT access tokens before acting, trading a round trip for a current answer.
Nothing reaches backwards past the API either. Photos the printer downloaded before you disconnected are copies in its own systems. As the Trust boundaries lesson pointed out, stopping future requests cannot make those copies disappear.
Two ways to disconnect
So far, the printer started the revocation. You can also end the connection from the other side, on the photo service's list of connected applications, and the two are not the same.
When the printer revokes, the client is declaring that it no longer needs its tokens. It might do this because you asked, because you closed your printer account, or because it suspects its own token storage has been exposed and wants every token it holds to stop working. Revocation by the client starts from a token the client still has and can name. What else ends with it, such as the access tokens of the same grant or the grant itself, is up to the authorization server's policy.
When you remove the connection at the photo service, the authorization server ends the grant itself, along with every token family under it. That works even when the printer is offline, broken, or no longer trustworthy, which is exactly when you most want it. The printer is not told. It finds out the next time it uses its tokens: the photo API answers invalid_token, and the next refresh fails with invalid_grant. The refresh token grant lesson described the right response, marking the connection as needing attention and inviting you to reconnect if you want the calendar back.
A well-behaved client does both jobs. It revokes when its own reasons say so, and it accepts gracefully that someone else may end its access first.
Throughout these lessons, the printer has been a backend on its own servers, holding its tokens where no browser or phone could see them. Many clients are not built that way. Some run entirely in a browser, some on phones, some in a terminal, and some are services calling other services. Where a client's work runs changes what it can protect, and that is where Application architectures begins.