Read success and failure responses carefully
03HTTP 200 deliberately covers both a successfully revoked token and an invalid token. It is not a token-validity oracle or a promise about every related token.
The token must be assumed still to exist. An example Retry-After: 60 gives expected service delay; retry reasonably rather than assuming logout completed at the server.
Source for this drawing: RFC 7009 · Read RFC section 2.2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Idempotent effect
- Repeating cleanup need not change an already invalid token again, even though POST is the request method.
- Retry-After
- An optional HTTP response field that can indicate how long a service expects to be unavailable.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
For a valid request, the authorization server returns HTTP 200 when revocation succeeds or the submitted token is invalid. The client ignores the response body.
- For a valid request, the authorization server returns HTTP 200 when revocation succeeds or the submitted token is invalid. The client ignores the response body.
- After receiving HTTP 200 the client must not try to use the token again. A repeated request for an already invalid token can therefore receive the same success status.
- unsupported_token_type means the server cannot revoke the presented token type, such as an access token when only refresh-token revocation is supported. It does not mean the hint was unrecognized.
- Errors follow RFC 6749 §5.2, generally HTTP 400 unless otherwise specified. On HTTP 503 the client must assume the token still exists and may retry after a reasonable delay; Retry-After may indicate expected unavailability.
The two 200 branches assume the request has passed applicable client/ownership validation; HTTP 200 is not guaranteed for malformed or unauthorized requests. For failed Basic client authentication RFC 6749 §5.2 requires HTTP 401 with a matching WWW-Authenticate header. A 503 does not confirm revocation or guarantee that the token is otherwise usable. The illustrated Retry-After value of 60 seconds is a chosen example, not a required retry interval.
Read the RFC section ↗