OAuth 2.0 Token Revocation Response Limits for Invalid Tokens

Question

RFC 7009 Compliance and Token Enumeration
The OAuth 2.0 Token Revocation specification (RFC 7009) defines a standardized mechanism for clients to invalidate access and refresh tokens. A critical security requirement of this specification is the prevention of token enumeration, which ensures that an attacker cannot determine if a specific token is valid by observing the server's response.
In a distributed environment, the behavior of the revocation endpoint must remain consistent regardless of whether the token is currently active, has already expired, or was never issued. This creates a specific constraint on the HTTP response codes returned to the client during the revocation request.
Implementation Uncertainty
There is a design tension between providing detailed debugging information to legitimate clients and maintaining the security symmetry required to prevent enumeration. Specifically, the handling of 'phantom' tokens—those that are syntactically correct but non-existent in the data store—must be carefully managed.

What is the required HTTP response code when a client attempts to revoke a token that is already invalid or does not exist?
Does the specification allow for different response codes based on the token type (access vs. refresh) if the token is invalid?

Tasadduq Burney · Answer

RFC 7009 Compliance and Response Requirements
According to RFC 7009, the authorization server must respond with an HTTP 200 OK when a client attempts to revoke a token that is already invalid, expired, or does not exist in the server's data store.
The specification does not allow for different response codes based on the token type (access vs. refresh) when the token is invalid. Whether the token is a refresh token or an access token, the server must return an HTTP 200 OK to maintain security symmetry.

Preventing Token Enumeration
The primary driver for this behavior is the prevention of token enumeration. If a server returned a 404 Not Found for non-existent tokens and a 200 OK for valid ones, an attacker could programmatically test strings to identify which tokens are currently active in the system. By returning a success code regardless of the token's prior state, the server ensures that the response reveals nothing about the token's validity or existence.

Implementation Guidelines
To ensure compliance and security, follow these implementation constraints:

Uniformity: The response for a "phantom" token (syntactically correct but non-existent) must be identical to the response for a successfully revoked token.
  Avoid Detailed Errors: Do not include error messages in the response body that distinguish between "token not found" and "token successfully revoked."
  Scoped Failures: HTTP 400 (Bad Request) should only be used if the request is syntactically malformed or missing required parameters, not because the token value itself is invalid.

Verification Steps
You can verify the implementation of your revocation endpoint using the following test cases. The expected result for all three is an HTTP 200 OK with an empty response body:

Valid Token: Revoke a known, active token.
  Expired Token: Revoke a token that has already passed its expiration time.
  Non-existent Token: Revoke a randomly generated string that matches the expected token format.

Note: If your server currently returns 400 or 404 for non-existent tokens, it is non-compliant with RFC 7009 and susceptible to enumeration attacks.

OAuth 2.0 Token Revocation Response Limits for Invalid Tokens

RFC 7009 Compliance and Token Enumeration

Implementation Uncertainty

1 answer

RFC 7009 Compliance and Response Requirements

Preventing Token Enumeration

Implementation Guidelines

Verification Steps

Your perspective belongs here.

0 question comments