Which OAuth grant type should I use?

For apps that redirect a user, use Authorization Code with PKCE — it now suits both confidential and public clients. For machine-to-machine calls use Client Credentials, and for input-constrained devices like TVs use the Device Authorization grant. Use Refresh Token to renew access without re-prompting.

Why is the Implicit grant deprecated?

Implicit returned the access token directly in the redirect URL fragment, where it can leak through browser history, referrers and logs, and it offered no client authentication. OAuth 2.1 and the Security BCP remove it in favour of Authorization Code with PKCE.

What problem does PKCE solve?

PKCE (Proof Key for Code Exchange) binds the authorization code to a one-time secret the client generates. Even if an attacker intercepts the code on the redirect, they cannot exchange it without the original code_verifier, which defeats authorization-code interception on public clients.

Does Client Credentials involve a user?

No. The client authenticates as itself to access its own resources, with no end-user and usually no refresh token. It is the right choice for backend services and cron jobs, but never for acting on behalf of a specific user.

Should I still use the Password grant?

Avoid it. The Resource Owner Password Credentials grant hands the user's password to the client, which breaks SSO, MFA and consent. OAuth 2.1 removes it; it survives only for migrating legacy first-party apps and should be retired.

What is the OAuth 2.0 Grant Types Reference?

Reference for OAuth 2.0 grant types — authorization code, PKCE, client credentials, refresh token, device, implicit and password — each with its step-by-step flow, spec and security guidance under OAuth 2.1. It runs free in your browser on Gera Tools, with nothing uploaded.

OAuth 2.0 Grant Types Reference

Name: OAuth 2.0 Grant Types Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

Pick the correct OAuth 2.0 grant

A grant type is the path an OAuth client takes to obtain an access token. The right one depends on what the client is: a web app that can redirect a user, a single-page or mobile app that cannot keep a secret, a backend service acting on its own behalf, or a constrained device like a TV. This reference describes each grant with its step-by-step flow and the security notes that matter, flagging which grants OAuth 2.1 keeps and which it removes.

Grant types at a glance

Grant	User involved?	OAuth 2.1 status	Best for
Authorization Code + PKCE	Yes	Recommended	Web, mobile, SPA
Client Credentials	No	Recommended	Machine-to-machine
Device Authorization	Yes (on separate device)	Retained	TVs, CLIs, IoT
Refresh Token	Indirectly	Retained	Renewing access
Implicit	Yes	Removed	— (do not use)
Resource Owner Password	Yes	Removed	— (legacy only)

How the redirect-based flow works

In the Authorization Code flow, the client redirects the user to the authorization server’s /authorize endpoint with its client_id, redirect_uri, scope, state, and — with PKCE — a code_challenge derived from a random code_verifier. After the user consents, the server redirects back to the client with a short-lived code. The client then POSTs that code plus the original code_verifier to the /token endpoint and receives the access token (and usually a refresh token).

The state parameter is a CSRF guard: the client generates it, embeds it in the redirect, and verifies it on return. The PKCE code_verifier is a per-request secret: even if an attacker intercepts the code in the redirect, they cannot exchange it without the original verifier.

Client Credentials flow

The Client Credentials grant skips the user entirely. The backend service posts its client_id and client_secret (or a signed JWT assertion) directly to /token and receives an access token scoped to its own permissions. There is no redirect and no refresh token in the canonical form.

Device Authorization

The device (a TV, a CLI tool, a console) calls /device_authorization and receives a device_code and a short URL it displays to the user. The user opens the URL on a phone or computer and approves. Meanwhile the device polls /token with the device_code until it gets the access token or the code expires. This decoupled flow means no browser redirect is needed on the constrained device itself.

Security guidance

Default to Authorization Code with PKCE for any user-facing client and enable refresh-token rotation with reuse detection so a stolen refresh token can be revoked across its whole token family. For browser-only apps, consider a backend-for-frontend (BFF) that keeps tokens server-side rather than in JavaScript. Always validate state on return, use S256 (never plain) for the PKCE challenge, and scope tokens as narrowly as the task allows. Treat anything that puts a long-lived token in the browser URL or fragment as a security red flag — this is exactly what made the Implicit grant dangerous.