35 Configuring OAuth Services in 12c
Oracle Access Management (OAM) OAuth helps secure access to services. OAuth services are enabled as a part of the OAM 12c installation process. OAM provides an API based approach for configuring OAuth Services. During set up, you need to configure OAuth clients and resources in Oracle Access Manager.
This chapter contains the following sections:
35.1 Set-up OAuth Services
You are an administrator and are responsible for setting up OAuth. You want to configure OAuth to secure access to services. During set up, you need to configure OAuth clients and resources in Oracle Access Manager. This section describes how to enable and manage OAuth Services using APIs.
You have the following responsibilities as an administrator.
-
Configure and manage OAuth Identity Domain
-
Configure and manage OAuth Resources
-
Configure and manage OAuth Clients
-
Ensure that the communication between different services is secure
-
Access protected services through REST API calls
Pre-requisite for OAuth configuration
-
Ensure you have the required OAuth Administrator permissions
-
Ensure the 12c environment is installed. See Installing the Oracle Identity and Access Management Software in Fusion Middleware Installing and Configuring Oracle Identity and Access Management
-
Ensure OAuth and OpenIDConnect Service is enabled in Available Services of the Configuration Section. See Available Services of the Common Configuration Section
-
Configure OAuth Resources and Clients
-
Obtain a Client Access Token
Setting Up OAuth: Task Flow
This section describes the high-level tasks in setting up OAuth in OAM. You start setting up OAuth by creating an identity domain and registering a resource. An OAuth Resource needs to be registered before registering an OAuth Client, as the resource information, specifically the API details, are required while registering a client.
-
To create an identity domain using REST API calls, refer to Creating an Identity Domain
-
To register a new resource using REST API calls, refer to Creating a Resource
-
After a resource is registered, you can configure and register an OAuth Client. To register a trusted client using REST API calls, refer to Creating a Client
For more information on OAuth REST APIs, See REST API for OAuth in Oracle Access Manager
35.2 Configuring OAuth Services Settings
OAuth Services has many components that must be configured before the authorization protocol can be used.
Descriptions of the OAuth Services components and how they work together can be found in Understanding the OAuth Services Components. This section includes information on configuring the OAuth Services components.
This section describes the following topics:
35.2.1 Creating an Identity Domain
An Identity Domain corresponds to the notion of a tenant. All clients and resource servers are created under an Identity Domain.
curl
command to create an identity domain are:
-
identityProvider: UserIdentityStore to perform the authentication against (Password Grant Flows). If not specified this is defaulted to the DefaultIdentityStore - "UserIdentityStore1"
-
errorPageURL: Custom error page to be used in the case of 3 legged flows. If not specified it is defaulted to OAM server's error page.
-
consentPageURL: Customer consent page to be used in case of 3 legged flows. If not specified uses the custom consent page shipped with OAM.
-
tokenSettings: Token defaults are maintained at the IdentityDomain level. If tokenSettings is not specified the default values for the ACCESS_TOKEN and others are used.
Note:
If RefreshToken needs to be generated along with AccessToken,refreshTokenEnabled=true
must be set, under ACCESS_TOKEN settings.
Endpoint for CRUD operations:
http:<AdminServerHost:Port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/oauthidentitydomain
Note:
Use Content-Type:application/json in the REST API HTTP request.There are 2 ways to create the Identity Domain
-
Simple: In this mode, just the name and description of the IdentityDomain to be created are used. The rest of the values are defaulted.
-
Detailed: In this mode, you can give specific values to the different parameters.
- In Simple mode, a sample
curl
command to create a domain is shown.curl -i -H 'Content-Type: application/x-www-form-urlencoded' -H 'Authorization:Basic d2VibG9naWM6V2VsY29tZTE=' --request POST http:<Servername>:<Port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/oauthidentitydomain -d '{"name":"TestDomain","description":"Test Domain"}'
- In Detailed mode, a sample
curl
command to create a domain using scopes is shown below.curl -i -H 'Content-Type: application/x-www-form-urlencoded' -H 'Authorization:Basic d2VibG9naWM6V2VsY29tZTE=' --request POST http:<Servername>:<Port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/oauthidentitydomain -d '{"name":"TestDomain","identityProvider":"UserIdentityStore1","description":"Test Domain"}' HTTP/1.1 200 OK Date: Fri, 28 Jul 2017 13:01:41 GMT Content-Length: 860 Content-Type: text/plain X-ORACLE-DMS-ECID: 78d30c19-07b6-4ac2-a39b-f1cbd8182ebb-000003fd X-ORACLE-DMS-RID: 0 Set-Cookie: JSESSIONID=_oGJSc7Vt2vIWLNQ_uwYCZz151JqOXewJRIkyvstnnio8WsNborT!-1875566563; path=/; HttpOnly Sucessfully created entity - OAuthIdentityDomain, detail - OAuth Identity Domain :: Name - TestDomain, Id - 1636d0492f36447087780abdfdc4c15f, Description - Test Domain, TrustStore Identifiers - [TestDomain], Identity Provider - UserIdentityStore1, TokenSettings - [{"tokenType":"ACCESS_TOKEN","tokenExpiry":3600,"lifeCycleEnabled":false,"refreshTokenEnabled":false, "refreshTokenExpiry":86400,"refreshTokenLifeCycleEnabled":false}, {"tokenType":"AUTHZ_CODE","tokenExpiry":3600,"lifeCycleEnabled":false,"refreshTokenEnabled":false,"refreshTokenExpiry":86400, "refreshTokenLifeCycleEnabled":false}, {"tokenType":"SSO_LINK_TOKEN","tokenExpiry":3600,"lifeCycleEnabled":false, "refreshTokenEnabled":false,"refreshTokenExpiry":86400,"refreshTokenLifeCycleEnabled":false}], ConsentPageURL - /oam/pages/consent.jsp, ErrorPageURL - /oam/pages/error.jsp, CustomAttrs - null
35.2.2 Enabling Consent Management
You can enable Consent Management for each of the OAuth Identity Domains or all the OAuth Identity Domains in OAM.
During the 3-legged OAuth flow, OAM presents a consent page enabling you to grant access to the resource. If Consent Management is enabled, your consent is saved, and OAM skips the consent on subsequent 3-legged OAuth flows. For details about the 3-legged OAuth Flow, see Understanding 3-Legged Authorization
By default, Consent Management is disabled.
To enable Consent Management per OAuth Identity Domain, create or modify
the OAuth Identity Domain by setting the custom attribute
consentExpiryTimeInMinutes
using the Admin Server OAuth
API.
For example:
curl --header 'Authorization: Basic d2VibG9naWM6d2VsY29tZTE=' \
--header 'Content-Type: application/json' \
--request POST 'http:<Servername>:<Port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/oauthidentitydomain' \
--data-raw '{"name":"MyDomain","identityProvider":"UserIdentityStore1","description":"MyDomain",
"tokenSettings":[{"tokenType":"ACCESS_TOKEN","tokenExpiry":3600,"lifeCycleEnabled":false,"refreshTokenEnabled":false,"refreshTokenExpiry":86400,"refreshTokenLifeCycleEnabled":false}],
"errorPageURL":"/oam/pages/error.jsp","consentPageURL":"/oam/pages/consent.jsp",
"customAttrs":"{\"domainCertValidityInDays\":\"30\", \"consentExpiryTimeInMinutes\":\"10\"}"}
'
where, consentExpiryTimeInMinutes
in minutes is the
duration, during which the OAuth consent stays valid.
Beyond this duration, OAM presents the consent page again during the 3-legged OAuth flow, and you must grant the consent.
OAM allows each of the OAuth Identity Domains to enable, disable, or
change the consent validity period using
consentExpiryTimeInMinutes
.
consentExpiryTimeInMinutes
system property while starting
OAM.
- Stop all the Administration and Managed Servers.
- Edit the
$OAM_DOMAIN_HOME/bin/setDomainEnv.sh
, and add theconsentExpiryTimeInMinutes
property under EXTRA_JAVA_PROPERTIES as shownEXTRA_JAVA_PROPERTIES="-DconsentExpiryTimeInMinutes=10"
- Start the Administration and Managed Servers.
Note:
System property overrides the individual Consent Management configuration on each OAuth Identity Domains.See Also, REST API for OAuth in Oracle Access Manager.
35.2.3 Creating a Resource
A Resource Server hosts protected resources. The resource server is capable of accepting and responding to protected resource requests using access tokens.
curl
command to create a resource are:
-
Name: Name of the Resource Server
-
Scopes: The following two parameters are used
-
scopeName - Name of the scope
-
description - Description of the scope
-
-
idDomain - Name of the IdentityDomain under which this resource server is created
-
tokenAttributes - List of custom attributes that are sent by the server, as part of the access token. The attributes can be "STATIC" in which case the value is substituted as is. If "DYNAMIC", the attributeValue is evaluated and populated in the final AccessToken.
Note:
Scopes are referred to by prefixing the resource server name. This makes them unique across resource servers.
Endpoint for CRUD operations:
http:<AdminServerHost:Port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/application
Note:
Use Content-Type:application/json in the REST API HTTP request.35.2.4 Creating a Client
A Client is an application making protected resource requests on behalf of the resource owner and with the resource owner's authorization.
curl
command to create a client are:
-
Name: Name of the client
-
idDomain: Name of the identityDomain under which the client is created
-
secret: Client secret incase of a CONFIDENTIAL_CLIENT
-
clientType: Type of client. Supported values - CONFIDENTIAL_CLIENT, PUBLIC_CLIENT, MOBILE_CLIENT
-
redirectURIs: List of redirectURIs configured for the client
-
attributes: List of custom attributes configured for the client
-
grantTypes: List of allowed grant types. Allowed values - PASSWORD, CLIENT_CREDENTIALS, JWT_BEARER, REFRESH_TOKEN, AUTHORIZATION_CODE
-
Scopes: List of scopes that the client can request access to.
-
scopeName - Name of the scope. This is referred to by the <ResourceServerName>.<ScopeName>
-
-
defaultScope - This is the default scope that the access token is generated with, If no scope is specified during the Runtime Flows.
Endpoint for CRUD operations:
http:<AdminServerHost:Port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/client
Note:
Use Content-Type:application/json in the REST API HTTP request.35.3 Enabling Consent Management on MDC
Follow the steps in this section to enable Consent Management on MDC.
Note:
To enable consent managemet for a pre-existing MDC configuration, you must re-configure MDC.- Setup two OAM environments DC1 (Master) and DC2 (Clone).
- Set the
consentExpiryTimeInMinutes
parameter in the OAuth Identity Domain on the Master. For details, see Enabling Consent Management. - Configure OAuth on the Multi-Data Centers. For details, see Configuring OAuth in Multi-Data Centers
- Enable Automated Policy Syncronization. For details, see Enabling Automated Policy Synchronization
35.4 Configuring OAuth in Multi-Data Centers
You can configure OAuth support in Multi-Data Centers(MDC) using REST APIs.
-
Create the OAuth Artifacts - Identity Domain, Resource Server, Client and associated trust artifacts on the MasterDC.
-
Follow the steps given in Configuring Multi-Data Centers to setup MDC between two data centers.
Note:
As part of Step 2, the requests exportAccessStore on Master and importAccessStore on Clone DC are performed. This ensures that artifacts created on MasterDC are visible on CloneDC. Step 2, also ensures that the OAuth Artifacts get copied over to the Clone DC.
-
Perform
GET
commands of these artifacts on the Clone DC to confirm that OAuth has been successfully setup in MDC mode. -
Enable Automated Policy Synchronization
-
Now execute the 2 legged flows to verify MDC flows.
-
Create an Access Token as part of Password Grant Flow on DC1.
-
Send the same token to the Clone DC end point for validation.
-
The token should be valid on DC2.
-
35.5 Optional Parameters for Consent Management in Multi-Data Centers
You can set the following optional parameters in the system property of the Runtime Server on the Clone Data Center.
- Stop all the Administration and Managed Servers.
- Edit the
$OAM_DOMAIN_HOME/bin/setDomainEnv.sh
and add the parameters under EXTRA_JAVA_PROPERTIES.For example,EXTRA_JAVA_PROPERTIES="-DconsentExpiryTimeInMinutes=10"
- Start the Administration and Managed Servers.
Table 35-1 Optional Parameters for Consent Management on MDC
Parameter | Default Value | Description |
---|---|---|
failOnConsentStoreError |
true |
By default, if master DC is not available, the user consent request is not processed and an error is displayed to the user. To turn off the error, set the value of the
parameter to |
printEntitiesInRequest |
false |
Prints the body of HTTP request and response to the log. |
runtimeResourceConnTimeout |
60000 (in milliseconds; 60
seconds)
|
Specifies the connection timeout for the HTTP Request to store/fetch/delete entities to the Master DC. |
runtimeResourceReadTimeout |
60000 (in milliseconds; 60
seconds)
|
Specifies the HTTP response read timeout from the Master DC. |
sourceDcJournalThreshold |
100 |
Defines the limit for on-demand replication from the
runtime server.
After this limit, the on-demand replication sets in and all the user requests also try to fetch the results from Master. |
sourceDcJournalThresholdUpperLimit |
250 |
Defines the upper limit for on-demand replication.
If the Journal Sequence difference between the Clone DC and Master DC grows beyond the defined limit, the OAMRE-07023 error is displayed to the administrators for all user requests. |
sourceDcLastPingThresholdInSec |
600 (in seconds; 10
minutes)
|
Defines the limit for availability of the Master.
If the last ping to the Master is successful within this time limit, the master is considered available. You must always set the value of this parameter
greater than the value of
|
sourceHealthCheckIntervalInSec |
120 (in seconds; two
minutes)
|
Specifies the polling frequency for checking the connection and the latest journal sequence in Master DC. |
replication.poller.thread.interval |
120 (in seconds; two
minutes)
|
Running Replication on Policy Manager can result
into multiple instances due to Policy Manager cluster. Replication
Instance Manager Thread ensures that a single instance of
Replication is running in a clustered environment.
This parameter defines the interval, in which Replication Instance Manager Thread must run. |
replication.database.thread.interval |
120 (in seconds; two
minutes)
|
Single replication instance on Policy Manager
Cluster is maintained by having an entry in database and
continuously updating it. Every cluster keeps performing the insert
or update operation.
This parameter determines a valid database entry duration, that is, if an instance has updated the database entry within the duration, for example, 2 min, then the other instances cannot override it. But if the instance fails to update the entry, other instances can update the database entry post the duration. |
35.6 Error Codes and Troubleshooting Steps for Consent Management on MDC
The section lists the error codes and the troubleshooting steps for consent management on MDC.
Error Code | Error Description | Resolution |
---|---|---|
OAMRE-07001 | Error is logged in the Master DC if the user data has been modified but the deleted data is still present in the main store. | Manually delete the runtime data identified by the unique id present in the log. |
OAMRE-07002 , OAMRE-07018, OAMRE-07019 |
Error is logged in the Clone DC when there are multiple replication agreements pointing to the same Master DC. |
There must be only one replication agreement from Master DC (Source DC) and Clone DC(target DC). Remove the multiple replication agreeements using the replication agreement Rest APIs. |
OAMRE-07004 | Error occurs if the replication agreement has been modified and deleted, and the older replication agreement is no longer valid. | Restart the managed servers in Clone DC. |
OAMRE-07006 | Error occurs if the Master DC replication API does not work or the current replication agreement is not valid. | Restart the managed servers in Clone DC. |
OAMRE-07008 | Error is logged if MDC has been setup without the Policy Manager REST endpoint. | Add the Policy Manager REST endpoint, in the MDC
configuration, with the name
PolicyManagerRESTEndpoint |
OAMRE-07009 | Error is logged if the Replication Agreement is not present and/or the replication agreement does not have the authorization code using which the master can be connected. | Ensure the replication agreement exists with necessary authorization code. |
OAMRE-07010 , OAMRE-07011, OAMRE-07012, OAMRE-07013 , OAMRE-07016, OAMRE-07020, OAMRE-07022 | Error is logged in the Clone DC when the Master DC resources are not present and/or Master DC is not available. | Check if the Master DC resource is available and if the Master DC has been patched correctly. |
OAMRE-07014, OAMRE-07015, OAMRE-07016 | Error occurs if there is missing entity in the Master DC. | Delete the entity from the clone DC. |
OAMRE-07017 | Error occurs if the source server (Master DC) setting does not exist in the confirguration. | Check the Entity replication or Import and Export the access store again and redo the Entity and Runtime Entity Replication. |
OAMRE-07023 | Error occurs if the runtime entity replication is
out-of-sync and the journal backlog for replication has grown beyond the
value of sourceDcJournalThresholdUpperLimit
parameter.
|
This gets auto corrected once the runtime entity
replication gets in sync.
Manually Import access store and Export access store to synchronize the data again. |
Error in the clone processing server response. | Enable the HTTP request and response log by setting the
system property printEntitiesInRequest=true |
Request and response Logging is enabled by setting this property. |
35.7 Dynamic Client Registration
Dynamic client Registration (DCR) provides a way for the native mobile apps (Android) to dynamically register as clients with the OAuth Server (OAM).
This section provides the detailed process for dynamically registering clients with the Oauth Server (OAM).
35.7.1 Enabling Dynamic Client Registration
You must enable Dynamic Client Registration (DCR) at the identity domain level.
isDcrRegEnabled
set to true
using the Admin Server OAuth API, as shown.
Note:
If theisDcrRegEnabled
flag is not specified, or set to false
then DCR is disabled.
curl -X POST \
http(s)://<Admin-Server-URL>:<Admin_Server_Port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/oauthidentitydomain \
-H 'authorization: Basic d2VibG9naWM6d2VsY29tZTE=' \
-H 'cache-control: no-cache' \
-H 'content-type: application/json' \
-d '{"name":"dcr_domain","enableMultipleResourceServer":false,"description":"DCR Domain",
"tokenSettings":[{"refreshTokenEnabled":true,"refreshTokenLifeCycleEnabled":true,"refreshTokenExpiry":5400,
"lifeCycleEnabled":true,"tokenType":"ACCESS_TOKEN","tokenExpiry":1800},
{"refreshTokenEnabled":true,"refreshTokenLifeCycleEnabled":true,"refreshTokenExpiry":10800,
"lifeCycleEnabled":true,"tokenType":"AUTHZ_CODE","tokenExpiry":240}],
"customAttrs":"{\"isDcrRegEnabled\":\"true\"}"
}'
35.7.2 Creating OAuth Client Template
The OAuth client template serves as a blueprint for creating the actual clients.
Create the OAuth client template using the Admin Server OAuth API, as shown.
curl -X POST \
http(s)://<AdminServerHost:Port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/client \
-H 'authorization: Basic d2VibG9naWM6d2VsY29tZTE=' \
-H 'cache-control: no-cache' \
-H 'content-type: application/json' \
-d '{"id":"DCR_REG_STUB_oma", "secret":"welcome1",
"redirectURIs": [{"url":"http://www.dcr.com/access","isHttps":"false"}],
"scopes":["dcrreg"],"grantTypes":["IMPLICIT"],"clientType":"PUBLIC_CLIENT","idDomain":"dcr_domain",
"description":"dcr client for acme app registration","name":"DCR_REG_STUB_acme","defaultScope":"dcrreg"}'
Table 35-2 Mandatory Property and Values for Creating the OAuth Client Template
Property | Values |
---|---|
grantTypes | IMPLICIT .
|
clientType | PUBLIC_CLIENT |
idDomain | Must be the same as the domain under which the actual clients need to be created. |
name | Must be prefixed with DCR_REG_STUB_ .
Note: The prefix must not be used in regular client names. |
defaultScope | dcrreg Note: The scope field must contain only one scope and its value must bedcrreg .
|
redirectURIs | Specify the URIs as required by the actual client.
Note: The redirectURI values are automatically assigned to the actual client. |
35.7.3 Getting Registration Tokens
The mobile device apps that need to register dynamically with the Oauth Server (OAM) must first acquire the registration token.
Process Flow for Getting Registration Token
- User opens native app on the mobile device
- The native app displays Register button
- When the user clicks on the Register button, the app launches the browser with registration token URI. The request to the OAuth Server includes
domain_name
andtemplate_id
. - Based on the authentication policy configured, the user is redirected to the login form.
- After successful authentication, OAuth Server generates the registration token and returns it as a token or qrcode, based on the request.
- Using the registration token, the native app can continue to register the client.
Figure 35-1 Diagram Showing the Flow for Getting Registration Token

Registration Token Sample Request
On the mobile device, when the user (or resource-owner) opens the app, the app must send a GET
request with /dcr/token
endpoint to the Oauth Server (OAM). The /dcr/token endpoint must be protected.
The following is a request sample
GET http(s)://<server-host>:<server-port>/oauth2/rest/dcr/token?domain=dcr_domain&template_id=DCR_REG_STUB_acme&response_type=token
domain | Name of the domain under which the client has to be registered. |
template_id | The Oauth Client template ID |
response_type | Response type can be either of the following:
|
Table 35-3 Registration Token Sample Response
Configuration | Sample Response |
---|---|
Redirect URI is defined in the Client Template. In this case |
|
Redirect URI is not present and response_type is not passed, or passed as token.
|
|
Redirect URI is not present and response_type is passed as qrcode
|
|
Table 35-4 Registration Token Error Responses
Scenario | HTTP Status Code | Errror Message | Secondary Message |
---|---|---|---|
OAuth Service is not enabled | 403 | Unauthorized | Unauthorized |
Dynamic Client Registration is not enabled | 403 | Unauthorized | Unauthorized |
Required fields are not provided | 400 | Invalid Request | Required fields are missing |
Invalid Domain | 400 | Invalid Request | Invalid Domain |
Invalid Client:
|
400 | Invalid Request | Invalid Client |
Invalid Response Type | 400 | Invalid Request | Unsupported Response Type |
Client passed is not authorized to execute DCR flow | 403 | UnAuthaorized Client | UnAuthorized Client |
35.7.4 Registering the Client using the Registration Token
Use the registration token to register the clients with the OAuth Server (OAM).
Process Flow for Client Registration
- The native app sends a request containing the registration token to OAuth Server for registering the client.
- OAuth Server validates the token and registers the client. The client profile includes the following fields:
client_id auto-generated client_secret auto-generated client_name auto-generated grant type Client is registered with grant-type as Authorization_Code and Refresh_token only. scopes/default scope dcrread
is the only scope added to client profile. This is also the defaultScope.redirect_uris Derived from client template. client type By default assigned as Mobile/Native Client token attributes Derived from client template.
Figure 35-2 Diagram Showing the Flow for Client Registration

Client Registration Sample Request
The application must use the POST
method with /dcr/client
to register as client.
POST /oauth2/rest/dcr/client HTTP/1.1
Host: <OAuth Server host-name>:<OAuth server port name>
Content-Type: <can be any valid value as there is no input>
X-OAUTH-IDENTITY-DOMAIN-NAME: dcr_domain
Authorization: Bearer eyJraWQiOi.abcdsfsdfr.ascsfsdff
X-OAUTH-IDENTITY-DOMAIN-NAME | Name of domain under which the client must be created. This value must be the same as the domain name specified during token acquisition, otherwise the request will fail. |
Authorization | Registration token is provided as Bearer token. |
Client Registration Sample Response
HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-cache
Pragma: no-cache
{
"client_id": "cd885f3da58f498e830c4f636636dd23",
"client_secret": "gjDmqUVW1k",
"client_name": "oma498e830c4f636636dd23",
"redirect_uris": [
"app://callBack"
],
"client_secret_expires_at": 0,
"client_get_uri": "http(s)://<host>:<port>/oauth2/dcr/client?client_id=<id of created client>"
}
Table 35-5 Client Registration Error Responses
Scenario | HTTP Status Code | Errror Message | Secondary Message |
---|---|---|---|
OAuth Service is not enabled | 403 | Unauthorized | Unauthorized |
Dynamic Client Registration is not enabled | 403 | Unauthorized | Unauthorized |
Required fields are not provided | 400 | Invalid Request | Required fields are missing |
Invalid Domain | 400 | Invalid Request | Invalid Domain |
Invalid Token | 401 | Unauthorized | Access token is {0} , where {0} could be:
|
Fails on server | 500 | Internal Server Error | Detailed error message on what went wrong |
Client already exists | 409 | Client already exists | Client already exists |
35.7.5 Reading Client Details
Read APIs are protected using OAuth. This section provides details on how to read client information.
Generate the authorization code, for the client that needs to be read, using scope=dcrread
as shown in the following sample request.
http(s)://<server-host>:<server-port>/oauth2/rest/authz?response_type=code&client_id=cd885f3da58f498e830c4f636636dd23&domain=dcr_domain
&scope=dcrread&state=xyz&redirect_uri=http://www.dcr.com/access
Pass this authorization code to the POST
method with the /oauth2/rest/token
endpoint to generate the access token with scope=dcrread
.
Pass this access token as bearer access token using the GET
method with the /dcr/client
endpoint to read the client.
Sample Request for Retreiving Client Details
GET /oauth2/rest/dcr/client/cd885f3da58f498e830c4f636636dd23 HTTP/1.1
Host: <OAuth Server host-name>:<OAuth server port name>
Content-Type: <can be any valid value as there is no input>
X-OAUTH-IDENTITY-DOMAIN-NAME: dcr_domain
Authorization: Bearer <Access token>
{
"client_id": "cd885f3da58f498e830c4f636636dd23",
"domain": "domainName",
"client_name": "oma498e830c4f636636dd23",
"redirect_uris": [
"http://www.dcr.com/access", "other redirect URI"
]
}
35.7.6 Deleting Dynamically Registered Client
This section provides details on how to delete the dynamically registered client.
Generate the authorization code, for the client that needs to be deleted, using scope=dcrdel
as shown in the following sample request.
http(s)://<server-host>:<server-port>/oauth2/rest/authz?response_type=code&client_id=cd885f3da58f498e830c4f636636dd23&domain=dcr_domain
&scope=dcrdel&state=xyz&redirect_uri=http://www.dcr.com/access
Pass this authorization code to the POST
method with the /oauth2/rest/token
endpoint to generate the access token with scope=dcrdel.
DELETE
method with the /dcr/client
endpoint to delete the client.GET /oauth2/rest/dcr/client/cd885f3da58f498e830c4f636636dd23 HTTP/1.1
Host: <OAuth Server host-name>:<OAuth server port name>
Content-Type: <can be any valid value as there is no input>
X-OAUTH-IDENTITY-DOMAIN-NAME: dcr_domain
Authorization: Bearer <Access token>
35.8 SSO Session Linking for OAuth Tokens
In deployment scenarios where a few resources are protected by OAM while some might be accessed with OAuth, to achieve seamless SSO between the different mixes of applications, it is necessary to link the SSO session with the Access Token. SSO Session Linking for OAuth Tokens supports key OAuth deployments requiring 2 legged flows involving native mobile apps and Synchronization of OAuth Tokens with SSO tokens.
Use Case Flow
Figure 35-3 illustrates the use case flow of the SSO Ssession linking.
Figure 35-3 Use case flow for SSO Session Linking for OAuth Tokens

