Authorization Basics

3 mins read

Resource Owner Password Credentials Flow

The resource owner password credentials grant (ROPC) is designed for obtaining access tokens directly in exchange for a username and password. For this reason, it requires strong trust between the user and client application, and still, additional measures must be taken to mitigate the likely vulnerabilities and complications. Consider ROPC is not recommended as per the OAuth 2.0 best practices.

In a Nutshell

The Resource Owner Password Credentials grant (also known as ROPC), according to the OAuth 2.0 Authorization Framework RFC6749 definition, can be used directly to obtain an access token by providing end-user credentials to the authorization server by the client. The credentials should only be used when there is a high degree of trust between the resource owner and the client (e.g., the client is part of the device operating system or a highly privileged application).

Flow in Depth

[mermaid-begin]
sequenceDiagram Title: Resource Owner Password Credentials autoNumber participant user as User participant app as Application participant ce as Authorization server user->>app: Authenticate with username/password app->>ce: /oauth/token ROPC grant ce->>ce: Validate user credentials ce->>app: Access & ID token app->> user: User is authenticated
  1. The client requests token by calling the token endpoint.

    Sample cURL to the token endpoint with Cloudentity as an authorization server

    For client authentication method set to none:

    curl --location --request POST \
    --url "https://$TENANT_ID.$REGION_ID.authz.cloudentity.io/$TENANT_ID/$WORKSPACE_ID/oauth2/token" \
    --header "Content-Type: application/x-www-form-urlencoded" \
    --data-raw "grant_type=password&client_id=$CLIENT_ID&username=$USER_NAME&password=$USER_PASSWORD"
    

    For client authentication method set to client secret post or basic:

    curl --location --request POST \
    --url "https://$TENANT_ID.$REGION_ID.authz.cloudentity.io/$TENANT_ID/$WORKSPACE_ID/oauth2/token" \
    --header "Content-Type: application/x-www-form-urlencoded" \
    --data-raw "grant_type=password&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET&username=$USER_NAME&password=$USER_PASSWORD"
    

    Region identifier

    REGION_ID is available for recently created tenants in the tenant URL next to TENANT_ID. The region IDs are assigned as follows:

    • Australia: au

    • Europe: eu

    • USA: us

    For tenants without the region identifier, the REGION_ID parameter must be skipped.

  2. Authorization server validates user credentials.

    When user credentials are valid, then

  3. Authorization server returns the access and ID tokens.

  4. User gets authenticated.

Cloudentity as Authorization Server

With Cloudentity, everyone interested can create an authorization server in a few clicks and free of charge. Once you click LAUNCH FREE TENANT and provide the bare essentials, add an authorization server—a workspace. Cloudentity offers workspaces for various purposes, including compatibility with the Open Finance initiatives, integration with external parties, as well as applications and services for workforce or consumers. To add users, connect an identity provider. You can select a well-known provider from the wide range supported by Cloudentity or use Cloudentity Identity Plane.

That’s it. Your server is equipped for kick-off.

To make it loud and clear, take in the fundamentals of access management, get familiar with open banking, and discover how Cloudentity APIs can make your life easier.

Launch a complete, secure cloud-based authorization server compliant with the best practices for free and with zero additional efforts.

Then, try the resource owner password credentials grant with the Demo client application to see how the flow goes.

Ready to go? A few steps to activate the ROPC grant type:

  1. Enable Resource owner password for the Demo workspace.

  2. Allow Password as a grant type for your client application.

  3. Set a token endpoint authentication method. Depending on your needs, it can be as follows:

    • Client secret post

    • Client secret basic

    • None

You can set up dynamic scopes for your application, from coarse- to fine-grained. Upon scope modifications, configure the user consent form based on your changes.

More in Cloudentity

Cloudentity supports other grant types for you to select a flow based on your needs.

For example, use the Device flow for a browserless device authorization.

To implement a secure authorization for your native or single-page application, use the PKCE extension of the Authorization code grant.

You can find more info about oauth grant types in our article, namely, what grant types are available in Cloudentity, and learn what type meets your case.

Updated: May 22, 2023