Category: OAuth & OIDC

Resource Owner Password Credentials Grant

Also known as: ROPC, Resource Owner Password Credentials Flow, ROPC Flow, Password Grant, Resource Owner Password Grant, ROPG, Resource Owner Password Flow

Simply put

The Resource Owner Password Credentials Grant is an OAuth 2.0 method in which a user hands their username and password directly to an application, which then exchanges those credentials for an access token. Because the application sees the user's password directly, this approach is now considered legacy and is deprecated in favor of safer flows.

Formal definition

The Resource Owner Password Credentials (ROPC) grant is an OAuth 2.0 grant type in which an application collects a user's credentials (typically username/email/phone and password) and submits them directly to the authorization server's token endpoint in exchange for an access token. Because it requires the client to directly handle the resource owner's credentials, it is limited by design to highly-trusted, often first-party or legacy applications. As an OAuth 2.0 grant, it is a delegated authorization mechanism rather than a purpose-built authentication protocol; the grant itself is now deprecated and disallowed in current OAuth security guidance, with implementations such as OIDC-based variants layering additional behavior. Available factors, token issuance details, and support vary by vendor and deployment configuration.

Why it matters

The Resource Owner Password Credentials grant is significant precisely because it violates one of the core design goals of OAuth 2.0: keeping the user's credentials away from the client application. In most OAuth 2.0 flows, the application never sees the user's password; instead, the user authenticates directly against the authorization server. ROPC breaks that separation by requiring the application to collect the username and password and submit them to the token endpoint itself. This means every application using ROPC becomes a place where credentials can be logged, intercepted, or mishandled, expanding the attack surface well beyond what redirect-based flows require.

Because the application directly handles the resource owner's password, ROPC is fundamentally incompatible with modern authentication practices. Interactive mechanisms such as multi-factor authentication, step-up authentication, passwordless flows, and federated login typically cannot function through a simple credential-for-token exchange, since those mechanisms depend on the authorization server controlling the user interaction. As a result, current OAuth security guidance deprecates and disallows the grant, and vendor implementations (including OIDC-based variants) restrict it to highly-trusted, often first-party or legacy applications where no better option is available.

For teams operating identity systems, ROPC matters as a migration and risk-management concern. Existing legacy applications may still depend on it, and removing it requires re-architecting how those applications authenticate users. Understanding where ROPC is in use, and what it prevents an organization from adopting, is a prerequisite to phasing it out in favor of redirect-based flows that keep credentials with the authorization server.

Who it's relevant to

Security Architects

Architects evaluating authentication flows need to recognize that ROPC exposes user credentials to the client application and is deprecated in current OAuth security guidance. Where it exists, it typically blocks adoption of MFA, passwordless, and federated login, and should be treated as a legacy pattern to be replaced with redirect-based flows that keep credentials at the authorization server.

IAM Engineers

Engineers integrating applications with an authorization server may encounter ROPC in first-party or legacy systems that submit username and password directly to the token endpoint. They should understand its restricted, highly-trusted use cases and that vendor support, token issuance, and available factors vary by deployment configuration.

Compliance and Audit Leads

Because ROPC requires applications to directly handle user passwords, its presence is a relevant finding when assessing credential-handling risk and authentication modernization. Auditors should note where the grant is enabled, what applications rely on it, and whether its use is justified given that it is deprecated and disallowed in current guidance.

Application Developers Maintaining Legacy Systems

Developers responsible for older applications that use the password grant are often the ones who must plan migration away from it. Understanding why ROPC is deprecated, and that it prevents interactive security mechanisms controlled by the authorization server, helps prioritize moving to safer flows.

Inside ROPC

Grant Type (grant_type=password)

The OAuth 2.0 authorization grant, defined in the OAuth 2.0 Authorization Framework, in which the client collects the resource owner's username and password and exchanges them directly with the authorization server's token endpoint for an access token. It is a delegated authorization flow, not an authentication protocol in itself.

Resource Owner Credentials

The username and password (knowledge factors) belonging to the resource owner, which the client must handle directly under this grant. This direct exposure of primary credentials to the client is the defining and most sensitive characteristic of the flow.

Client Application

The application requesting access. Under this grant the client obtains and transmits the user's raw credentials, so it is typically limited to highly trusted first-party clients, since third-party clients gaining the password defeats the delegation purpose OAuth 2.0 was designed to provide.

Token Endpoint

The authorization server endpoint that receives the credentials and, on successful validation, issues an access token and, depending on configuration, a refresh token. Whether a refresh token is issued varies by server policy and profile.

Access Token (and optional Refresh Token)

The access token returned for use against protected resources; a refresh token may also be returned depending on configuration. The tokens may be opaque or self-contained (for example a JWT) depending on the authorization server.

Scope

