RFC 6749 — Versola Docs
/docs
Pre-1.00.7.5versola.ioGitHub

RFC 6749

OAuth 2.0 Authorization Framework — grants, client authentication and endpoints that Versola implements.

Specification: RFC 6749

OAuth 2.0 is the industry-standard protocol for authorization. It lets an application obtain limited access to a resource on behalf of a user or of itself.

Status

Partially implemented. Checked claims: 26 of 28.

Grant types

  • Authorization Code Grant (PKCE required, except for confidential clients of a standard tenant)
  • Client Credentials Grant
  • Refresh Token Grant
  • Device Authorization Grant (RFC 8628) — not implemented

Removed by design, per OAuth 2.1:

  • Implicit Grant
  • Resource Owner Password Credentials Grant

PKCE

  • code_challenge required on every authorization request, except for confidential clients of a standard tenant
  • code_verifier required on the token exchange whenever the code was issued against a challenge, and refused when it was not
  • S256 challenge method, with code_challenge_method required whenever a challenge is sent
  • plain challenge method — not accepted

Refresh tokens

  • Refresh token rotation — a new refresh token is issued on every use; a sender-constrained grant is renewed in place instead
  • The old refresh token is retired immediately on use
  • The whole token family is revoked when a retired refresh token is presented again (RefreshTokenFlowSpec)
  • Idempotency-Key on a refresh request lets a client retry safely after a lost response

Authorization codes

  • Codes are single use; presenting a used code revokes the tokens issued from it
  • A code is redeemable only by the client it was issued to, for the same redirect_uri

Bearer token usage

  • Access tokens accepted in the Authorization header only
  • Tokens in URL query parameters or in the request body are refused
  • Short-lived access tokens with a per-client TTL
  • Cache-Control: no-store and Pragma: no-cache on token endpoint responses

Client authentication

  • client_secret_basic — Authorization: Basic header
  • client_secret_post — client credentials in the request body
  • private_key_jwt — see RFC 7523
  • tls_client_auth and self_signed_tls_client_auth — see RFC 8705
  • client_secret_jwt — not implemented

Endpoints

  • GET and POST /authorize — Authorization endpoint
  • POST /token — Token endpoint
  • POST /par — Pushed Authorization Requests (RFC 9126)
  • POST /revoke — Token Revocation (RFC 7009)
  • POST /introspect — Token Introspection (RFC 7662)
  • GET /.well-known/oauth-authorization-server — Server Metadata (RFC 8414)

Notes

  • Which clients may authenticate with which method depends on the tenant’s security profile. A fapi2 tenant admits only private_key_jwt and the two mutual TLS methods.
  • A public client on a standard tenant authenticates with client_id alone at /token and /revoke, but never at /introspect.

Where to look

The OpenAPI reference lists the OpenAPI files for /authorize, /token, /par, /introspect and /revoke.