Card 09/ 11
The Implicit and Password Grants, and Why They Are Retired
Two grants built for older browsers and trusted apps leak tokens and passwords, and OAuth 2.1 removes both.
The implicit grant and the resource owner password grant are no longer recommended for any client. The implicit grant returns the access token directly in the redirect URL, where history, logs and scripts can read it; the password grant has the application collect the user's password, the thing OAuth exists to avoid. RFC 9700, the OAuth security best current practice, rules both out, and the OAuth 2.1 draft removes them.
The symptom. A tutorial or an older library sets up a single-page app with response_type=token, or a mobile app with a username and password form that posts to /token.
Implicit grantthe token travels through the browser
The authorization server redirects to https://app.example/callback#access_token=7Kq2mX9v.... The token sits in the address bar and history, is readable by every script on the page, and cannot be bound to the client that asked.
Code flow with PKCEonly a code travels
The redirect carries ?code=SplxlOBe..., valid once and for seconds. Exchanging it needs the code verifier, which never left the app, so an intercepted code is useless.
Why they existed. Implicit was designed when browsers could not make cross-origin requests to a token endpoint. The password grant was a bridge for first-party apps moving off stored passwords. Browsers now support CORS, covered in the topic on protecting an API, and PKCE protects public clients, so neither reason remains.
What they cost. Tokens leaked from URLs, no refresh tokens for implicit clients, and users trained to type their password into applications other than the provider's.
What to do. Use the authorization code flow with PKCE for every client that acts for a user: single-page apps, mobile apps and server-side web apps alike. Use client credentials when no user is involved.
← → move through sections and cards