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.
# 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=xyz789If 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.
Practice what you learned
1. Where did the Implicit grant return the access token, and why was this risky?
2. What core OAuth principle does the Resource Owner Password Credentials (ROPC) grant violate?
3. Why does ROPC make multi-factor authentication difficult to support?
4. What is the recommended migration path for an app currently using the Implicit grant?
5. Why do some authorization servers still technically support Implicit and ROPC despite OAuth 2.1 removing them?
Was this page helpful?
You May Also Like
Authorization Code with PKCE
The Authorization Code grant is OAuth 2.0's most secure and widely used flow, and PKCE hardens it further so it is safe for public clients like single-page apps and mobile apps.
Choosing the Right Grant
OAuth 2.0 offers several grant types built for different trust boundaries; picking the wrong one is one of the most common real-world sources of OAuth vulnerabilities.
The Refresh Token Grant
Refresh tokens let a client obtain new access tokens without repeating the full authorization flow, keeping short-lived access tokens practical for long-running sessions.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics