v1oauth context
Revocation
POST /v1/oauth/revoke — RFC 7009 token revocation with an empty, uncacheable response.
POST {issuer}/revoke revokes a token per RFC 7009. The body is application/x-www-form-urlencoded.
Request
| Parameter | Type | Required | Notes |
|---|---|---|---|
token | string | ✅ | Token to revoke |
token_type_hint | string | Optional | access_token or refresh_token; a lookup hint only |
client_id | string | ✅ (with none) | Mandatory for public clients |
The client must authenticate first, using the same methods as the token endpoint.
curl -X POST 'https://id.example.com/v1/oauth/revoke' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-u "$CLIENT_ID:$CLIENT_SECRET" \
-d "token=$ACCESS_TOKEN" \
-d 'token_type_hint=access_token'Response
200 with an empty body.
An empty response still must not be cached
RFC 7009 does not mandate Cache-Control, but "empty response = cacheable" is a proxy's default assumption.
If an intermediary caches this 200, the next request revoking a different token gets the same "success" while the actual revocation never happened — the client believes it is signed out, and the token is still alive.
Behaviour
| Rule | Notes |
|---|---|
| Idempotent | Revoking an already invalid token also returns 200 |
| No result disclosure | The caller is not told whether the token was already invalid, so the endpoint cannot be used as a probe |
| Refresh tokens | Revoking a refresh token also invalidates the access tokens it issued |
Related
- Revoking an authorized application (user side): Authorized applications
- Revoking a session (first party): Sessions