Under Native Consoles > Access Management, go to Realms > Realm Name > Services > OAuth2 Provider.

On the Advanced tab, enable Encrypt Client-Side Tokens.

Save your changes.

Under Native Consoles > Access Management, go to Realms > Realm Name > Services, and click OAuth2 Provider.

On the Advanced tab, in the OAuth2 Token Signing Algorithm list, select the signing algorithm to use for signing client-side tokens.

Save your changes.

Go to Applications > Client ID > Sign On > General Settings > Scopes.

Edit the Scopes settings using the extended scope allowlist format.

Save your work.

Go to Applications > Client ID > Sign On > General Settings > Show advanced settings > Access.

Edit the Claims settings.

Save your work.

Under Native Consoles > Access Management, go to Realms > Realm Name > Applications > OAuth 2.0 > Remote Consent and click Add Remote Consent Agent.

Set the Agent ID, such as myRemoteConsentAgent.

If the remote consent service uses an HMAC algorithm to sign JWTs, set Remote Consent Service secret to the shared symmetric key.

Click Create.

Configure the profile settings as required and save your work.

Under Native Consoles > Access Management, go to Realms > Realm Name > Services > OAuth2 Provider and switch to the Consent tab.

Select Enable Remote Consent.

Select the profile in the Remote Consent Service ID list.

If necessary, update the settings for signing and encryption.

Save your work.

Under Native Consoles > Access Management, go to Realms > Realm Name > Applications > OAuth 2.0 > Clients > Client ID and switch to the OAuth2 Provider Overrides tab.

Select Enable OAuth2 Provider Overrides.

Select Enable Remote Consent.

Select the profile in the Remote Consent Service ID list.

Save your work.

Create a confidential OAuth 2.0 client account.

Under Sign On > General Settings > Scopes, add access and save your work.

Generate a public-private key pair for the OAuth 2.0 client.

Represent the public key as a JWK.

{
  "jwk": {
    "kty": "EC",
    "use": "enc",
    "crv": "P-256",
    "kid": "myPublicJsonWebKey",
    "x": "D5kNqoGZbLZa77xdh4HSlSZIJcHxNw4UP0pgd5wbXvU",
    "y": "tX3SnRZgUOy48FV0XTCtaQNLG_DxXGbcVk94KvpyXrk"
  }
}

Base64-encode your JWK, as in the following example:

ewogICJqd2siOiB7CiAgICAia3R5IjogIkVDIiwKICAgICJ1c2UiOiAiZW5jIiwKICAgICJjc
nYiOiAiUC0yNTYiLAogICAgImtpZCI6ICJteVB1YmxpY0pzb25XZWJLZXkiLAogICAgIngiOi
AiRDVrTnFvR1piTFphNzd4ZGg0SFNsU1pJSmNIeE53NFVQMHBnZDV3Ylh2VSIsCiAgICAieSI
6ICJ0WDNTblJaZ1VPeTQ4RlYwWFRDdGFRTkxHX0R4WEdiY1ZrOTRLdnB5WHJrIgogIH0KfQ==

Include the base64-encoded JWK as the value of the cnf_key parameter to request an access token:

$ curl \
--request POST \
--user 'myClient:forgerock' \
--data 'grant_type=client_credentials' \
--data 'scope=access' \
--data 'cnf_key=eyJqd2siOnsia3R5IjoiRUMiLCJ1c2UiOiJlbmMiLCJjcnYiOiJQLTI1NiIsImtpZCI6Im15UHVibGljSnNvbldlYktleSIsIngiOiJENWtOcW9HWmJMWmE3N3hkaDRIU2xTWklKY0h4Tnc0VVAwcGdkNXdiWHZVIiwieSI6InRYM1NuUlpnVU95NDhGVjBYVEN0YVFOTEdfRHhYR2JjVms5NEt2cHlYcmsifX0=' \
'https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/access_token'
{"access_token":"nhFC8RBEA6Zm672ir9GlWOMdJYc","scope":"access","token_type":"Bearer","expires_in":3599}

The client uses the access token to request a protected resource on the resource server.

The resource server uses the access token to get the public key.

$ curl \
--request POST \
--user 'myClient:forgerock' \
--data 'token=nhFC8RBEA6Zm672ir9GlWOMdJYc' \
'https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/introspect'
{
  "active": true,
  "scope": "access",
  "realm": "/alpha",
  "client_id": "myClient",
  "user_id": "myClient",
  "username": "myClient",
  "token_type": "Bearer",
  "exp": 1671126270,
  "sub": "myClient",
  "subname": "myClient",
  "iss": "https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "use": "enc",
      "crv": "P-256",
      "kid": "myPublicJsonWebKey",
      "x": "D5kNqoGZbLZa77xdh4HSlSZIJcHxNw4UP0pgd5wbXvU",
      "y": "tX3SnRZgUOy48FV0XTCtaQNLG_DxXGbcVk94KvpyXrk"
    }
  },
  "authGrantId": "CBmKDJ1Ei8V7HhyXcKAyHaNR42I",
  "auditTrackingId": "3c47dc23-a35f-4a34-9f73-daf709d42400-385803"
}

The resource server uses the public key to confirm proof-of-possession with a challenge-response interaction.

The resource server grants access to the resource.

Create a confidential OAuth 2.0 client account.

Under Sign On > General Settings > Sign-in URLs, add https://www.example.com:443/callback and save your work.

Create a user profile.

Record the username and password.

Authenticate as the resource owner:

curl \
--request POST \
--header 'Content-Type: application/json' \
--header 'X-OpenAM-Username: <resource-owner-username>' \
--header 'X-OpenAM-Password: <resource-owner-password>' \
--header 'Accept-API-Version: resource=2.0, protocol=1.0' \
'https://<tenant-env-fqdn>/am/json/realms/root/realms/alpha/authenticate'
{"tokenId":"<resource-owner-tokenId>","successUrl":"/enduser/?realm=/alpha","realm":"/alpha"}

Request the authorization code as the client:

curl \
--dump-header - \
--request POST \
--Cookie '<session-cookie-name>=<resource-owner-tokenId>' \
--data 'scope=openid' \
--data 'response_type=code' \
--data 'client_id=myClient' \
--data 'csrf=<resource-owner-tokenId>' \
--data 'redirect_uri=https://www.example.com:443/callback' \
--data 'state=abc123' \
--data 'decision=allow' \
'https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/authorize'
...
location: https://www.example.com:443/callback?code=<authorization-code>&iss=https%3A%2F%2F...
...

Exchange the authorization code for an access token as the client:

curl \
--request POST \
--user 'myClient:forgerock' \
--data 'grant_type=authorization_code' \
--data 'code=<authorization-code>' \
--data 'redirect_uri=https://www.example.com:443/callback' \
'https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/access_token'
{
  "access_token": "<access-token>",
  "refresh_token": "<refresh-token>",
  "scope": "openid",
  "id_token": "<id-token>",
  "token_type": "Bearer",
  "expires_in": 3599
}

The client, usually a web-based service, receives a request to access a protected resource. To access the resource, the client requires authorization from the resource owner.

The client redirects the resource owner’s user-agent to the authorization server.

The authorization server authenticates the resource owner, confirms resource access, and gathers consent if required.

The authorization server redirects the resource owner’s user agent to the client.

During the redirection process, the authorization server appends an authorization code.

The client receives the authorization code and authenticates to the authorization server to exchange the code for an access token.

If the authorization code is valid, the authorization server returns an access token (and a refresh token, if configured) to the client.

The client requests access to the protected resource from the resource server.

The resource server contacts the authorization server to validate the access token.

The authorization server validates the token and responds to the resource server.

If the token is valid, the resource server lets the client access the protected resource.

The end user wants to use the services provided by the relying party (RP). The RP, usually a web-based service, requires an account to provide those services.

To access the end user’s information in the OpenID provider (OP), the RP requires end user consent.

...to the OP.

The OP authenticates the end user, confirms resource access, and gathers consent if necessary.

The OP redirects the end user’s user-agent to the RP.

During the redirection process, the OP appends an authorization code.

The RP authenticates to the OP and exchanges the authorization code for an access token and an ID token.

If the authorization code is valid, the OP returns an access token and an ID token to the RP.

The RP validates the ID token and its claims.

If the RP requires additional claims, it sends a request to the /oauth2/userinfo endpoint with the access token for authorization.

If the access token is valid, the /oauth2/userinfo endpoint returns any additional claims.

Create an application owner profile and record the username and password.

Register a client application.

Create a resource owner profile and record the username and password.

The client redirects the resource owner’s user-agent to the authorization server’s /oauth2/authorize endpoint, including the following query parameters:

https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/authorize
?client_id=myClient
&response_type=code
&scope=write
&state=abc123
&redirect_uri=https://www.example.com:443/callback

The resource owner authenticates to the authorization server. In this demonstration, they sign in using the default journey configured for the realm.

Inspect the URL in the browser.

Follow the steps to get an access token.

Authenticate as the resource owner.

$ curl \
--request POST \
--header 'Content-Type: application/json' \
--header 'X-OpenAM-Username: <resource-owner-username>' \
--header 'X-OpenAM-Password: <resource-owner-password>' \
--header "Accept-API-Version: resource=2.0, protocol=1.0" \
'https://<tenant-env-fqdn>/am/json/realms/root/realms/alpha/authenticate'
{"tokenId":"<tokenId>","successUrl":"/enduser/?realm=/alpha","realm":"/alpha"}

As the client, call the /oauth2/authorize endpoint to request the authorization code. Provide the resource owner’s SSO token in a cookie and the following parameters:

Follow the steps to get an access token.

The client receives a request to access a protected resource. To access the resource, the client requires authorization from the resource owner. When using the PKCE standard, the client must generate a unique code and a way to verify it, and append the code to the request for the authorization code.

The client redirects the resource owner’s user-agent to the authorization server.

The authorization server authenticates the resource owner, confirms resource access, and gathers consent if not previously saved.

If the resource owner’s credentials are valid, the authorization server stores the code challenge and redirects the resource owner’s user agent to the redirection URI.

During the redirection process, the authorization server appends an authorization code to the request to the client.

The client receives the authorization code and calls the authorization server’s token endpoint to exchange the authorization code for an access token appending the verification code to the request.

The authorization server verifies the code stored in memory using the validation code. It also verifies the authorization code. If both codes are valid, the authorization server returns an access token (and a refresh token, if configured) to the client.

The client requests access to the protected resource from the resource server.

The resource server contacts the authorization server to validate the access token.

The authorization server validates the token and responds to the resource server.

If the token is valid, the resource server allows the client to access the protected resource.

The end user wants to use the services provided by the relying party (RP). The RP, usually a web-based service, requires an account to provide those services.

To access the end user’s information in the OpenID provider (OP), the RP requires end user consent. When using the PKCE standard, the RP must generate a unique code and a way to verify it, and append the code to the request for the authorization code.

The RP redirects the end user’s user-agent with code_challenge and code_challenge_method...

...to the OP.

The OP authenticates the end user, confirms resource access, and gathers consent if necessary.

On success, the OP stores the code challenge and its method.

The OP redirects the end user’s user-agent to the redirection URI, usually at the RP.

During the redirection process, the OP appends an authorization code.

The RP authenticates to the OP and exchanges the authorization code for an access token and an ID token, appending the verification code to the request.

The OP verifies the code challenge it stored using the validation code, and verifies the authorization code.

If the codes are valid, the OP issues an access token and an ID token to the RP.

The RP validates the ID token and its claims.

If the RP requires additional claims, it sends a request to the /oauth2/userinfo endpoint with the access token for authorization.

If the access token is valid, the /oauth2/userinfo endpoint returns any additional claims.

Create an application owner profile and record the username and password.

Register a client application.

Create a resource owner profile and record the username and password.

The client redirects the resource owner’s user-agent to the authorization server’s /oauth2/authorize endpoint, including the following query parameters:

https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/authorize
?client_id=myClient
&response_type=code
&scope=write
&redirect_uri=https://www.example.com:443/callback
&code_challenge=K7Dz7AcV1urbgo4FYNgy2QAAz6v2LyIdmmGPzsFZbAc
&code_challenge_method=S256
&state=abc123

The resource owner authenticates to the authorization server. In this demonstration, they sign in using the default journey configured for the realm.

Inspect the URL in the browser.

Follow the steps to get an access token.

Authenticate as the resource owner.

$ curl \
--request POST \
--header 'Content-Type: application/json' \
--header 'X-OpenAM-Username: <resource-owner-username>' \
--header 'X-OpenAM-Password: <resource-owner-password>' \
--header "Accept-API-Version: resource=2.0, protocol=1.0" \
'https://<tenant-env-fqdn>/am/json/realms/root/realms/alpha/authenticate'
{"tokenId":"<tokenId>","successUrl":"/enduser/?realm=/alpha","realm":"/alpha"}

As the client, call the /oauth2/authorize endpoint to request the authorization code. Provide the resource owner’s SSO token in a cookie and the following parameters:

Follow the steps to get an access token.

Create an application owner profile and record the username and password.

Register a client application.

Configure the duration of the request URI:

Create a resource owner profile and record the username and password.

Ensure the client has retrieved a request URI by following the steps described in Get a PAR request URI.

The client redirects the resource owner’s user-agent to the authorization server’s /oauth2/authorize endpoint including the following query parameters:

https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/authorize \
?client_id=myClient \
&request_uri=<par_request_uri>
&response_type=code \
&scope=write \
&state=abc123 \
&redirect_uri=https://www.example.com:443/callback

The resource owner authenticates to the authorization server. In this demonstration, they sign in using the default journey configured for the realm.

Inspect the URL in the browser.

Follow the steps to get an access token.

Ensure the client has retrieved a request URI by following the steps described in Get a PAR request URI.

Authenticate as the resource owner.

$ curl \
-i \
--request POST \
--header "Content-Type: application/json" \
--header 'X-OpenAM-Username: <resource-owner-username>' \
--header 'X-OpenAM-Password: <resource-owner-password>' \
--header "Accept-API-Version: resource=2.0, protocol=1.0" \
'https://<tenant-env-fqdn>/am/json/realms/root/realms/alpha/authenticate'
{"tokenId":"<tokenId>","successUrl":"/enduser/?realm=/alpha","realm":"/alpha"}

As the client, call the /oauth2/authorize endpoint to request the authorization code. Provide the resource owner’s SSO token in a cookie and the following parameters:

$ curl --dump-header - \
--request POST \
--Cookie "<session-cookie-name>=<tokenId>" \
--data "request_uri=<par_request_uri>" \
--data "client_id=myClient" \
--data "scope=write" \
--data "response_type=code" \
--data "csrf=<tokenId>" \
--data "redirect_uri=https://www.example.com:443/callback" \
--data "state=abc123" \
--data "decision=allow" \
"https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/authorize"

HTTP/2 302
...
location: https://www.example.com:443/callback?code=<authorization-code>&iss...
...

Perform the steps in Exchange an authorization code for an access token to get an access token.

The client, usually a single-page application (SPA), receives a request to access a protected resource. To access the resource, the client requires authorization from the resource owner.

The client redirects the resource owner’s user-agent or opens a new frame to the Identity Cloud authorization service.

The authorization server authenticates the resource owner, confirms resource access, and gathers consent if not previously saved.

If the resource owner’s credentials are valid, the authorization server returns the access token to the user-agent as part of the redirection URI.

Now, the client must extract the access token from the URI. In this example, the user-agent follows the redirection to the web-hosted server that contains the protected resource without the access token.

The web-hosted server returns a web page with an embedded script to extract the access token from the URI.

The user-agent executes the script and retrieves the access token.

The user-agent returns the access token to the client.

The client requests access to the protected resources presenting the access token to the resource server.

The resource server contacts the authorization server to validate the access token.

The authorization server validates the token and responds to the resource server.

If the token is valid, the resource server allows the client to access the protected resource.

The RP, usually an SPA, receives a request to access user information at the OP. To access this information, the RP requires authorization from the end user.

The RP redirects the end user’s user-agent or opens a new frame to the OP.

The OP authenticates the end user, confirms resource access, and gathers consent if necessary.

On success, the OP returns access and ID tokens to the user-agent in the redirection URI.

The user-agent extracts the tokens from the URI.

The RP returns a web page with an embedded script to extract the tokens from the URI.

The user-agent executes the script and retrieves the tokens.

The user-agent returns the tokens to the RP.

The RP validates the ID token and its claims.

If the RP requires additional claims, it sends a request to the /oauth2/userinfo endpoint with the access token for authorization.

If the access token is valid, the /oauth2/userinfo endpoint returns any additional claims.

Create an application owner profile and record the username and password.

Register a client application.

Create a resource owner profile and record the username and password.

The client redirects the resource owner’s user-agent to the authorization server’s /oauth2/authorize endpoint, including the following query parameters:

https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/authorize \
?client_id=myClient \
&response_type=token \
&scope=write \
&redirect_uri=https://www.example.com:443/callback \
&state=abc123

The resource owner authenticates to the authorization server. In this demonstration, they sign in using the default journey configured for the realm.

Inspect the URL in the browser.

Authenticate as the resource owner.

$ curl \
--request POST \
--header "Content-Type: application/json" \
--header 'X-OpenAM-Username: <resource-owner-username>' \
--header 'X-OpenAM-Password: <resource-owner-password>' \
--header "Accept-API-Version: resource=2.0, protocol=1.0" \
'https://<tenant-env-fqdn>/am/json/realms/root/realms/alpha/authenticate'
{"tokenId":"<tokenId>","successUrl":"/enduser/?realm=/alpha","realm":"/alpha"}

As the client, call the /oauth2/authorize endpoint to request the authorization code. Provide the resource owner’s SSO token in a cookie and the following parameters:

$ curl \
--Cookie "<session-cookie-name>=<tokenId>" \
--request POST \
--data "client_id=myClient" \
--data "response_type=token" \
--data "scope=write" \
--data "state=123abc" \
--data "decision=allow" \
--data "csrf=<tokenId>" \
--data "redirect_uri=https://www.example.com:443/callback" \
"https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/authorize"

HTTP/2 302
...
location: https://www.example.com:443/callback#access_token=<access-token>&iss...
...

HTTP/2 302
...
location: https://www.example.com:443/callback#access_token=<access-token>&&id_token=<id_token>...
...

Create an application owner profile and record the username and password.

Register a client application.

Create a resource owner profile and record the username and password.

Under Native Consoles > Access Management, go to Realms > Realm Name > Services > OAuth2 Provider > Advanced and check that the Grant Types field includes Resource Owner Password Credentials.

The resource owner provides their credentials to the client. This is done outside the scope of this procedure.

As the client, call /oauth2/access_token specifying the resource owner’s and the client’s credentials, and grant_type=password.

$ curl \
--request POST \
--user '<client-id>:<client-secret>' \
--data "grant_type=password" \
--data "username=<resource-owner-username>" \
--data "password=<resource-owner-password>" \
--data "scope=write" \
'https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/access_token'

{
  "access_token": "<access-token>",
  "refresh_token": "<refresh-token>",
  "scope": "write",
  "token_type": "Bearer",
  "expires_in": 3599
}