The optional scope parameter constraining the authorization associated with the issued access token, determining what the token may be used to request rather than authenticating the user.

Common questions

Answers to the questions practitioners most commonly ask about ROPC.

Is the Resource Owner Password Credentials (ROPC) grant an authentication protocol?

No. ROPC is a grant type within the OAuth 2.0 delegated authorization framework, not an authentication protocol. While it involves the resource owner supplying a username and password directly to the client, its purpose is to obtain an access token for authorization, not to authenticate the user to the client in a standardized, verifiable way. If you need user authentication, OpenID Connect (which layers authentication on top of OAuth 2.0 and issues an ID token) is the appropriate mechanism. Treating ROPC as an authentication solution conflates authorization with authentication and typically misses identity assertions the client can validate.

Is ROPC a recommended or best-practice grant type for modern applications?

Generally no. ROPC requires the client to handle the user's plaintext credentials directly, which conflicts with a core motivation of OAuth 2.0, avoiding credential sharing with clients. It is widely discouraged for new deployments and is often described as suitable only for narrow legacy scenarios where the client is highly trusted and other flows are not feasible. Depending on your authorization server and its configured profile, ROPC may be disabled by default or unavailable. Redirect-based flows such as the authorization code grant with PKCE are typically preferred instead.

What credentials does the client send when using the ROPC grant?

In a typical ROPC request, the client sends the resource owner's username and password as part of the token request to the authorization server's token endpoint, along with the grant_type parameter. In most deployments the client also authenticates itself (for example with a client ID and, for confidential clients, a client secret), depending on the client type and server configuration. The exact parameters and client authentication requirements vary by authorization server and profile.

Can ROPC issue refresh tokens, and how should they be handled?

Depending on the authorization server's configuration and the scopes granted, an ROPC token response may include a refresh token alongside the access token, allowing the client to obtain new access tokens without re-collecting credentials. Where this is supported, issuing a refresh token is often used specifically so the client does not need to store the user's password. Refresh tokens should be stored securely and subject to the server's rotation and revocation policies. Whether refresh tokens are issued at all is a per-deployment decision.

What transport and credential-handling safeguards apply when ROPC is used?

Because the user's plaintext credentials transit through the client to the token endpoint, TLS on the connection to the authorization server is essential. The client should avoid persisting the user's password and, where a refresh token is available, use it rather than retaining credentials. Beyond that, the security of ROPC depends heavily on how much the client is trusted and how the authorization server is configured; ROPC does not inherently support many protections (such as user consent screens or interactive step-up challenges) that redirect-based flows can provide.

How does ROPC interact with multi-factor authentication?

ROPC is centered on a single knowledge factor, the username and password, submitted directly to the token endpoint, and it does not provide a standardized mechanism for interactive additional factors or step-up challenges. In deployments that enforce MFA, this is a common reason ROPC is restricted or disabled, since it cannot easily accommodate a possession or inherence factor in the flow. Whether and how any MFA integration is possible is vendor- and configuration-specific and is out of scope for the base OAuth 2.0 ROPC definition.

Common misconceptions

The password grant is a way to authenticate users, similar to OpenID Connect.

OAuth 2.0, including this grant, is a delegated authorization framework and not an authentication protocol. The token endpoint returns an access token for authorization purposes; it does not return an ID token or produce a standardized authentication result. Use OpenID Connect if user authentication is the goal.

It is a convenient, generally recommended way for any client to log users in.

The grant requires the client to handle the user's primary credentials directly, which undermines the delegation model OAuth 2.0 was designed around. It is widely discouraged for general use and is typically only considered for highly trusted first-party clients, if at all; current guidance in many deployments favors browser-based flows instead.

Because the client sends credentials over TLS, the flow supports MFA and modern authentication.

The direct username/password exchange does not accommodate interactive factors such as step-up prompts, WebAuthn/FIDO2, or other multi-factor challenges, since the flow assumes a single knowledge-factor credential exchange. TLS protects the transport but does not add authentication factors.

Best practices

Avoid the Resource Owner Password Credentials Grant for new deployments; prefer interactive, browser-based flows so the authorization server, rather than the client, handles user credentials and can enforce MFA and step-up authentication.

If the grant must be used, restrict it strictly to highly trusted first-party clients and never expose it to third-party applications.

Never store or persist the resource owner's raw credentials in the client after the token exchange; discard them immediately once an access token (and, depending on configuration, a refresh token) is obtained.

Use OpenID Connect rather than this grant when the actual requirement is authenticating the user, since the password grant provides authorization tokens, not a standardized authentication result.

Enforce TLS on all requests to the token endpoint and scope issued access tokens as narrowly as the use case allows.

Plan migration away from this grant toward flows compatible with passwordless and multi-factor methods, and document its use as a known limitation during security reviews.