RFC 7009 — Token Revocation — Versola Docs
/docs
Pre-1.00.7.5versola.ioGitHub
RUEN

RFC 7009 — Token Revocation

OAuth 2.0 Token Revocation — what POST /revoke does to refresh tokens and to access tokens, and where a revoked access token is rejected.

Specification: RFC 7009

Token Revocation lets a client tell the authorization server that a token is no longer needed. Versola accepts both refresh tokens and access tokens; what happens next differs between the two, as the lists below spell out.

Status

Implemented. Checked claims: 17 of 20.

Endpoint

  • POST /revoke endpoint (Section 2); other methods are refused
  • application/x-www-form-urlencoded request body; a request without token is refused with invalid_request

Token types

  • Refresh token revocation — the token is deleted at once, so it can no longer be exchanged, and every access token the same grant issued is revoked (see below)
  • Access token revocation — accepted; the revocation is pushed to the client’s back-channel endpoint, and edge rejects the token from then on
  • Access token rejected by auth itself after revocation — not implemented: /introspect and /userinfo keep honouring the token until it expires
  • Token type detected by format (a JWT is an access token, anything else is a refresh token)
  • token_type_hint is accepted and ignored, which the RFC permits (RevocationSpec)
  • unsupported_token_type — never returned; a value no client could hold is answered with 200

Where a revoked access token stops working

  • The client’s back_channel_logout_uri receives a signed event, versola:event:access-token-revocation, naming the token (revoked_jti) or the whole refresh-token family (revoked_fam) together with revoked_exp
  • edge stores the revocation in the revocations table and refuses the token before its exp, on every replica (see Edge; TokenRevocationFlowSpec)
  • A client with no back_channel_logout_uri — nothing is pushed, so a revoked access token stays valid until it expires; /revoke still answers 200

Client authentication

  • Client authentication required on every request (Section 2.1), including for a value no client could hold
  • client_secret_basic and client_secret_post
  • private_key_jwt (RFC 7523)
  • tls_client_auth and self_signed_tls_client_auth (RFC 8705)
  • invalid_client with HTTP 401 when authentication fails (RevocationSpec)
  • A public client authenticates with its client_id alone, except on a fapi2 tenant, which refuses it

Response behaviour

  • HTTP 200 on success (Section 2.2)
  • HTTP 200 for unknown, already revoked or malformed tokens (RevocationSpec)
  • A client cannot revoke another client’s token — invalid_client (RevocationSpec)

Notes

  • Access tokens are signed JWTs that auth does not record, so revoking one is a notification, not a state change inside auth. Resource servers that verify the signature locally need the edge check, or a subscription to the back-channel event, to learn about it.
  • A refresh token revocation names the token family, not individual access tokens, and bounds the entry by the client’s current access token TTL.

Where to look

The OpenAPI reference has the revocation specification, and Edge explains the revocation cache that rejects revoked access tokens.