Resource Owner Password Credentials
The OAuth flow where the app collects the user's password directly — formally deprecated, kept alive only by legacy systems, and the anti-pattern worth knowing by name.
Last reviewed: July 25, 2026
What is the Resource Owner Password Credentials grant?
ROPC is the OAuth grant where the client application takes the user’s username and password itself and exchanges them directly for tokens. No redirect, no consent screen, no authorization server UI — the app touches raw credentials. It existed as a bridge for trusted first-party apps migrating from password databases to OAuth, and it now exists primarily as a security-review red flag: OAuth 2.1 removes it, and current best-practice guidance (RFC 9700) says MUST NOT.
Why it’s deprecated — the full indictment
ROPC breaks OAuth’s founding purpose: the entire point was that applications never see passwords. With ROPC, credential phishing becomes indistinguishable from normal login (users are trained to type passwords into apps); the client becomes a credential-theft target; MFA, WebAuthn/passkeys, and adaptive authentication cannot run because there’s no IdP-controlled interaction; federation breaks (the app can’t do SAML/social login); and consent is fiction. Every modern identity capability you want is structurally unavailable through ROPC.
What to use instead
Interactive apps — web, mobile, SPA: Authorization Code with PKCE, full stop; system browsers handle credentials and MFA. Machine-to-machine with no user: Client Credentials. Input-constrained devices: Device Code flow. Legacy ROPC deployments (old mobile apps, scripted logins against enterprise IdPs) should be treated as migration debt with a deadline — IdPs increasingly disable the grant by default, so the deadline may be chosen for you.
What people get wrong
- Using ROPC for test automation against production IdPs — service accounts with client credentials or test-specific token endpoints exist for this.
- “It’s first-party, so it’s fine”: first-party status doesn’t restore MFA, passkeys, or phishing resistance.
- Confusing ROPC with client credentials — one impersonates a user with their password; the other authenticates an application as itself.
Primary source: RFC 9700 — Best Current Practice for OAuth 2.0 Security
Why It’s Formally Deprecated
The OAuth 2.0 Security Best Current Practice document explicitly recommends against this grant type for new implementations, since it fundamentally contradicts OAuth’s core purpose — allowing an application to gain access without ever seeing the user’s actual password. Any application using this flow has full visibility into a user’s raw credentials, which it could misuse, log accidentally, or lose in a breach, none of which is possible with authorization-code-based flows where the password only ever passes between the user and the actual identity provider. It persists mainly in legacy internal tools built before more secure flows were standardized, and migrating away from it is a common item in security modernization roadmaps for older applications.
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.