OAuth Grant Types and Flows Reference
An OAuth grant represents how a client obtains authorization to request an access token. Choose a flow by client capability and actor, then follow the authorization server's exact profile.
Authorization code with PKCE
This is the primary interactive flow for browser, mobile, desktop, and server-rendered applications. The client sends the user to the authorization endpoint, receives a short-lived one-time code through a registered callback, and exchanges it at the token endpoint. PKCE binds the exchange to a high-entropy verifier held by the initiating client. Validate state, redirect URI, issuer, and the returned tokens.
A confidential web backend can also authenticate itself at the token endpoint. Public applications cannot keep a client secret, so embedding one in JavaScript or an installable binary adds no confidentiality. Use the provider's public-client registration and PKCE requirements.
Client credentials
A confidential client uses client credentials when acting as itself rather than on behalf of a signed-in user. Typical uses include internal service calls and scheduled machine operations. Scope the client narrowly, rotate its secret or key, and separate environments. Do not use client credentials to impersonate end users or expose the credential to frontend code.
Refresh tokens
A refresh token lets an authorized client obtain new access tokens without repeating user interaction. It is a high-value credential and needs encrypted transport, secure server-side or platform storage, bounded lifetime, revocation, and rotation where supported. Store a rotated replacement atomically and coordinate concurrent refreshes so one worker does not invalidate another worker's copy.
Device authorization
The device authorization flow supports input-constrained devices. The device obtains a user code and verification URI, displays them, and polls the token endpoint within the provider's interval and expiry rules while the user authorizes on another device. Never ask the user to enter credentials into the constrained device, and slow polling when instructed.
Legacy flows
The implicit flow returned tokens through the browser authorization response and lacks the stronger code exchange used by authorization code with PKCE. The resource-owner password credentials grant asks the client to collect the user's password. Do not introduce these flows into new applications. Migrate legacy integrations according to provider guidance without weakening redirect or token validation.
Scopes, resources, and audiences
Scopes represent delegated permissions under provider semantics. Request only what the current feature needs and use incremental consent where available. The intended API can be selected through an audience or resource parameter depending on the provider. An access token issued for one resource should not be accepted by another merely because the issuer is trusted.
Tokens and validation
An access token can be opaque or structured; clients should not depend on decoding unless the provider contract permits it. APIs validate token format, issuer, signature where applicable, audience, expiry, token type, scopes, permissions, and resource ownership. An ID token is for authentication to the client and is not a general API access token.
Frequently Asked Questions
What should public apps use?
Authorization code with PKCE.
When should client credentials be used?
For a confidential client acting as itself.
Should new apps use password grant?
No. Choose a modern flow that keeps user credentials at the provider.