Implicit Grant

What is the Implicit grant?

The Implicit grant was an OAuth 2.0 flow designed for browser-based apps in an era before browsers could do modern cryptography: instead of exchanging a code for tokens server-side, the authorization server returned the access token directly in the redirect URL fragment, where JavaScript read it. No back-channel, no client secret — a pragmatic hack for single-page apps circa 2012, and a security anti-pattern by today’s standards. OAuth 2.1 removes it; current guidance (RFC 9700) says don’t use it.

Why it’s deprecated — the specifics

Returning tokens in the URL is the core sin, and it cascades. Tokens land in browser history, in server access logs (URLs get logged everywhere), and in Referer headers sent to third parties — three separate leak channels for a live credential. There’s no refresh token (the flow couldn’t secure one), forcing awkward re-authentication or long-lived access tokens that worsen the leak exposure. And it predates PKCE, leaving it vulnerable to token-interception attacks that the modern flow closes. Every one of these was a real, exploited weakness, not a theoretical nitpick.

What replaced it

Authorization Code with PKCE is the answer for all client types now, including the SPAs and mobile apps Implicit was invented for. PKCE (Proof Key for Code Exchange) lets public clients — those that can’t hold a secret — use the secure code-exchange flow safely: the app generates a random verifier, sends its hash up front, and proves possession when redeeming the code, defeating interception without a client secret. Browsers gained the crypto to do this; the reason Implicit existed evaporated. Legacy Implicit deployments are migration debt with a shrinking runway as IdPs disable the flow.

What people get wrong

• Still using Implicit for SPAs “because that’s the SPA flow” — it stopped being, years ago; use Auth Code + PKCE.
• Long-lived access tokens to compensate for the missing refresh token, compounding leak risk.
• Confusing Implicit with the modern code flow — the presence of a code exchange and PKCE is the whole distinction.

Primary source: RFC 9700 — OAuth 2.0 Security Best Current Practice

Why the Implicit Grant Was Deprecated

The implicit grant was originally designed for browser-based single-page applications that couldn’t securely store a client secret, returning an access token directly in the browser’s URL fragment rather than through a more secure server-side exchange. This design has since been identified as fundamentally less secure: tokens returned in a URL fragment can leak through browser history, referrer headers, or malicious browser extensions, and the flow provides no mechanism to verify the token actually reached the intended recipient. The OAuth 2.0 Security Best Current Practice now recommends the Authorization Code flow with PKCE (Proof Key for Code Exchange) as the secure replacement for public clients like single-page applications, and major identity providers have progressively deprecated or removed implicit grant support entirely in favor of this more secure alternative.