OAuth 2.1 & grants
Supported grant types and how the Authorization Code, Client Credentials, and Refresh Token flows behave.
Supported grant types
| Grant type | Description |
|---|---|
| Authorization Code + PKCE (S256) | Primary flow for user-facing apps. PKCE is mandatory. |
| Client Credentials | Machine-to-machine access. Scoped to registered clients. |
| Refresh Token | Silent token renewal with rotation on each use. |
OAuth 2.1 posture
Authorization Code without PKCE is not supported — this is intentional per OAuth 2.1. Only
S256 code challenges are accepted; plain is rejected.
Authorization Code + PKCE
The primary flow for user-facing apps. The client sends a code_challenge at /api/authorize; the
user authenticates; the server issues a single-use authorization code bound to the challenge and the
exact redirect URI. At /api/token, the client proves possession with the code_verifier.
- Authorization codes are single-use and short-lived, with PKCE verifier validation (S256 only) and exact-match redirect URI validation.
- When the
openidscope is granted, the token response also includes a signedid_token. - Pass a
resourceparameter to bind the token's audience — see resource indicators.
Client Credentials
Machine-to-machine access for backend services. The client authenticates with its client_id and
client_secret and receives an access token scoped to its grants.
Public clients can't use client_credentials
A public (PKCE-only) client with token_endpoint_auth_method: none has no secret, so
client_credentials is rejected for it. See Clients.
Refresh Token (rotation)
Refresh tokens are long-lived but single-use with rotation — each refresh invalidates the old token and issues a new pair.
- Revocable (the full token plus its associated refresh chain).
- Scope is preserved through rotation.
- User environment access is re-checked on every refresh: revoking a user's access to a client's environment stops new tokens immediately rather than at the refresh token's natural expiry.