With a grant, an app can get limited access to a user’s resources. OAuth 2.0 includes grant types for different kinds of access. ForgeRock Identity Cloud Express supports the following grant types:
- Authorization Code With PKCE: Secures authorization code grant for Web/Native/SPA Apps.
- Client Credentials: Secures M2M and Web Apps; for non-user resources.
- Password: Requires username/password; least secure grant type.
- Refresh Token: Prevents repeated sign-ins.
Authorization Code with PKCE
When a user authorizes access to their data, the authorization server returns an authorization code. The client application exchanges this code for an access token.
To secure the use of an authorization code grant, you need the Proof Key for Code Exchange (PKCE) protocol. With PKCE, you don’t have to share app client secrets with end user browsers.
As noted in the OAuth 2.0 website, PKCE (pronounced “pixie”) secures public clients that don’t use a client secret.
The client credentials grant allows access to info on a resource server. Client credentials are typically associated with Service (M2M) apps. They don’t require interaction with users.
The client credentials grant may also be used by web apps.
For more information, see the following section of our Access Management Guide: Client Credentials Grant.
The password grant is also known as the Resource Owner Password Credentials Grant. With a username and password, a client app can use this grant to get an access token.
The password grant carries risks because it transfers real user credentials and personally identifying information. However, it can be a useful tool during development.
To create a web app through the console, select Show Advanced Settings, scroll to the Grant Type box, and select the password grant type. It’s deselected by default.
In production, we encourage the use of Authorization Code (With PKCE).
When an access token expires, a web app can exchange a refresh token for a new access token. When this exchange occurs, apps don’t have to ask users to “sign in again” when an access token expires.
The following REST call uses a refresh token to get the following new tokens:
- Access token
- ID token
- Refresh token (different from the original)
curl --location --request POST "https://openam-<name_of_your_tenant>.forgeblocks.com/oauth2/access_token" \ --header "Content-Type: application/x-www-form-urlencoded" \ --header "Authorization: Basic <BASE_64_ENCODED_STRING"> \ --data "grant_type=refresh_token&refresh_token=<refreshToken>"
In this REST call, you’d use substitute:
- Name of your tenant
- Existing refresh token
- Base64 encoded string based on your client_id:client_secret; you can set this up is with the following command:
echo -n CLIENT_ID:CLIENT_SECRET | base64
Express does not support implicit flow. While some apps use the implicit flow grant type, the OAuth 2 Security Best Practice document describes the security risks associated with implicit flow. Express supports the use of Authorization Code With PKCE as an alternative.
For more information on each of these grant types, see the following sections of our Access Management documentation:
For the related specification, see the grant types discussed in RFC 6749.