OAuth2 – Resource Owner Password Credentials Grant

In this post, I’ll discuss the Resource Owner Password Credentials (ROPC) grant and when you should use it.

Overview of the ROPC Grant:

In a ROPC flow, the user gives the credentials directly to the client application, usually by mean of a login form over which the client application has complete control. In this flow, the client application does not redirect the user to an authorization server for authentication. However, the client application submits a request to the authorization server, passing over the user’s credentials to obtain an access token on behalf of the user. If the client is a confidential client or has been provided a secret key, the client also needs to authenticate against the authorization server using its client id and secret when requesting a token.

As an example, let’s look at a fictitious online book store -NumberOneBookStore which sells books online and provides personal recommendations based on purchase history. The company provides a web app and a RESTful API for accessing users’ data. To use the services, a user needs to register an account and authenticate against the company’s own directory. The engineering team has decided to implement the OAUTH ROPC grant flow for protecting the API. Below is the high level flow of a user who visits the company’s website to purchase books:

1. The user navigates to NumberOneBookStore website.
2.  The user enters the credentials into the login form.
3. The web app submits a request to the NumberOneBookStore authorization server, providing it’s credentials (client id and secret) as well as passing over the user’s credentials.
4. The authorization server validates the user’s and the web app’s credentials. On success, it issues an access token back to the web app.
5. The web app makes a request to the API protected endpoint to retrieve recommendations for the user. The API validates the user’s access based on the token and return back recommendation data.

When to use the ROPC Grant:

According to the spec,

“The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged application”.

In the example, the user is okay with giving the web app the credentials because the user trusts the app as it is from the company of which the user uses the services. Furthermore, the web app is a highly privileged application as the authorization server only allows the ROPC grant type requests from the NumberOneBookStore web app. It would be a serious security risk if for example, the authorization server issued an access token to a 3rd party application which took the user’s credentials for NumberOneBookStore and submitted a ROPC grant type request to the authorization server. In that case, the 3rd party application would be impersonating the user. That is why it is critical that the authorization server validates the client’s credentials to ensure it only issues access tokens to trusted applications.Another use case of the ROPC grant type, according to the spec, is

“to migrate existing clients using direct authentication schemes such as HTTP Basic or Digest authentication to OAuth by converting the stored credentials to an access token.”

In the example, the NumberOneBookStore team could save some resources using the HTTP Basic authentication as it does not require an authorization server. However, using  an access token offers several OAuth features including scope, token expiry time, and refresh token. For example, by using the flow, the NumberOneBookStore team achieve these benefits:

• Eliminate the need to store the user’s credentials for future use by using a refresh token.
• Mitigate the risks that occur in the event a malicious user gains access to the user’s access token by setting the token expiry time.
•  Provide fine grain access control based on scope. For instance, when requesting an access token, the web app could specify a scope named “purchase_history” to get just the list of books the user has purchased. The result token would allow access to only the user’s purchase history data and not other sensitive information about the user. In the event the token got compromised, the attacker would only see the list of books the user has purchased and nothing else.

Lastly, according to the spec,

“The authorization server should take special care when enabling this grant type and only allow it when other flows are not viable.”

In the example, the NumberOneBookStore team could have implemented the Implicit Grant type which would redirect the user to the authorization server’s login endpoint. However, using the Implicit Grant flow mean the user has to navigate back and forth between the web app and the authorization server. For the example, I personally feel the user has the better experience when using the ROPC flow.

Hopefully, you now have a better understanding of the ROPC grant type and when to use it.

References:

RFC 6749 Section 1.3.3