Deprecated Implicit and Password Grants

Analogy categoryAnalogies

The Implicit Grant: Tokens in the URL Fragment

The Implicit grant was designed in 2012 for browser-based apps that couldn't make a secure back-channel token request (SPAs, at the time, ran entirely client-side with no back end). Instead of returning an authorization code, the /authorize redirect returned the access token directly in the URL fragment (response_type=token), skipping the /token exchange step entirely. This seemed efficient, but it meant the access token appeared in browser history, could be leaked via the Referer header, was exposed to any script on the page, and, crucially, could never be tied to a confidential client since there was no back-channel exchange to authenticate against.

🏏

Cricket analogy: It's like a scorer announcing the final result over the stadium PA system in plain language the moment the last ball is bowled, rather than filing it through the official scorebook first; anyone within earshot, not just the official broadcaster, now has the raw result.

Why the Implicit Grant Is Deprecated

OAuth 2.1 formally removes the Implicit grant. Front-channel-only token delivery has no way to bind the token to the specific requesting client, meaning a malicious script or extension that manages to hook into the redirect can capture the token as easily as the legitimate app. Since browsers themselves now block third-party cookies and are increasingly hardened, and since virtually every SPA framework can now safely perform an Authorization Code exchange (either directly with CORS-enabled /token endpoints or via a lightweight backend-for-frontend), there is no longer a technical justification for accepting the extra exposure the Implicit grant introduces.

🏏

Cricket analogy: It's like retiring the practice of relaying umpiring decisions by hand signal alone across a noisy stadium, once every ground got proper radio-linked third-umpire communication; the old method is simply riskier with no remaining upside.

The Resource Owner Password Credentials (ROPC) Grant

ROPC lets a client collect the user's username and password directly, then exchange them for tokens at /token with grant_type=password, no redirect at all. It was intended as a bridge for trusted, first-party legacy applications migrating to OAuth, but it fundamentally violates OAuth's core principle: the resource owner's credentials should never be exposed to any client but the authorization server itself. Any client using ROPC could, maliciously or through a bug, log or misuse the raw password, and it makes multi-factor authentication and federated login (Google/Microsoft sign-in) essentially impossible to layer in, since there's no interactive login page for the authorization server to control.

🏏

Cricket analogy: It's like a fan handing their actual stadium membership login and password to a scalper's app to 'buy tickets faster', instead of using the official app's own secure login; the fan has no way to know what that third-party app does with the credentials afterward.

http

# ROPC (deprecated) — the client sees the raw password directly
POST /oauth/token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=password
&username=alice@example.com
&password=Sup3rSecret!          <-- exposed to the client app itself
&client_id=legacy-mobile-app
&scope=orders:read

# The correct modern replacement: Authorization Code with PKCE
# The client never sees the password; the user authenticates
# directly on the authorization server's own login page.
GET /authorize?response_type=code&client_id=legacy-mobile-app
  &redirect_uri=com.example.app:/callback
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256&scope=orders:read&state=xyz789

If you inherit a codebase still using ROPC or Implicit, the migration path is almost always Authorization Code with PKCE: for ROPC, replace the embedded username/password form with a redirect (or embedded web view/ASWebAuthenticationSession on mobile) to the authorization server's hosted login page; for Implicit, simply switch response_type=token to response_type=code and add the PKCE parameters.

Where You Might Still Encounter Them

Despite formal deprecation, both grants persist in older systems: enterprise identity providers still supporting decade-old integrations, internal tools built before PKCE was widely available, and some IoT or CLI tools that predate the Device Authorization Grant. Security audits and OAuth migrations frequently flag ROPC and Implicit usage as findings precisely because they're 'still technically supported' by many authorization servers for backward compatibility, even though the spec authors and virtually every major identity provider (Okta, Auth0, Microsoft, Google) actively discourage new usage and some have begun disabling them by default for new applications.

🏏

Cricket analogy: It's like a historic ground still having an old hand-operated scoreboard sitting unused behind the modern electronic one, kept only because ripping it out entirely would be disruptive, not because anyone still relies on it for the real score.

Never build new functionality on ROPC or Implicit, even if your identity provider still technically supports them 'for compatibility'. Both grants are formally removed from OAuth 2.1, both have well-documented real-world exploitation patterns (phishing via ROPC, token leakage via Implicit), and both block you from adopting MFA and federated login cleanly. Treat any existing usage you find during a code review as a migration item, not a pattern to replicate.

The Implicit grant returned access tokens directly in the URL fragment, exposing them to browser history, Referer headers, and any page script.
OAuth 2.1 formally removes the Implicit grant; Authorization Code with PKCE now works safely for every browser-based client.
ROPC has the client collect the user's raw username and password directly, violating OAuth's core principle of never exposing credentials to the client.
ROPC makes MFA and federated login essentially impossible to layer in cleanly, since there's no authorization-server-hosted login page involved.
Both grants remain 'technically supported' by many providers for legacy backward compatibility, not as a recommended pattern for new apps.
Migrating off Implicit means switching response_type=token to response_type=code and adding PKCE parameters.
Migrating off ROPC means replacing the embedded credential form with a redirect to the authorization server's hosted login page.