OAuth Resource Owner Password Credentials Flow
On this page
What is the Resource Owner Password Credentials Flow in OAuth 2.0?
The Resource Owner Password Credentials flow (ROPC flow) is an OAuth 2.0 password grant flow designed for legacy systems where users provider their credentials directly to a client application. The user is authenticated by the client, passing the username and password in the request. This is an anti-pattern, and the flow only exists to provide an outlet for third-party applications that need to migrate to use OAuth-protected APIs but cannot be re-written.
The ROPC flow implies security risks such as credential exposure. It also lacks support for multi-factor authentication (MFA) and any other modern authentication method.
How ROPC Flow Works
Legacy flow
The ROPC flow only exists for historical reasons to support legacy applications. Do not use in new developments.
- The client application collects the username and password from the user. It sends the credentials to the token endpoint of the authorization server.
- The authorization server validates the credentials and returns an access token (and, optionally, a refresh token) to the client.
User Authentication
The user is authenticated with a username and password. There is no other way to authenticate the user. This means that the flow cannot support multi-factor authentication or passwordless methods and thus does not meet common security requirements.
Client Authentication
The client authenticates as part of the token request. There are many ways for a client to authenticate. The most common being client secret. The Curity Identity Server supports the following authentication mechanisms for clients:
- No authentication (public client)
- Secret in POST body
- Secret using Basic Authentication
- Client Assertion JWT
- Mutual TLS (mTLS) client certificate
- Asymmetric Key
- Symmetric Key
- Credential Manager
- JWKS URI
ROPC Authentication
An ROPC client can not be configured as a public client with no authentication.
The Access Token
The access token is returned by the token endpoint. It is the token that clients can use to call the API and gain access. It is often a bearer token, and as such, the client must not send it to untrusted parties. The access token usually has a lifetime of 5-30 minutes.
The Refresh Token
The refresh token is issued if the client is configured to have refresh tokens. This token can be used to obtain more access tokens once the first one expires. The refresh token may have a very long lifetime, ranging from hours to years.
ROPC Request Parameters & Token Handling
Request Parameters
- Method:
POST - Content-Type:
application/x-www-form-urlencoded - Response Type:
json
| Parameter | Value | Mandatory | Description |
|---|---|---|---|
| client_id | The Client ID | yes | The ID of the requesting client. |
| client_secret | The client secret | yes* | The secret of the client. *Mandatory if client authentication is of type secret, and the authentication is not done using basic authentication. |
| grant_type | password | yes | Tells the token endpoint to perform the resource owner password credential flow. |
| scope | Space-separated string of scopes | no | List the scopes the client is requesting access to. |
| username | the username | yes | The username of the resource owner. |
| password | the user password | yes | The password of the resource owner. |
Response
- Response Type:
application/json
| Parameter | Value | Mandatory | Description |
|---|---|---|---|
| access_token | A newly issued access token | yes | The resulting access token for the flow. |
| refresh_token | A newly issued refresh token | no | Only issued if the client is configured to receive refresh tokens. |
| expires_in | Expiration in seconds | yes | The time to live of the access token in seconds. |
| scope | Space-separated string | no | If not present, the requested scopes were issued. If present, the issued scopes may differ from the requested scopes. |
| token_type | Bearer or other token type | yes | Describes how the token can be used. Most commonly Bearer token usage. |
Security Concerns & Best Practices
Since ROPC authentication requires the user to directly share their credentials and doesn't support multi-factor authentication, you should consider alternative OAuth flows such as:
- Authorization Code Flow with PKCE for public clients.
- Client Credentials Flow for server-to-server communication.
- Device Authorization Flow for applications without direct user input.
- Which OAuth Flow Should I Use? to learn how to select the right OAuth 2.0 flow for your app.
Jacob Ideskog
Identity Specialist and CTO at Curity
Join our Newsletter
Get the latest on identity management, API Security and authentication straight to your inbox.
Start Free Trial
Try the Curity Identity Server for Free. Get up and running in 10 minutes.
Start Free Trial
