OAuth Grant Types

What OAuth Grant Types Actually Define

oauth grant types are not just different login buttons. They define which party is allowed to request tokens, what proof it must present, and how the application moves from an initial trust decision to an access token that can be used against an API or resource server.

The practical effect is that each grant type draws a different boundary around consent, client identity, user involvement, and token issuance. That is why the choice of grant type changes both security posture and operational design, not just implementation syntax.

In practice, the grant type is where OAuth turns an abstract authorization model into a concrete exchange pattern. A browser redirect, a back-channel client assertion, a device activation step, or a refresh token exchange all answer a different question about who is acting and who is trusted.

Common OAuth Grant Types and What They Are For

The authorization code flow is the most common user-facing pattern because it separates the front-channel browser interaction from the token exchange. The client receives a short-lived code, then redeems it at the token endpoint, which reduces the exposure of access tokens during the authorization step.

The client credentials grant is used when the application itself is the actor, such as service-to-service or machine-to-machine access. In that flow, the client authenticates as the client, not as a user, so the resulting token represents the application’s own authority rather than delegated user consent. See RFC 6749: The OAuth 2.0 Authorization Framework for the core standard that defines this model.

The device code flow is designed for input-constrained devices where a separate browser or phone completes the user interaction. Refresh token grant usage, meanwhile, extends a session without repeating the full interactive flow, which is convenient but also increases the value of token protection and revocation discipline.

Why Grant Type Choice Changes Security Boundaries

Grant types matter because they change the trust assumptions around the client, the user, the browser, and the token endpoint. A flow that relies on redirects and user consent has different attack opportunities than one that relies on client authentication or assertion-based delegation.

That difference affects how you think about phishing resistance, token leakage, replay risk, and whether the application is acting on its own behalf or on behalf of someone else. It also affects whether secrets, certificates, or signed assertions are part of the authentication story, and whether token binding or sender-constrained protections are worth adding.

For teams that use OAuth to authorize APIs, the grant type is often the first place where architectural mistakes become security issues. Weak client authentication, over-broad scopes, and confused delegation paths can turn a valid token exchange into an abuse path even when the protocol itself is implemented correctly.

How to Choose the Right Grant Type

Choose the grant type based on who or what is actually requesting access, whether a human must be present, and how sensitive the downstream resource is. A user-mediated application, a headless integration, and a device with no keyboard are different trust problems, so they should not be forced into the same flow.

It is also important to treat grant selection as part of broader token governance. If a flow produces long-lived refresh tokens, supports delegation, or allows broad reuse across apps and resources, you need clearer controls around consent, revocation, audience restriction, and client authentication than you would for a short-lived interactive exchange.

Modern deployments should also confirm that the chosen grant still matches current OAuth guidance, because industry practice evolves and some older flows are now discouraged or restricted in favour of safer alternatives. For a concise, implementation-oriented overview of supported flows and common security mistakes, the OAuth 2.0 and OpenID Connect Guide for Identity Teams is a useful companion reference.

Risk and Threat Considerations

OAuth grant types can be abused when they are chosen for convenience instead of fit. The most common failure modes are consent phishing, token theft, over-broad delegated access, and replay of tokens or refresh tokens after an initial compromise.

Failure mechanism: An attacker targets the grant path that offers the easiest path to a valid token, then abuses user consent, weak client authentication, or poor token handling to retain access beyond the original interaction.

Impact: Stolen or over-permissive tokens can expose mailboxes, SaaS data, APIs, and downstream integrations, often without immediately triggering a password reset or traditional account compromise signal.

Practitioner Guidance

Why practitioners should care: Grant type choice is a control decision, not just a developer preference. The selected flow determines whether access is user-delegated, application-only, or delegation-on-behalf-of, which in turn shapes scope design, token lifetime, and revocation strategy.

What to watch for: Review whether the implementation still uses the least risky flow that fits the use case, especially when a headless integration, delegated automation, or device-based sign-in is involved. The SaaS-to-SaaS and OAuth App Governance Guide helps map grant usage to consent, scope, and revocation governance, while the Device Code Phishing Guide is useful when device flows are in scope.

Practitioner takeaway: The safest OAuth design is the one whose grant type matches the real actor, minimizes standing access, and makes token abuse easier to detect and revoke.

Related resources from NHI Mgmt Group

• What is the difference between Authorization Code and Implicit grant types in OAuth?
• OAuth Connected App
• When should organisations revoke an OAuth grant or third-party app permission?
• When should organisations treat an OAuth grant as a security incident?