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.

OAuth 2.0 Grant Types Reference

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, 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 tool 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.

How it works

In the redirect-based grants, the client sends the user to the authorization server’s /authorize endpoint and, after consent, receives a short-lived authorization code. It then exchanges that code at the /token endpoint for an access token (and often a refresh token). The state parameter guards against CSRF, and PKCE binds the code to a per-request code_verifier so an intercepted code is useless. The client_credentials grant skips the user entirely: the client authenticates with its own credentials to get a token for its own resources. The device_code grant decouples the device from the browser — the user approves on a phone while the device polls /token. The legacy implicit and password grants are described for recognition only; both are removed in OAuth 2.1.

Tips and notes

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 family. For browser-only apps, consider a backend-for-frontend (BFF) that keeps tokens server-side rather than in JavaScript. Always validate state, use S256 (never plain) for PKCE, and scope tokens as narrowly as the task allows. Treat anything that puts a long-lived token in the browser URL as a red flag.