Implicit Grant
The OAuth flow that returned tokens directly in the browser URL — deprecated for a decade of good reasons, replaced everywhere by Authorization Code + PKCE.
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
codeexchange and PKCE is the whole distinction.
Primary source: RFC 9700 — OAuth 2.0 Security Best Current Practice
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.