Which OAuth grant should I use for a single-page app?

Authorization Code with PKCE. SPAs are public clients that cannot keep a secret, and PKCE binds the authorization code to the client that requested it, preventing interception. The older Implicit flow is deprecated and should not be used for new apps.

What is PKCE and why does it matter?

PKCE (Proof Key for Code Exchange) adds a one-time code_verifier and its hashed code_challenge to the authorization code flow. The attacker who steals an authorization code cannot exchange it without the verifier. OAuth 2.1 requires PKCE for all clients, public and confidential.

When is the Client Credentials grant appropriate?

For machine-to-machine calls where no human is involved — a backend service authenticating to an API as itself. It issues only an access token with no user context and no refresh token, since the client can simply request a new token with its own credentials.

How does the Device Authorization grant work?

An input-constrained device (a TV or CLI) shows the user a short code and a verification URL. The user opens that URL on a phone or laptop, signs in and enters the code, while the device polls the token endpoint until authorization completes. It avoids typing credentials on the device.

Why are the Implicit and Password grants deprecated?

Implicit returns the access token directly in the redirect URL, exposing it in browser history and referrer headers. The Password grant gives the app the user's raw credentials, defeating the point of delegated authorization. OAuth 2.1 removes both in favour of safer flows.

OAuth 2.0 Grant Type 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 right OAuth 2.0 flow for your client

OAuth 2.0 defines several grant types — each a different way for a client to obtain an access token. The right one depends on whether a user is present, whether the client can keep a secret, and what kind of device runs it. This reference lists each grant with its grant_type value, intended use case, the tokens it issues and its current status under OAuth 2.1.

How it works

Most user-facing flows split into a front channel (the browser redirect where the user authenticates) and a back channel (a server-to-server token exchange). The Authorization Code flow returns a short-lived code on the front channel, which the client swaps for tokens on the back channel — so the token never travels through the URL. PKCE strengthens this by binding the code to the original requester.

1. App -> /authorize?response_type=code&code_challenge=...   (front channel)
2. User logs in, consents
3. AS  -> redirect_uri?code=AUTH_CODE
4. App -> /token  code=AUTH_CODE&code_verifier=...           (back channel)
5. AS  -> { access_token, refresh_token, id_token }

Machine-to-machine calls skip the user entirely with Client Credentials, and input-limited hardware uses the Device Authorization flow with polling.

Tips and notes

Default to Authorization Code with PKCE for any flow that signs in a user.
Use Client Credentials only for trusted backend services, never from a browser where the secret would leak.
Treat refresh tokens as sensitive: rotate them for public clients and detect reuse to limit damage from theft.
Do not build new integrations on Implicit or Password grants — both are removed in OAuth 2.1.