Choosing a Grant Type
Which OAuth grant type to use and what each one supports.
OAuth defines several grant types — each designed for a different kind of application or use case. Pick the one that matches how your app runs.
| Grant type | Best for | Refresh tokens | User context |
|---|---|---|---|
| Authorization Code | Web apps, mobile apps, SPAs | Yes (with offline_access) | Yes |
| Implicit | Legacy browser apps only | No | Yes |
| Device Code | CLIs, smart devices, headless apps | No | Yes |
| Client Credentials | Backend services, daemons | No | No |
| Service Token | Trusted internal services | No | No |
For a deeper explanation of OAuth concepts, see the OAuth 2.0 documentation.
Authorization Code
The standard flow for most apps. The user is redirected to the auth server, authenticates, and your app receives a short-lived code that you exchange for tokens.
Use this when your app:
- Runs in a browser, on mobile, or as a server-rendered web app
- Needs to act on behalf of a user
- Needs long-lived access via refresh tokens
PKCE (code_challenge + code_verifier) is strongly recommended for public clients (SPAs, native apps) that cannot safely store a client secret.
Requires supports_code to be enabled on your client.
Implicit
A simplified browser-only flow where the access token is returned directly in the URL fragment — no code exchange step. There are no refresh tokens.
Only use this if you are maintaining a legacy integration. Authorization Code with PKCE is the preferred replacement for all browser-based apps.
Requires supports_implicit_grant to be enabled on your client.
Device Code
Designed for devices that can't open a browser — CLIs, smart TVs, set-top boxes. The device displays a short code and a URL; the user visits the URL on another device and approves the request while the device polls for a token.
Requires supports_device_code_grant to be enabled on your client.
Client Credentials
No user is involved. Your service authenticates directly with its own client_id and client_secret and receives an access token scoped to that service.
Use this for backend-to-backend calls where there is no user session.
Service Tokens
Similar to Client Credentials but built around pre-issued JWT tokens tied to a named service account. The service account is created by an admin with a fixed set of scopes, and the resulting token is used to exchange for short-lived access tokens.
Use this for trusted internal services that need fine-grained, auditable access.
Limits & constraints
- Refresh tokens require the
offline_accessscope andsupports_refresh_tokenenabled on your client. - Client secrets must be kept server-side. Never embed them in a browser or native app.
- Token lifetimes: access tokens are valid for 3600 seconds. Device codes expire in 300 seconds. PAR requests expire in 600 seconds.
- Redirect URIs must match the registered URI exactly (scheme + host). Additional query parameters are allowed but the base URI must be pre-registered.