Developer Resources

Get Tokens: Resource Owner Password Credentials

The ROPC grant type can be used in scenarios where an interactive user agent is not available, where specific design requirements warrant the use of a native application login interface, or for legacy reasons (i.e. retro-fitting a login form for OAuth2). In the ROPC grant type, the client captures the user credentials (step 1 below) and uses those credentials to swap for an access token (step 2).

Oauth ropc flow
Capability

Browser-based end user interaction

No

Can use external IDP for authentication

No

Requires client authentication

No

Requires client to have knowledge of user credentials

Yes

Refresh token allowed

Yes

Access token is in context of end user

Yes

Sample Client Configuration

For the resource owner password credentials grant type example below, the following client information will be used:

Admin Label OAuth2 Parameter Example Value

Client ID

client_id

ro_client

Client Authentication

client_secret

2Federate

Allowed Grant Types

response_type grant_type

  • grant_type of "password" (ropc)

  • grant_type of "refresh_token" (refresh)

Getting the Tokens

At this stage, the client displays a login form to the user and collects the credentials (i.e. username/password) and defined scope if required from the resource owner (user) and makes a HTTP POST to the token endpoint.

For the example below, the following credentials were received by the client and are used to request an access token:

The credentials passed via the Resource Owner Password Credential flow are processed through a PingFederate Password Credential Validator. These credentials do not have to be a username and password, they could be for example a username / PIN combination or another credential that is validated by a PCV. 
POST https://localhost:9031/as/token.oauth2 HTTP/1.1

Content-Type: application/x-www-form-urlencoded

Authorization: Basic cm9fY2xpZW50OjJGZWRlcmF0ZQ==

grant_type=password&username=joe&password=2Federate&scope=edit

If successful, the client will receive a 200 OK response to this request and the access token (and optional refresh token) will be returned in a JSON structure:

HTTP/1.1 200 OK

Content-Type: application/json;charset=UTF-8

{
  "access_token":"zzz...yyy",
  "token_type":"Bearer",
  "expires_in":14400,
  "refresh_token":"123...789"
}
An error condition from the authentication / authorization process will be returned to this callback URI with error and error_description parameters.

The application can now parse the access token and, if present, the refresh token to use for authorization to resources. If a refresh token was returned, it can be used to refresh access token once it expires.