Why you should deprecate the Resource Owner Password Credentials (ROPC) grant type

The Resource Owner Password Credentials (ROPC) grant type is a legacy OAuth 2.0 flow that poses security risks and should be deprecated. In this post, we will indicate why you should avoid using ROPC on your applications.

SimengDeveloper

April 24, 20247 min read

Introduction

The Resource Owner Password Credentials (ROPC) grant type a.k.a. password grant type is an OAuth 2.0 flow that allows an application to exchange a user's username and password for an access token. It was first introduced in the OAuth 2.0 specification as a way to support legacy applications such as HTTP basic authentication or legacy native applications that could not use the more secure OAuth tokenized flows.

However, the ROPC grant type poses several security risks and has been marked as a MUST NOT be used in the OAuth 2.0 security best practices.

Recently, we have received several questions from our customers requesting guidance or support for implementing the ROPC grant type. In this post, we will explain why you should avoid using the ROPC grant type especially for your new applications.

ROPC grant type vs. authorization code flow

How the ROPC grant type works

The ROPC grant type is a simple flow that exchanges the user's username and password for an access token. The client application collects the user's credentials directly and sends them directly to the authorization server. The authorization server then validates the credentials and issues an access token to the client.

How the authorization code flow works

In contrast, the authorization code flow is the recommended OAuth 2.0 flow for web applications. It involves multiple steps and redirects between the client application, the authorization server, and the user's browser. The authorization code flow is more secure because it does not expose the user's credentials to the client application.

The main differences between the ROPC grant type and the authorization code flow is ROPC expose the user's credentials to the client application, while the authorization code flow does not. User credentials should be kept confidentially within the authorization server. Whenever a client application requests for a resource on behalf of the user, it should redirect the user to the authorization server to authenticate and authorize the client application. It keeps a minimum amount of authorization data on the client application side.

Security risks of the ROPC grant type

1. User credentials exposure

Like we mentioned earlier, the ROPC grant type exposes the user's credentials to the client application. This is a significant security risk because the client application can store or log the user's credentials, and get reauthorized without the user's awareness.

Especially for a public client application like a mobile application or a single-page application, the client application can be easily injected or reverse-engineered to extract the user's credentials. Neither a mobile application nor a single-page application running on the user's browser can keep secrets confidentially. Thus they can not authenticate the user without exposing the user's credentials.

Even if the resource owner has a trusted relationship with the client application, the client application plays a man-in-the-middle role in the whole authentication process, it might be compromised by another malicious actor. The malicious actor can steal the user's credentials and impersonate the user to access the user's resources.

There are multiple ways to steal the user's credentials, based on the client application's security posture, like keyloggers, phishing attacks, or malware. Not mentioning the client credentials are transmitted over the network on every authorization requests. It further increases the risk of credential interception.

Imagine if you have multiple applications that use the ROPC grant type, the potential risk of credential exposure is multiplied.

The ROPC grant type does not support user consent. When the client application collects the user's credentials directly, the user does not have the opportunity to review and approve the client application's access to their resources. This is a violation of the user's privacy and trust.

Users should have the right to decide which client application can access their resources and for how long. Especially for third-party applications, a user consent mechanism is essential to protect the resource owner's data and it is essential to comply with data protection regulations like GDPR.

3. ROPC does not support multi-factor authentication

Multi-factor authentication (MFA) is a security implementation that requires the user to provide two or more verification factors to access their resources. It adds an extra layer of security to the authentication process. The ROPC grant type does not support MFA. Instead it restricts the authentication process to a single factor, and the token request is only based on the user's credentials. It is imposable to implement challenge-based authentication mechanisms like SMS OTP, email OTP, or WebAuthn with the ROPC grant type.

ROPC is not compatible with modern applications

The ROPC grant type was designed to support legacy applications which cannot support modern IAM systems Single Sign-On (SSO) or federated identities.

1. ROPC is not compatible with SSO

Single Sign-On (SSO) is a modern authentication architecture that allows users to log in once and access multiple applications effortlessly.

A centralized IdP plays a crucial role in the SSO architecture. It manages the user's authentication session and issues tokens to the client applications. The client applications do not need to collect the user's credentials directly, and the user's credentials are kept confidentially within the IdP.

The ROPC grant type does not support SSO. It requires the client application to collect the user's credentials directly, which breaks the SSO architecture. It is not compatible with modern SSO system like OpenID Connect (OIDC) or SAML.

2. ROPC is not compatible with federated identities

Similar to the SSO architecture, federated identities allow users to use their existing identity to access multiple third-party applications. A user may link multiple social accounts like Google, Facebook, or Twitter to a centralized IdP, and use these social accounts to authenticate with the client applications. All the federated identities are managed by the IdP, and the client applications do not aware the user's authentication details under the hood.

The ROPC grant type, instead, requires the client application to collect the user's credentials directly. It limits the client application's capability to support federated identities and exposes the user's identity data to the client application.

Conclusion

The Resource Owner Password Credentials (ROPC) grant type is a legacy OAuth 2.0 flow that poses significant security risks and should be deprecated. It exposes the user's credentials to the client application, does not support modern security mechanisms like MFA or SSO. We strongly recommend avoiding using the ROPC grant type for your applications. If you have legacy authentication systems that rely on the ROPC grant type, consider migrating to more secure OAuth 2.0 flows like the authorization code flow or the client credentials flow.

Contact us if you need help integrating secure user authentication and authorization service into your applications, or migrating from the legacy password based authentication system to a more secure OAuth 2.0 flow. We are here to help you build secure and modern applications.