Description of "Figure 35-3 Use case flow for SSO Session Linking for OAuth Tokens"
Server Changes to Link SSO Session
-
When the SSO Session is created, a JWT User Token is also created. The JWT User Token has the SSO "session_id" as part of its claims.
-
Creating this JWT Token is based on configurations. When created, this token can be sent either as a cookie or a header to downstream applications. Currently the configurations are set as challenge parameters at the scheme level.
By default, the SSO link JWT token is set in the cookie.Note:
If theOAUTH_TOKEN_RESPONSE_TYPE
isheader
, the JWT token is set with the cookie nameJWTAssertion
.If the
OAUTH_TOKEN_RESPONSE_TYPE
iscookie
, the JWT token is set with the cookie nameOAUTH_TOKEN
.
Description of the illustration ssolink_challengparam.png -
Token Signing: On bootstrap a default OAuth key-certificate is boot-strapped into the server. The JWT token will be signed by the Identity Domain private key. When the JWT token is received as an assertion back, the X5T value is retrieved from the header and the associated public key is fetched, which can be used to verify the token.
-
When the token is sent back as part of the JWT Bearer flow in the OAuth Token request, the OAM server retrieves theSSO "session_id" from the token.
-
Check Valid Session: If the JWT Token has a session ID, the server knows this is a SSO Linked JWT Token. It retrieves the "sessionId" claim from the token and checks if the server session with the given ID is still valid.
-
If the session is valid, the subject from the SSO Session is compared with the “sub” field in the JWT Token. If this matches, the access token for this user is generated and returned to the client.
-
In case of an MDC Enabled environment, as part of the JWT Token creation, another claim "mdc_sso_link" is also added to the token. This claim contains the clusterId of the machine on which the session was anchored and the UserIdentityStore reference
-
When the token is sent back as part of the JWT Bearer flow in the OAuth Token request, the OAM server will retrieve the SSO Session ID from the token.
-
Check Valid Session: If the JWT Token has a session ID, the server knows this is a SSO Linked JWT Token. It retrieves the "sessionId" claim from the token and the clusterid from the mdc_sso_link claim and retrieves the session. The normal MDC flows for checking validity of the session are maintained here.
-
If session is valid, the subject from the SSO Session will be compared with the “sub” field in the JWT Token. If this matches, the access token for this user is generated and the returned to the client.
If the session has been idle for more than 15 mins(configured value), when this JWT token is checked for validity it will fail. This ensures that the rules of the session are also applied to the OAuth Access Tokens.
35.9 Runtime REST APIs for OAuth 12c
Runtime REST APIs for OAuth provides REST calls for 2-legged and 3-legged OAuth Services flows in the new 12c OAuth Server. The sections provide sample REST requests that show how to get a resource access token.
Creating Access Tokens
http://<ManagedServerHost>:<ManagedServerPort>/oauth2/rest/token
-
Using Resource Owner Credentials
Following is a sample request against the server:
curl -i -H 'Authorization: Basic U1NPTGlua0NsaWVudDp3ZWxjb21lMQ==' -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" -H "X-OAUTH-IDENTITY-DOMAIN-NAME: SSOLink" --request POST http://<ManagedServerHost>:<ManagedServerPort>/oauth2/rest/token -d 'grant_type=PASSWORD&username=weblogic&password=welcome1&scope=SSOLink.link1'
Note:
Headers of interest for all requests-
Authorization : Base64 Url encoded ClientID:secret combination.
-
X-OAUTH-IDENTITY-DOMAIN-NAME: Identity Domain that the client belongs to.
-
-
Using Client Credentials
Following is a sample request against the server:
curl -i -H 'Authorization: Basic U1NPTGlua0NsaWVudDp3ZWxjb21lMQ==' -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" -H "X-OAUTH-IDENTITY-DOMAIN-NAME: SSOLink" --request POST http://<ManagedServerHost>:<ManagedServerPort>/oauth2/rest/token -d 'grant_type=CLIENT_CREDENTIALS&scope=SSOLink.link1'
-
Using JWT Bearer Token
Following is a sample request against the server:
curl -i -H 'Authorization: Basic U1NPTGlua0NsaWVudDp3ZWxjb21lMQ==' -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" -H "X-OAUTH-IDENTITY-DOMAIN-NAME: SSOLink" -- request POST http://<ManagedServerHost>:<ManagedServerPort>/oauth2/rest/token -d 'grant_type=JWT_BEARER&scope=SSOLink.link1&assertion=<assertion token value>'
-
Using JWT Bearer Flow to get User Data through UserInfo Endpoint
If an access token got from the JWT bearer flow is required to fetch user data through
/UserInfo
endpoint, the following scopes have to be assigned to the client and requested during runtime.Scope Corresponding OpenID Scope UserInfo.email openid email UserInfo.me (default) openid (returns the username)
UserInfo.address openid address UserInfo.phone openid phone UserInfo.profile openid profile Client Profile
Following is a sample client profile, which is registered with the UserInfo related scopes.
curl -X POST \ http://<AdminServerHost:Port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/client \ -H 'Authorization: Basic d2VibG9naWM6d2VsY29tZTE=' \ -H 'Content-Type: application/json' \ -d '{"attributes":[{"attrName":"UserAttr","attrValue":"CustomStaticValue","attrType":"STATIC"}, {"attrName":"ResServerConstAttr","attrValue":"Overriding client - static attribute","attrType":"STATIC"}], "secret":"welcome1","id":"DemoClientID","scopes":["UserInfo.address", "UserInfo.email"],"clientType":"CONFIDENTIAL_CLIENT","idDomain":"DemoDomain","description":"Client Description","name":"DemoClient","grantTypes":["JWT_BEARER"],"defaultScope":"UserInfo.email","redirectURIs":[{"url":"http://localhost:8080/Sample.jsp","isHttps":true}]}'
Example
Following is an example of the token request.
curl -i -H 'Authorization: Basic U1NPTGlua0NsaWVudDp3ZWxjb21lMQ==' -H "Content- Type: application/x-www-form-urlencoded;charset=UTF-8" -H "X-OAUTH-IDENTITY- DOMAIN-NAME: SSOLink" -- request POST http://<ManagedServerHost:ManagedServerPort>/oauth2/rest/token - d 'grant_type=JWT_BEARER&scope=UserInfo.email UserInfo.address&assertion=assertion token value'
-
-
Using Refresh Token
Following is a sample request against the server:
curl -i -H 'Authorization: Basic U1NPTGlua0NsaWVudDp3ZWxjb21lMQ==' -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" -H "X-OAUTH-IDENTITY-DOMAIN-NAME: SSOLink" --request POST http://<ManagedServerHost>:<ManagedServerPort>/oauth2/rest/token -d 'grant_type=REFRESH_TOKEN&scope=SSOLink.link1&refresh_token=<RefreshTokenValue>'
-
Using Resource Owner Credentials with JWT - Client Assertion Token
Following is a sample request against the server:
curl -i -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" -H "X-OAUTH-IDENTITY-DOMAIN-NAME: SSOLink" --request POST http://<ManagedServerHost>:<ManagedServerPort>/oauth2/rest/token -d 'grant_type=PASSWORD&scope=SSOLink.link1&client_assertion=<ClientAssertionTokenValue>&client_assertion_type=JWT_BEARER&username=weblogic&password=welcome1'
Note:
-
Allowed values for client_assertion_type are JWT_BEARER andurn:ietf:params:oauth:client-assertion-type:jwt-bearer
-
redirect_uri is not expected for 2 legged flows.
-
scope is optional in 2 legged flows. If not provided, the access token will be generated with the defaultScope associated with the client (provided during client registration).
In order to achieve 3–legged flow, you need to perform few manual steps both on the OAM server and on the Webgate before proceeding. The consent page and approver page need to be protected through OAM. If the consent page is customized, this needs to be protected by a Webgate.
-
OAM server - On the created Application Domain, you need to add couple of 3 legged resources as described in the given steps.
-
Webgate - Modify the mod_wl_ohs.conf as mentioned in this section.
OAM Server side steps to be performed
-
List of all the resources to be added as part of 3 legged setup. Details for each and every resource is mentioned as in step2.
Description of the illustration all_resources.png -
Create a resource "/oauth2/rest/approval". This has to be protected by Webgate.
Description of the illustration 3legged1.png -
Create a resource "/oauth2/rest/approval/skip". This has to be protected by Webgate.
-
Create a resource "/oam/pages/consent.jsp" which is the out of the box consent page. If you are using a custom consent page, it needs to be protected by Webgate and the appropriate resource has to be added here.
Description of the illustration consent_resource.png -
Create a resource "/oauth2/rest/**" and mark the Protection level as
Excluded
.
Description of the illustration 3legged3.png -
Create a resource "/oam/**" and mark the Protection level as
Excluded
.
Description of the illustration oam_resource.png
Webgate Side steps to be performed
Open and update the mod_wl_ohs.conf file which is located at <OHS_HOME>/user_projects/domains/base_domain/config/fmwconfig/components/OHS/<ohs instance name>
location and add the below entry.
<Location /oauth2> SetHandler weblogic-handler WebLogicHost <Managed Server Host Name> WebLogicPort <Managed Server Port> ErrorPage http:/WEBLOGIC_HOME:WEBLOGIC_PORT/ </Location> <Location /oam> SetHandler weblogic-handler WebLogicHost <Managed Server Host Name> WebLogicPort <Managed Server Port> ErrorPage http:/WEBLOGIC_HOME:WEBLOGIC_PORT/ </Location>
3 Legged Flows
-
Through the Browser request the Authorization Code
Following is a sample request against the server
http://<OHS Hostname>:<OHS Port>/oauth2/rest/authz?response_type=code&client_id=TestClient2&domain=TestDomain1&scope=TestRS.scope1+TestRS.scope2+TestRS.scope3&state=xyz&redirect_uri=http://localhost:8080/SampleTest/index.jsp
-
Generate the Access Token using the Authorization Code
Following is a sample request against the server
curl --request POST \ --url http://<ManagedServerHost>:<ManagedServerPort>/oauth2/rest/token --header 'authorization: Basic U1NPTGlua0NsaWVudDp3ZWxjb21lMQ==' --header 'cache-control: no-cache' --header 'content-type: application/x-www-form-urlencoded' --header 'x-oauth-identity-domain-name: SSOLink' --data grant_type=AUTHORIZATION_CODE&code=bnAreDZVMUxEemZtZmJPUEE2U1N2QT09fmVBUVJZYnFtYmZFSU1EaUFpSktvQjVwQ0ZGQm4xV1R4dmJrekp0MTdDZXdPYjJFNjEwVkdhZlN3VWJjTWcvRUpwL3RqWERUZWliZWdUSzZPQkxQNktwQk03c0ZKMEV1NmN3SmxwbGl5b1U4MnZ6S1pXRFB6ekdiU1k3V3FEZ3lLSjgxM0NwUGNwUjk1eXI5enRKb0ZLb1VVZ0hqNm53TkVFTEpKMmtKNmY3b1ZHWDFtcFkvL1haMUs4N0xiRGlnbkFwTWpHd1J5QjVuZkdxTzh4U01hamdWZnNmT3doSlo1SS9KY3NtOGNaQkJxMDd3SzgrWXBIcVYxYlgxYzFLSWhubW5MWndZQTg5ZnV0aU1Kam54bytZaGZhbW5IK2xrNjFBYVhxOHB5SEdENG5SRzJ2aytDcjRHR1g2OWZFbTdT&redirect_uri=http%3A%2F%2Fredirect_uri'
Validating Access Tokens
curl -i -H "X-OAUTH-IDENTITY-DOMAIN-NAME: SSOLink" --request GET "http://<ManagedServerHost>:<ManagedServerPort>/oauth2/rest/token/info?access_token=<AccessToken>"
35.10 Proof Key for Code Exchange (PKCE) Support in OAM
This section provides details about the Proof Key for Code Exchange (PKCE) enhancement.
In OAuth 2.0, 3-legged flow, public clients that use the
authorization_code
, client_id
, and
client_secret
parameters for requesting access token from the
authorization server are vulnerable to interception attacks. Once the attacker gains
access to the authorization code and the client_secret
, it can also
retrieve the access token, therefore compromising the entire security of the 3-legged
flow.
To prevent this, OAM provides Proof Key for Code Exchange (PKCE) support for OAuth 2.0 authorization code grant flow.
In a typical PKCE flow, the clients use a temporary one-time dynamic credential called
code_verifier
instead of the static client_secret
.
A SHA256 hashed string is generated from the code_verifier
called the
code_challenge
, which is then used to request the Authorization
Code. The access token is then requested from the authorization server by sending the
authorization code along with the code_verifier
in the request. The
authorization server (OAM) hashes the code_verifier
and compares it
with the previously received code_challenge
. Only if these two values
match, the access token is issued, thereby enhancing the security of the authorization
code grant flow.
OAM implements PKCE, as defined in RFC7636.
Refer to https://tools.ietf.org/html/rfc7636 for information.
See the following sections for more details about enabling PKCE and generating access token through PKCE flow.
35.10.1 Enabling PKCE
If you need enhanced security with the 3-legged OAuth 2.0 code grant flow,
you can enable PKCE by setting UsePKCE
either at the domain or client
level.
- The
UsePKCE
values are case-sensitive. - The domain level values are applicable to all the clients under that specific
domain. If you need to apply PKCE for a specific client, you can enable PKCE by
setting the
UsePKCE
parameter only for that client. - The client level values take precedence over the domain level values.
Enabling PKCE at Domain Level
UsePKCE
in customAttrs
and setting it to one of the following values:
Values | Behavior and Description |
---|---|
ALL_CLIENTS_TYPES |
PKCE is enabled for all client types. If the PKCE parameters
|
ALL_CLIENTS_TYPES_STRICT |
PKCE is enabled for all client types. If the PKCE parameters
|
PUBLIC_CLIENTS |
PKCE is enabled for If the PKCE parameters
For non-public clients, that PKCE parameters are ignored if used. |
PUBLIC_CLIENTS_STRICT |
PKCE is enabled for If the PKCE parameters
|
The following example shows a sample request to enable PKCE when
creating the domain. To update an existing domain with PKCE parameters use the
PUT
method.
See Identity Domain REST Endpoints for the REST API documentation.
curl --request POST '<AdminServer>:<AdminPort>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/oauthidentitydomain' \
--header 'Authorization: Basic d2VibG9naWM6d2VibG9naWMx' \
--header 'Content-Type: application/json' \
--header 'Cookie: JSESSIONID=OweshB5ejqWvx6wDrFbHD1sc67WsGbEWu4sBp3aeZ3Ki7kLPLEY7!1934427792' \
--data-raw '{
"name": "DemoDomain",
"identityProvider": "UserIdentityStore1",
"description": "Test Domain",
"tokenSettings": [
{
"tokenType": "ACCESS_TOKEN",
"tokenExpiry": 3600,
"lifeCycleEnabled": false,
"refreshTokenEnabled": false,
"refreshTokenExpiry": 86400,
"refreshTokenLifeCycleEnabled": false
},
{
"tokenType": "AUTHZ_CODE",
"tokenExpiry": 3600,
"lifeCycleEnabled": false,
"refreshTokenEnabled": false,
"refreshTokenExpiry": 86400,
"refreshTokenLifeCycleEnabled": false
},
{
"tokenType": "SSO_LINK_TOKEN",
"tokenExpiry": 3600,
"lifeCycleEnabled": false,
"refreshTokenEnabled": false,
"refreshTokenExpiry": 86400,
"refreshTokenLifeCycleEnabled": false
}
],
"errorPageURL": "/oam/pages/servererror.jsp",
"consentPageURL": "/oam/pages/consent.jsp",
"customAttrs": "{\"usePKCE\":\"ALL_CLIENTS_TYPES\"}"
}'
Enabling PKCE at Client Level
UsePKCE
parameter to one of the following values:
Values | Behavior and Desciption |
---|---|
STRICT |
If the PKCE parameters
|
NON_STRICT |
If the PKCE parameters
|
The following example shows a sample request to enable PKCE when
creating the client. To update an existing client with the PKCE parameters use the
PUT
method.
See Client REST Endpoints for the REST API documentation.
curl --request POST '<AdminServer>:<AdminPort>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/client' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic d2VibG9naWM6d2VibG9naWMx' \
--header 'Cookie: JSESSIONID=OweshB5ejqWvx6wDrFbHD1sc67WsGbEWu4sBp3aeZ3Ki7kLPLEY7!1934427792' \
--data-raw '{
"attributes": [
{
"attrName": "customeAttr1",
"attrValue": "CustomValue",
"attrType": "static"
}
],
"secret": "<client_secret>",
"id": "DemoClientId",
"scopes": [
"DemoResServer.scope1"
],
"clientType": "PUBLIC_CLIENT",
"idDomain": "DemoDomain",
"description": "Client Description",
"name": "DemoClient",
"grantTypes": [
"PASSWORD",
"CLIENT_CREDENTIALS",
"JWT_BEARER",
"REFRESH_TOKEN",
"AUTHORIZATION_CODE"
],
"defaultScope": "DemoResServer.scope1",
"usePKCE": "NON_STRICT",
"redirectURIs": [
{
"url": "http://localhost:8080/Sample.jsp",
"isHttps": true
}
]
}'
35.10.2 PKCE Flow for Access Token Generation
This section provides the PKCE flow details for Access Token generation.
- Create or update your Identity Domain by adding
UsePKCE
incustomAttrs
. For details, see Enabling PKCE at Domain Level - If the resource server already exists, skip this step. If not, add a resource server as described in the section Creating a Resource.
- Create or update the OAuth Client by adding the
UsePKCE
parameter. For details, see Enabling PKCE at Client Level - If the OAuth 3-legged flow is already setup, skip this step. If not, perform the manual side steps on OAM server and WebGate as described in the section 3 - Legged Flows — process under Runtime REST APIs for OAuth 12c
- Generate a cryptographically random key called
code_verifier
.code_verifier
refers to a cryptographically random URL safe string generated using the characters A-Z, a-z, 0-9, and the punctuation characters -._~ (hyphen, period, underscore, and tilde). The string must be between 43 and 128 characters long.Note:
A uniquecode_verifier
must be created for each authorization request.For example,
Y1lgBSx8gRsruplrdpGiG-9Lkv~kna1q2pgwXY7UYKc~~jTgMkmUlZkZkapJGT6X.m12.ZUBDj24qWuPGHl21x3vyFEC.m_XDH_JTw4Qk6_a62Qw~e0sVp3I-AHYhTzn
This
code_verifier
will be used to request the Access Token later. - Generate
code_challenge
string from thecode_verifier
.code_challenge
refers to the transformed BASE64-URL-encoded string of the SHA256 hash of thecode_verifier
.For example, for code_verifier:
Y1lgBSx8gRsruplrdpGiG-9Lkv~kna1q2pgwXY7UYKc~~jTgMkmUlZkZkapJGT6X.m12.ZUBDj24qWuPGHl21x3vyFEC.m_XDH_JTw4Qk6_a62Qw~e0sVp3I-AHYhTzn
, the transformed SHA256 hashed string, code_challenge, isEc-YfJRRibqf_myiWqObZfT-M1HthBUTygBH73zEHbc
. - Through the browser, request the Authorization Code. Send the
code_challenge
along withcode_challenge_method
in theauthorization_code
request to the authorization server (OAM).code_challenge_method
value can be one of the following:Plain
: Sets thecode_verifier
ascode_challenge
instead of the hashed value.S256
(Recommended): Indicates the hashed value of thecode_verifier
is set ascode_challenge
.
Note:
A unique Authorization Code can be exchanged for a single Access Token only. Authorization Code replay is rejected by OAM server.Authorization Code Sample Request
http://<OHS Hostname>:<OHS Port>/oauth2/rest/authz?response_type=code &client_id=TestClient&domain=TestDomain&scope=TestResourceServer.scope1&state=xyz &redirect_uri=http://localhost:8080/Sample.jsp &code_challenge=Ec-YfJRRibqf_myiWqObZfT-M1HthBUTygBH73zEHbc &code_challenge_method=S256
Authorization Code Sample Response
http://localhost:8080/Sample.jsp?code=UlF6aVY3eFVIemNTVWhVcWlmM0o1UT09fkJ5b0J4MlRVdFhwVFYySXhKR1RUS1NnOWV4UE1oUGRKMFYxR3RmbGt FYjJYK3lMUUxDRGxyZXNHa2VrRXRtQVp1S25MYVY1YXVkbFFGNmx5MUtCcXFZYWJhRlhpRENIcjI0Vm1YZjNtRE1hTzFDL1lmbEhKK0wvK2pBeUdTZWNYbEMza2dBSnM0Q0ZrZ1R NNmQ3SUVuSmZJNExScEI4ZUJySVpMT1hEZ1p5alp5eHVxSkd2RllCdVFqcFpEQTJEaCt5Z1JxN21ZWFQyc3JKQi9EY0JrTDhiUVBlb0laNkFzdVhJL1JURjBpWFVvK2VPelVxaVo zSjBMMjJncmZlcEhxMzh1N0hkZ0pqaEZZZmgyRWJHakkxMnlBeE9nVlRxRXdxcXhaazdCdW5mQ3VORFkvVHBLUXRvNEJpUzlEby9vcXlXaEJnZ08vMjExbE5NSFhHUVJFTHkrTlp 4aGNWUzBVMFd2cFVJcWpUd3ZHVjBEZmlaOVBQbWI5b3FhT3gvUFpXdVdrYjczRDJBeUw4RVJjdjMyQ2NnTEZRMXV0aDE2enVOYm9aYVNVb1pjOTJsRGliTGJxRWYrOTZtbXlVNll SNkxRWEVqd2ovTVBpaHc2TzRrbFZXMysrM2kyaGxuYmhoNFdOeENSL1NvLysrTDBXQktUQVhrb2Y0NzF6WTY1VXhIcFg0bG56REoxcURjTFFlSnNMUUE1aVNtMWtocDlzYW1CRFd 0YWRpcEhsT1JzK0hydDk4K0pFb0ZaSDYwaWJ1QlZMZGc0dzJ2ekh2ZWpLWU1ldnBIUWdjRVlBeDVVaENmOVg4dloyb0hhV0J6ekMyMExCQTdTdnFudyt1ZVV6Nkp3cWZON1N6VGJ0 UnA3UGk2U1JablVBK0k1bTduR1haOWwzVklQeHRKWWIwNHVObXY5NkFxN2tUMEMwb0djb2FlK1c0NGFTekFvKzd1bFdFbnFuZz09&state=xyz
- Request the access token from the authorization server (OAM) using
the
authorization_code
and thecode_verifier
.Access Token Sample Request
curl --request POST 'http://<ManagedServerHost>:<ManagedServerPort>/oauth2/rest/token' \ --header 'X-OAUTH-IDENTITY-DOMAIN-NAME: DemoDomain' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --header 'Cookie: JSESSIONID=OweshB5ejqWvx6wDrFbHD1sc67WsGbEWu4sBp3aeZ3Ki7kLPLEY7!1934427792' \ --data-urlencode 'grant_type=AUTHORIZATION_CODE' \ --data-urlencode 'code=UlF6aVY3eFVIemNTVWhVcWlmM0o1UT09fkJ5b0J4MlRVdFhwVFYySXhKR1RUS1NnOWV4UE1oUGRKMFYxR3RmbGt FYjJYK3lMUUxDRGxyZXNHa2VrRXRtQVp1S25MYVY1YXVkbFFGNmx5MUtCcXFZYWJhRlhpRENIcjI0Vm1YZjNtRE1hTzFDL1lmbEhKK0wvK2pBe UdTZWNYbEMza2dBSnM0Q0ZrZ1RNNmQ3SUVuSmZJNExScEI4ZUJySVpMT1hEZ1p5alp5eHVxSkd2RllCdVFqcFpEQTJEaCt5Z1JxN21ZWFQyc3J KQi9EY0JrTDhiUVBlb0laNkFzdVhJL1JURjBpWFVvK2VPelVxaVozSjBMMjJncmZlcEhxMzh1N0hkZ0pqaEZZZmgyRWJHakkxMnlBeE9nVlRxR XdxcXhaazdCdW5mQ3VORFkvVHBLUXRvNEJpUzlEby9vcXlXaEJnZ08vMjExbE5NSFhHUVJFTHkrTlp4aGNWUzBVMFd2cFVJcWpUd3ZHVjBEZml aOVBQbWI5b3FhT3gvUFpXdVdrYjczRDJBeUw4RVJjdjMyQ2NnTEZRMXV0aDE2enVOYm9aYVNVb1pjOTJsRGliTGJxRWYrOTZtbXlVNllSNkxRW EVqd2ovTVBpaHc2TzRrbFZXMysrM2kyaGxuYmhoNFdOeENSL1NvLysrTDBXQktUQVhrb2Y0NzF6WTY1VXhIcFg0bG56REoxcURjTFFlSnNMUUE1 aVNtMWtocDlzYW1CRFd0YWRpcEhsT1JzK0hydDk4K0pFb0ZaSDYwaWJ1QlZMZGc0dzJ2ekh2ZWpLWU1ldnBIUWdjRVlBeDVVaENmOVg4dloyb0h hV0J6ekMyMExCQTdTdnFudyt1ZVV6Nkp3cWZON1N6VGJ0UnA3UGk2U1JablVBK0k1bTduR1haOWwzVklQeHRKWWIwNHVObXY5NkFxN2tUMEMwb0 djb2FlK1c0NGFTekFvKzd1bFdFbnFuZz09' \ --data-urlencode 'redirect_uri=http://localhost:8080/Sample.jsp' \ --data-urlencode 'code_verifier=Y1lgBSx8gRsruplrdpGiG-9Lkv~kna1q2pgwXY7UYKc~~jTgMkmUlZkZkapJGT6X.m12.ZUBDj24qWuPGHl21x3vyFEC.m_XDH_JTw4Qk6_a62Qw~e0sVp3I-AHYhTzn' \ --data-urlencode 'client_id=DemoClientId'
Access Token Sample Response
{"access_token":"eyJraWQiOiJEZW1vRG9tYWluIiwieDV0IjoieGVmZExvZnpienRnTkJ2NGR3QXFnYkJyZGhvIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwOi8vc2xjMTZmc3UudXMub3JhY2 xlLmNvbToxNzI5OC9vYXV0aDIiLCJhdWQiOlsiRGVtb1Jlc1NlcnZlciIsImFiMCJdLCJleHAiOjE2MDQ5OTM0ODcsImp0aSI6InFPV0ZKYk1tdldmTW5IalA4Z0hVamciLCJpYXQiOjE2MDQ5ODk4ODcsInN1YiI6In dlYmxvZ2ljIiwiY3VzdG9tZUF0dHIxIjoiQ3VzdG9tVmFsdWUiLCJjb2RlX2NoYWxsZW5nZV9tZXRob2QiOiJTMjU2Iiwic2Vzc2lvbklkIjoiOTEyNTA2NWItZDJiNC00YWE1LTliNTctZjllZTU3NDUzZjQyfDJraS 9iWnRHYkYyT3FXOWhDRkJHcFpkcjJDTjZaTnJJWGszMFNURUV1N1k9IiwiY29kZV9jaGFsbGVuZ2UiOiJFYy1ZZkpSUmlicWZfbXlpV3FPYlpmVC1NMUh0aEJVVHlnQkg3M3pFSGJjPSIsInJlc1NydkF0dHIiOiJSRV NPVVJDRUNPTlNUIiwiY2xpZW50IjoiRGVtb0NsaWVudElkIiwic2NvcGUiOlsiRGVtb1Jlc1NlcnZlci5zY29wZTEiXSwiZG9tYWluIjoiRGVtb0RvbWFpbiJ9.cpR4L9UhIF4ZyPyelKgUeHzVQlIiqIN0vaqqPmC8a ed19JQFRzpI4xL8jlU4cFXFd9bwSX3_Y6s5Y16eMtSQ1DnOX-u-eoFYE4O6G8AitOAG2oWy82R1O5YJ693Aa7ovVf2VZ8Y1y-JG17HBK4TBXqUgOLhVgURtLsPCJ_Knjyut_TC44NbxsVfRAuOo2li-3vSeCrAi776bM 6TXLPo9VeYJvhGmVQyFA6Fe4QZ5qSLrU2r8Oi7p0plCjTQgEIt2EoHjH88-nfbZ35F4K3zha3UOh4l1gAtkq0HgkP2okwIcMNPk7t0p6kXMWNNm9tDAWCCOKN_Fhyv2_c7JqRZSrQ", "token_type":"Bearer","expires_in":3600}
Note:
OAM hashes thecode_verifier
and compares it with the previously receivedcode_challenge
. Only if these two values match, the access token is issued. - Validate the Access Token.
Validate Access Token Sample Request
curl --location --request GET 'http://<ManagedServerHost>:<ManagedServerPort>/oauth2/rest/token/info?access_token=<AccessToken> \ --header 'X-OAUTH-IDENTITY-DOMAIN-NAME: DemoDomain' \ --header 'Cookie: JSESSIONID=d4SxI2e58dgP6XbZepQo8uPRequ1cynWMjKtQyymVQhbi424TIOl!1934427792'