Module revoke 

RFC 7009 OAuth 2.0 Token Revocation (POST /revoke).

Two properties drive every decision in this module:

1. Revocation is idempotent and never an oracle. RFC 7009 section 2.2 requires HTTP 200 both when a token was revoked and when the client “submitted an invalid token” – unknown, already revoked, expired, or issued to somebody else. A caller must not be able to tell those apart from the response, so the success path below deliberately discards the store’s did-it-delete boolean.
2. A client may only revoke its own tokens. RFC 7009 section 2.1 makes the server “verify whether the token was issued to the client making the revocation request”. That check is the client_id predicate inside crate::sqlite::SqliteStore::revoke_refresh_token’s DELETE, so a request naming somebody else’s token deletes nothing – and, per (1), still answers 200.

Only refresh tokens are revocable. Access tokens are self-contained EdDSA-signed JWTs (see crate::jwt) validated purely by signature and expiry, with no server-side record to delete and no denylist to add to, so token_type_hint=access_token is answered with RFC 7009 section 2.2.1’s unsupported_token_type rather than a 200 that would misrepresent what happened. Revoking the refresh token still severs renewal; outstanding access tokens age out on their own (one hour by default).

Functions

revoke

POST /revoke – RFC 7009 token revocation.