OAuth 2.0 is a flexible authorization framework, and understanding how OAuth 2.0 works requires understanding its grant types. Grant types (specified via the grant_type parameter in token requests) describe how a client obtains tokens from an authorization server, depending on the application type and its security capabilities. Each grant type is built around specific assumptions about the application, its environment, and its ability to store secrets securely. Selecting the right one is essential for building secure, reliable authentication and authorization flows.
This article explains the major OAuth 2.0 grant types that appear in modern applications, along with guidance on when each is appropriate. While some older grant types still exist for legacy reasons, most new applications rely on a small set of well-supported, security-focused grant types.
Why Grant Types Matter
The authentication needs of an application depend on its architecture, platform, and capabilities. A backend service can safely hold secrets, but a browser-based Single-Page Application (SPA) cannot. A native mobile app has different tradeoffs than a smart TV app. OAuth solves this by offering multiple grant types, each designed for a specific environment and security posture.
One of the most important distinctions is whether the client is public (unable to store secrets securely, such as SPAs and mobile apps) or confidential (able to protect secrets, such as backend services). Some grant types assume the client can authenticate with the authorization server; others are explicitly designed for clients that cannot.
Selecting a grant type that matches the client's capabilities is not just a design preference but is a foundational aspect of secure OAuth implementations. Using the wrong grant type can expose tokens, bypass key protections like Proof Key for Code Exchange (PKCE), or rely on assumptions that the client simply cannot fulfill. Using the right one gives you a safer, more reliable authentication model with far less room for error.
1. Authorization Code Grant with PKCE
The Authorization Code Grant (authorization_code) with PKCE is the recommended option for most applications that authenticate end users. With this grant type, the client directs the user to a browser-based login page hosted by the authorization server. After authentication, the server returns a short-lived authorization code that the client exchanges for tokens.
PKCE protects this exchange by ensuring the authorization code cannot be intercepted and reused by an attacker. Public clients such as browser-based SPAs, native mobile apps, and desktop applications must use PKCE because they cannot store client secrets safely. Confidential clients should use PKCE as well, since it prevents authorization code injection attacks that client authentication alone cannot stop.
Use the Authorization Code Grant with PKCE for:
- browser-based applications
- mobile and desktop applications
- any environment where users authenticate interactively
This grant type provides a strong balance of usability, compatibility, and security, making it the default choice for modern OAuth deployments. The non-PKCE version of the Authorization Code Grant still appears in older documentation, but modern OAuth guidance recommends using PKCE for both public and confidential clients.
2. Client Credentials Grant
The Client Credentials Grant (client_credentials) is designed for machine-to-machine communication where no user is involved. Instead of authenticating a person, the client authenticates itself to the authorization server using its own credentials. The resulting access token represents the application, not an end user.
This grant type is appropriate for:
- background jobs
- scheduled tasks
- backend services calling other services
- API-to-API communication
- microservices that need tokens to access shared resources
Because the access token represents the application, not an individual, this grant type should not be used for user authentication. Whenever you see a scenario where one service needs to call another on its own behalf, the Client Credentials Grant is likely the correct choice.
3. Device Authorization Grant
The Device Authorization Grant (urn:ietf:params:oauth:grant-type:device_code), often called the Device Code Grant, supports applications that cannot easily present a browser or accept meaningful user input. Examples include smart TVs, streaming devices, industrial terminals, and IoT appliances. These devices often lack keyboards or have limited input capabilities, making conventional browser-based authentication impractical.
With this grant type, the device displays a short code and a verification URL. The user opens the URL on a separate device — such as a phone or laptop — logs in, and approves the request. Meanwhile, the original device polls the authorization server and eventually receives an access token once the user has completed authentication.
Use the Device Authorization Grant when:
- the application lacks a full browser
- presenting a standard login screen is not feasible
- authentication must occur on a secondary device
This grant keeps credentials off constrained devices and maintains a secure and user-friendly authorization experience.
4. Refresh Token Grant
Access tokens are typically short-lived for security reasons. When an application needs long-term access on behalf of a user, the authorization server may issue a refresh token. The client can exchange this refresh token for new access tokens without requiring the user to log in again.
The Refresh Token Grant (refresh_token) is not a primary login mechanism; it exists solely to renew access after the initial sign-in. Applications may receive refresh tokens as part of another grant, such as Authorization Code with PKCE or Device Authorization. The term Refresh Token Grant refers specifically to the token endpoint call that exchanges an existing refresh token for a new access token.
Use refresh tokens when an application must keep a user signed in over extended periods or continue calling APIs after the original access token has expired. They are also useful when you want to avoid issuing long-lived access tokens altogether, allowing the system to maintain tight expiration policies without degrading the user experience.
Legacy and Deprecated Grants
OAuth 2.0 has evolved significantly since its original release in 2012, and not all grant types defined in early versions are still recommended today. Some older mechanisms remain in the specification for historical or compatibility reasons, but they no longer align with modern security guidance.
While you may encounter these grant types in existing systems, new systems should generally avoid them in favor of the modern approaches described above.
1. Resource Owner Password Credentials Grant (ROPC)
The ROPC grant (password) is now considered a legacy pattern. It allowed an application to collect a username and password directly, then exchange them for tokens. This approach no longer aligns with modern security guidance, since it bypasses the browser-based authorization experience that enables phishing protection, federated identity, and multi-factor authentication. The OAuth 2.1 draft removes this grant from the core specification, and new applications should not use it.
2. Implicit Grant (Deprecated)
The Implicit Grant (implicit) was originally introduced for early browser-based applications that could not securely store client secrets. Modern security recommendations — and the adoption of PKCE — make this approach unnecessary. OAuth 2.1 removes the Implicit Grant, and new applications should use the Authorization Code Grant with PKCE instead. Existing implementations may still encounter the Implicit Grant, but new development should avoid it.
Less Common Grant Types (Assertion Grants)
OAuth also defines specialized assertion grants, including the JWT Bearer (urn:ietf:params:oauth:grant-type:jwt-bearer) and SAML Bearer (urn:ietf:params:oauth:grant-type:saml2-bearer) profiles. Instead of redirecting a user through an authorization process, these grant types allow a client to exchange a previously issued, signed assertion for access tokens.
They are typically seen in enterprise or federation scenarios and are not commonly used when selecting grant types for typical application development.
Developers who want to dig deeper into the OAuth 2.0 specification can consult the OAuth 2.0 Authorization Framework (RFC 6749).
Final Thoughts
Understanding how OAuth 2.0 works requires understanding why its grant types exist and which scenarios they are designed to support. Each grant type reflects assumptions about the client, its capabilities, and how tokens should be issued securely. Choosing the right grant type strengthens your application's security posture while preserving a clean, predictable user experience.
By using the Authorization Code Grant with PKCE for interactive applications, Client Credentials Grant for machine-to-machine scenarios, Device Authorization Grant for constrained devices, and Refresh Token Grant (refresh tokens) for long-lived access, most modern systems can operate securely without relying on legacy mechanisms. ROPC and the Implicit Grant remain part of the broader OAuth landscape, but they are not recommended for new development.
For deeper guidance on identity systems in modern applications, the resources available at Duende Software offer an excellent path forward.