Implement authorization by grant type

This guide explains how to implement a Resource Owner Password flow for your app with Okta.

---

Learning outcomes

• Understand the OAuth 2.0 Resource Owner Password flow.
• Set up your app with the Resource Owner Password grant type.
• Implement the Resource Owner Password flow in Okta.

What you need

• Okta Developer Edition organization (opens new window)
• An app that you want to implement OAuth 2.0 authorization with Okta

Note: Okta's Developer Edition makes most key developer features available by default for testing purposes. Okta's API Access Management product — a requirement to use Custom Authorization Servers — is an optional add-on in production environments.

---

About the Resource Owner Password grant

The Resource Owner Password flow is not a recommended approach. It is intended for applications for which no other flow works, as it requires your application code to be fully trusted and protected from credential-stealing attacks. It is made available primarily to provide a consistent and predictable integration pattern for legacy applications that can't otherwise be updated to a more secure flow such as the Authorization Code flow. This should be your last option, not your first choice.

To select the appropriate flow to use for your application, see OAuth 2.0 and OpenID Connect overview's decision flowchart.

Grant-type flow

Resource Owner Password flow

At a high-level, this flow has the following steps:

1. User authenticates with your client application (app), providing their user credentials.

2. Your app sends these credentials to the Okta authorization server with its client ID and secret in the request header.

   You need to register your app so that Okta can accept the authorization request. See Set up your app to register and configure your app with Okta. After registration, your app can make an authorization request to Okta. See Request for tokens.

3. If the credentials are accurate, Okta responds with the requested tokens.

4. Your app uses the access token to make authorized requests to the resource server.

5. The resource server validates the token before responding to the request. See Validate access token.

Set up your app

Before you can implement authorization, you need to register your app in Okta by creating an app integration from the Admin Console.

1. In the Admin Console, go to Applications > Applications.
2. Click Create App Integration.
3. Select

   OIDC - OpenID Connect

   as the Sign-in method.

4. Select Native Application as the Application type, then click Next.
5. Specify the App integration name.
6. Select Resource Owner Password as an allowed Grant type.
7. Fill in the remaining details for your app integration, then click Save.
8. On the General tab, click Edit in the Client Credentials section.
9. Select Client secret as the Client authentication type, then click Save.

Save the generated Client ID and Client secret values to implement your authorization flow.

Flow specifics

If implementing the Resource Owner Password flow is your only option, you need to make direct calls to Okta's OIDC & OAuth 2.0 API. See the following sections for requests required in the flow.

Request for tokens

Before you can begin this flow, collect the user's password in a manner of your choosing. After you collect the credentials, all that is required is a single API call to the authorization server's /token endpoint. If you are using the default custom authorization server, then your request would look something like this:

curl --request POST \
  --url https://${yourOktaDomain}/oauth2/default/v1/token \
  --header 'accept: application/json' \
  --header 'authorization: Basic MG9hYn...' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data 'grant_type=password&username=testuser1%40example.com&password=%7CmCovrlnU9oZU4qWGrhQSM%3Dyd&scope=openid'

Important: The call to your authorization server's /token endpoint requires authentication. In this case, it is a Basic Auth digest of the client ID and secret. You can find the client ID and secret on your application's General tab. See Client Authentication Methods.

Note the parameters that are being passed:

• grant_type is password, indicating that we are using the Resource Owner Password grant type.
• username is the username of a user registered with Okta.
• password is the password of a user registered with Okta.
• scope must be at least openid. See the Create Scopes section of the Create an authorization server guide.

For more information on these parameters, see the OAuth 2.0 API reference.

If the credentials are valid, your application receives back access and ID tokens:

{
    "access_token": "eyJhb[...]56Rg",
    "expires_in": 3600,
    "id_token": "eyJhb[...]yosFQ",
    "scope": "openid",
    "token_type": "Bearer"
}

Validate access token

When your application passes a request with an access token, the resource server needs to validate it. See Validate access tokens.

Next steps

Now that you have implemented authorization in your app, you can add features such as:

• Brand customization (custom domain, custom SMS messages, custom emails, and custom error pages).
• Self-service enrollment.