What was the implicit grant, and why is it no longer recommended?
A shortcut flow in which the authorization server returns the access token directly in the redirect URL (no code, no back channel, no client authentication); it exposes tokens in the browser and cannot detect token injection, so it is deprecated and replaced by authorization code + PKCE.
The implicit flow was designed in 2012 for JavaScript apps in the browser, which could not keep a client secret and, at the time, could not easily make cross-origin requests to a token endpoint. So the token was delivered straight away, in the URL fragment of the redirect. It was the simplest flow to implement: a single request to the authorization server, and only the redirect URI was checked.
Its problems:
- Token in the browser URL: it can leak through browser history, logs, Referer headers or malicious scripts and extensions.
- No client authentication: the server cannot tell whether the legitimate client receives the token.
- Token injection: an attacker can feed the app a token obtained elsewhere, and the app cannot tell.
- No refresh tokens, so apps resorted to tricks to keep sessions alive.
Modern browsers support CORS, so a browser app can call the token endpoint directly. Authorization code + PKCE therefore achieves everything implicit did without its weaknesses. RFC 9700 says clients should not use the implicit grant, and OAuth 2.1 removes it.
Go deeper:
RFC 9700, Section 2.1.2: Implicit Grant — the formal recommendation against the implicit grant and the reasons.- oauth.net: Implicit Flow (Deprecated) — a short history of why it was introduced and why it was dropped.