Create an application owner profile and record the username and password.

Register a client application.

Create a resource owner profile and record the username and password.

Under Native Consoles > Access Management, go to Realms > Realm Name > Services > OAuth2 Provider > Advanced and ensure the Grant Types field includes Client Credentials.

Create an application owner profile and record the username and password.

Register a client application.

Create a resource owner profile and record the username and password.

As the client, call the /oauth2/device/code endpoint, specifying at least the client ID, myClient.

$ curl \
--request POST \
--data "client_id=myClient" \
--data "scope=write" \
"https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/device/code"
{
    "interval": 5,
    "device_code": "7a95a0a4-6f13-42e3-ac3e-d3d159c94c55...",
    "verification_uri": "https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/device/user",
    "verification_url": "https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/device/user",
    "verification_uri_complete": "https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/device/user?user_code=VAL12e0v",
    "user_code": "VAL12e0v",
    "expires_in": 300
}

The client device must now instruct the user to enter the user code and grant access to the OAuth 2.0 device.

The client device must start polling the authorization server for the access token using the interval and device code information obtained in the previous step.

The resource owner logs in to the authorization server.

$ curl \
--include \
--request POST \
--header "Content-Type: application/json" \
--header "X-OpenAM-Username: <resource-owner-username>" \
--header "X-OpenAM-Password: <resource-owner-password>" \
--header "Accept-API-Version: resource=2.0, protocol=1.0" \
'https://<tenant-env-fqdn>/am/json/realms/root/realms/alpha/authenticate'
{
  "tokenId":"<tokenId>",
  "successUrl":"/enduser/?realm=/alpha",
  "realm":"/alpha
"}

As the client, call the /oauth2/device/user endpoint. Provide the resource owner’s SSO token in a cookie, and at least the following parameters:

$ curl \
--request POST \
--header "Cookie: <session-cookie-name>=<tokenId>" \
--data "user_code=VAL12e0v" \
--data "decision=allow" \
--data "csrf=<tokenId>" \
"https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/device/user"

<!DOCTYPE html>
<!--
  Copyright …​
-→
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <meta name="description" content="OAuth2 Authorization">
  <title>OAuth2 Authorization Server</title>
</head>

<body style="display:none">
<div id="wrapper">Loading…​</div>
<footer id="footer" class="footer"></footer>
<script type="text/javascript">
  pageData = {
      locale: "en_US",
      baseUrl : "https://<tenant-env-fqdn>/am",
      realm : "\/alpha",
      done: true
  };
</script>
<script src="https://<tenant-env-fqdn>/am/main-device.js"></script>
</body>
</html>

$ curl \
--request POST \
--header "Cookie: iPlanetDirectoryPro=ne1QUOjPzY0r…​" \
--header "Accept: application/json" \
--data "user_code=Gp4qkX4G" \
--data "decision=allow" \
--data "csrf=ne1QUOjPzY0r…​" \
"https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/device/user"
{
  "baseUrl": "https://<tenant-env-fqdn>/am",
  "errorCode": null,
  "realm": "/alpha",
  "csrf": "1hQSplblZgaErLQ0/1rvcEvw5lj/cJQx3lrC3dV/3ac=",
  "locale": "en_US",
  "userCode": "Gp4qkX4G"
}

pageData = {
    locale: "en_US",
    errorCode: "not_found",
    realm : "/alpha",
    baseUrl : "https://<tenant-env-fqdn>/am"
    oauth2Data: {
          csrf: "ErFIk8pMraJ1rvKbloTgpp6b7GZ57kyk9HaIiKMVK3g=",
          userCode: "VAL12e0v"
    }
}

The resource owner navigates to the verification URL acquired with the user code. For example:

https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/device/user

The resource owner logs in to the authorization server.

The resource owner enters their user code:

Figure 13. OAuth 2.0 User Code

The resource owner authorizes the device flow client by allowing the requested scopes:

Figure 14. OAuth 2.0 Consent Page

Identity Cloud adds the OAuth 2.0 client to the user’s profile page in the Authorized Apps section and displays that the user is done with the flow:

Figure 15. OAuth 2.0 Done Page

On the client device, create a POST request to poll the /oauth2/access_token endpoint to request an access token specifying, at least, the following parameters:

$ curl \
--request POST \
--data "client_id=myClient" \
--data "grant_type=urn:ietf:params:oauth:grant-type:device_code" \
--data "device_code=<your-device-code>" \
"https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/access_token"

{
    "access_token": "<access-token>",
    "refresh_token": "<refresh-token>",
    "scope": "write",
    "token_type": "Bearer",
    "expires_in": 3599
}

{
    "error": "authorization_pending",
    "error_description": "The user has not yet completed authorization"
}

{
    "error": "slow_down",
    "error_description": "The polling interval has not elapsed since the last request"
}

Create an application owner profile and record the username and password.

Register a client application.

Create a resource owner profile and record the username and password.

As the client, call the /oauth2/device/code endpoint, specifying at least the following parameters:

$ curl \
--request POST \
--data "client_id=myClient" \
--data "code_challenge=<your-code-challenge>" \
--data "code_challenge_method=S256" \
--data "scope=write" \
"https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/device/code"
{
    "interval": 5,
    "device_code": "7a95a0a4-6f13-42e3-ac3e-d3d159c94c55...",
    "verification_uri": "https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/device/user",
    "verification_url": "https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/device/user",
    "verification_uri_complete": "https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/device/user?user_code=VAL12e0v",
    "user_code": "VAL12e0v",
    "expires_in": 300
}

The client device should now provide instructions to the user to enter the user code and grant access to the OAuth 2.0 device.

The client device should also begin polling the authorization server for the access token using the interval and device code information obtained in the previous step and the PKCE code verifier.

The resource owner logs in to the authorization server.

$ curl \
--include \
--request POST \
--header "Content-Type: application/json" \
--header "X-OpenAM-Username: <resource-owner-username>" \
--header "X-OpenAM-Password: <resource-owner-password>" \
--header "Accept-API-Version: resource=2.0, protocol=1.0" \
'https://<tenant-env-fqdn>/am/json/realms/root/realms/alpha/authenticate'
{
  "tokenId":"<tokenId>",
  "successUrl":"/enduser/?realm=/alpha",
  "realm":"/alpha
"}

As the client, call the /oauth2/device/user endpoint. Provide the resource owner’s SSO token in a cookie, and at least the following parameters:

$ curl \
--request POST \
--header "Cookie: <session-cookie-name>=<tokenId>" \
--data "user_code=VAL12e0v" \
--data "decision=allow" \
--data "csrf=<tokenId>" \
"https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/device/user"

<!DOCTYPE html>
<!--
  Copyright …​
-→
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <meta name="description" content="OAuth2 Authorization">
  <title>OAuth2 Authorization Server</title>
</head>

<body style="display:none">
<div id="wrapper">Loading…​</div>
<footer id="footer" class="footer"></footer>
<script type="text/javascript">
  pageData = {
      locale: "en_US",
      baseUrl : "https://<tenant-env-fqdn>/am",
      realm : "\/alpha",
      done: true
  };
</script>
<script src="https://<tenant-env-fqdn>/am/main-device.js"></script>
</body>
</html>

$ curl \
--request POST \
--header "Cookie: iPlanetDirectoryPro=ne1QUOjPzY0r…​" \
--header "Accept: application/json" \
--data "user_code=Gp4qkX4G" \
--data "decision=allow" \
--data "csrf=ne1QUOjPzY0r…​" \
"https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/device/user"
{
  "baseUrl": "https://<tenant-env-fqdn>/am",
  "errorCode": null,
  "realm": "/alpha",
  "csrf": "1hQSplblZgaErLQ0/1rvcEvw5lj/cJQx3lrC3dV/3ac=",
  "locale": "en_US",
  "userCode": "Gp4qkX4G"
}

pageData = {
    locale: "en_US",
    errorCode: "not_found",
    realm : "/alpha",
    baseUrl : "https://<tenant-env-fqdn>/am"
    oauth2Data: {
          csrf: "ErFIk8pMraJ1rvKbloTgpp6b7GZ57kyk9HaIiKMVK3g=",
          userCode: "VAL12e0v"
    }
}

The resource owner navigates to the verification URL acquired with the user code. For example:

https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/device/user

The resource owner logs in to the authorization server.

The resource owner enters their user code:

Figure 17. OAuth 2.0 User Code

The resource owner authorizes the device flow client by allowing the requested scopes:

Figure 18. OAuth 2.0 Consent Page

Identity Cloud adds the OAuth 2.0 client to the user’s profile page in the Authorized Apps section and displays that the user is done with the flow:

Figure 19. OAuth 2.0 Done Page

On the client device, create a POST request to poll the /oauth2/access_token endpoint to request an access token specifying, at least, the following parameters:

$ curl \
--request POST \
--data "client_id=myClient" \
--data "grant_type=urn:ietf:params:oauth:grant-type:device_code" \
--data "device_code=<your-device-code>" \
--data "code_verifier=<your-code-verifier>" \
"https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/access_token"

{
    "access_token": "<access-token>",
    "refresh_token": "<refresh-token>",
    "scope": "write",
    "token_type": "Bearer",
    "expires_in": 3599
}

{
    "error": "authorization_pending",
    "error_description": "The user has not yet completed authorization"
}

{
    "error": "slow_down",
    "error_description": "The polling interval has not elapsed since the last request"
}

Under Native Consoles > Access Management, go to Realms > Realm Name > Applications > OAuth 2.0 > Trusted JWT Issuer.

Click + Add Trusted JWT Issuer Agent, provide the following settings, and then click Create:

Configure at least the issuer’s public keys by setting either of these fields:

Configure additional settings as necessary:

Save your changes.

Create an application owner profile and record the username and password.

Register a client application.

Create a resource owner profile.

Record the identifier of the profile to use as the sub claim in the JWT.

In the Identity Cloud admin UI, select Scripts > Auth Scripts > + New Script.

In the New Script window, select OAuth2 May Act and continue.

In the new script window, name the script May act and save the following JavaScript:

(function () {
    var frJava = JavaImporter(
        org.forgerock.json.JsonValue
    );

    var mayAct = frJava.JsonValue.json(frJava.JsonValue.object())
    mayAct.put('client_id', 'impersonationClient')
    token.setMayAct(mayAct)
}());

Create a confidential OAuth 2.0 client account to get an original token for the subject.

Add the following settings under Sign On > General Settings and save your work:

Override OAuth 2.0 provider settings for this client.

Create a confidential OAuth 2.0 client account for the service that acts on behalf of the user.

Add the following settings under Sign On > General Settings and save your work:

Create a user profile.

Record the username and password.

In the Identity Cloud admin UI, select Scripts > Auth Scripts > + New Script.

In the New Script window, select OAuth2 May Act and continue.

In the new script window, name the script May act and save the following JavaScript:

(function () {
    var frJava = JavaImporter(
        org.forgerock.json.JsonValue
    );

    var mayAct = frJava.JsonValue.json(frJava.JsonValue.object())
    mayAct.put('client_id', 'delegateClient')
    mayAct.put('sub', 'delegateClient')
    token.setMayAct(mayAct)
}());

Create a confidential OAuth 2.0 client account to get an original token for the subject.

Add the following settings under Sign On > General Settings and save your work:

Override OAuth 2.0 provider settings for this client.

Create a confidential OAuth 2.0 client account for the service that acts on behalf of the user.

Add the following settings under Sign On > General Settings and save your work:

Create a user profile.

Record the username and password.