Authenticate Requests for Invoking Oracle Integration Flows

Integrations support multiple authentication methods suited to different applications and use cases. The adapters used as a trigger connection to stand up the endpoints/listener for a specific integration can support one or multiple authentication methods.

The following sections discuss the use cases, pros and cons, prerequisites, and instructions necessary for sending a request for each of the supported authentication methods.

Topics:

• About Requests to Invoke Integrations

• About OAuth 2.0 Grants

• Use OAuth 2.0 Grants in Identity Domain Environments

See OAuth Grant Types.

About Requests to Invoke Integrations

All integrations using this adapter as a trigger connection are protected by default using HTTP Basic Authentication and OAuth token-based authentication.

You currently can authenticate your requests to invoke integrations in either of the following ways:

• Using HTTP Basic Authentication by sending the credentials of the user (that is, created in your identity domain) through the HTTP authorization header
• Sending an OAuth access token in the header while invoking an Oracle Integration endpoint after acquiring the access token from your identity domain that serves as the OAuth authorization provider

You must have the ServiceUser role in your identity domain to invoke integrations.

Invoke Integration Endpoints Using HTTP Basic Authentication

This authentication method allows the credentials belonging to an Oracle Integration user to send the request to invoke an integration. You must create this user in your identity domain and ensure that the user was granted the role for invoking an integration.

The user can be:

• Human - representing a business user such as a sales representative, technician, or any other person for invoking an integration
• Nonhuman - representing a service integration account used by an external client application for invoking an integration

Even though it's easy to implement the authentication scheme, this is the least secure way to send a request to Oracle Integration for invoking an integration. Also, Oracle Integration doesn't recommend this authentication scheme.

In addition, the customer must ensure the credentials, when reset, are provided to the client application that invokes the integration to ensure a new set of credentials are being used from then on.

Assign appropriate users and groups of users to the various Oracle Integration roles. For standard/production configurations, use the ServiceUser role. See Oracle Integration Roles and Assign Oracle Integration Roles to Groups in Provisioning and Administering Oracle Integration 3.

Invoke Integration Endpoints Using OAuth Token-Based Authentication

This authentication scheme allows the external client to acquire a token that is also sent as part of the request sent to invoke an integration.

The most important step for an application in the OAuth flow is how the application receives an access token (and optionally a refresh token). A grant type is the mechanism used to retrieve the token. OAuth defines several different access grant types that represent different authorization mechanisms.

Applications can request an access token to access protected endpoints in different ways, depending on the type of grant type specified in the identity provider. A grant is a credential representing the resource owner's authorization to access a protected resource.

The following sections discuss the various grant types and their pros/cons, along with instructions on how to configure the specific grant type.

About OAuth 2.0 Grants

There are several OAuth 2.0 grant types you can use in Oracle Integration. Review the following information to identify the grant type to use for your use case.

Grant Type	About the Grant Type	Use Cases and Risks
JWT user assertion (recommended)	A user assertion is a user token that contains identity information about the user. The user can either represent a human or a service integration account created for identifying a specific calling application. The user assertion is used directly as an authorization grant to obtain an access token. The client details are provided either as an authentication header in the request or as a client assertion. The user assertion grant is more secure than the resource owner password credentials grant because the user’s credentials are never exposed. The user assertion workflow: Is used with confidential clients. The OAuth clients are trusted to assert a user/service integration account identity on behalf of the user/service integration account. The resource owner's credentials (Oracle Integration user) are never accessible to the client application. It just uses the assertion of the resource owner. It isn’t redirection-based. It takes a request only from the client application to the authorization server. The user is not redirected between interfaces to authorize the request. This user assertion grant works as follows: The client requests an access token by providing a user assertion. The client details are provided either as an authentication header in the request or as a client assertion. The OAuth service authenticates the client and, if valid, supplies an access token. The JWT user assertion characteristics are as follows: Does not require the client to have knowledge of user credentials. There is no browser-based end user interaction. A refresh token is allowed. An access token is in the context of the end user. In this OAuth flow: A user attempts to access a client application by sending a generated user assertion. The client application requests an access token, and often a refresh token, by providing a user assertion or a third-party user assertion. The identity domain authorization server returns the access token to the client application. The client application uses the access token in an API call to invoke the integration.	This grant is used by applications that want to programmatically invoke integrations without any user intervention. The client application impersonates the user by sending the user assertion to the identity domain while requesting token access. An access token is returned in the user context. The user can either represent a human or a service integration account created for identifying a specific calling application. Oracle Integration recommends the use of this grant for acquiring an OAuth access token by the applications that must programmatically start the integration without any user intervention. Risks Carefully use this grant (only with first party/trusted clients) because it allows for trivial impersonation to more highly privileged accounts on services. Usage See Prerequisites for JWT User Assertion.
Authorization code	The authorization code grant type is used by web and mobile applications. It differs from most of the other grant types by first requiring the application to launch a browser to begin the integration. At a high level, the integration consists of the following steps: The application opens a browser to send the user to the OAuth server. The user sees the authorization prompt and approves the application request. The user is redirected back to the application with authorization code in the query string. The application exchanges the authorization code for an access token. The authorization code has the following characteristics: Does not require the client to have knowledge of user credentials. Is a browser-based end user interaction. A refresh token is allowed. An access token is in the context of the end user. In this OAuth flow: A user clicks a link in a web server client application to request access to protected resources. The client application redirects the browser to the identity domain authorization endpoint with a request for an authorization code: oauth2/v1/authorize The identity domain authorization server returns an authorization code to the client application through a browser redirect after the resource owner gives consent. The client application subsequently exchanges the authorization code for an access token, and often a refresh token. The identity domain authorization server returns the access token to the client application. The client application uses the access token in an API call to invoke the integration.	This grant is used by the applications such as web portals and mobile applications involving user interactions that may end up invoking the integrations. In this type of use case, the user signing in to the web portal/mobile application explicitly provides the consent by authenticating against Oracle Integration to let their application start the integration. Usage See Prerequisites for Authorization Code.
Client credentials	The client uses its client credentials (or other supported means of authentication) to request an access token when requesting access to protected resources: Under its control Those of another resource owner that have been previously arranged with the authorization server Only confidential clients must use this grant type. In this OAuth flow: The client authenticates with the authorization server and requests an access token from the token endpoint. Because client authentication is used as the authorization grant, no additional authorization request is required. The authorization server authenticates the client and, if valid, issues an access token. If the request fails client authentication or is invalid, the authorization server returns an error response.	This grant is typically used by clients to obtain an access token outside of the context of a user (for example, to access resources about themselves rather than to access a user's resources). Usage See Prerequisites for Client Credentials and Resource Owner Password Credentials.
Resource owner password credential (ROPC) (not recommended)	The resource owner’s password credentials (that is, the user name and password) can be used by the OAuth client directly as an authorization grant to obtain an access token. The resource owner password credentials grant type is suitable for cases where the resource owner has a trust relationship with the OAuth client. When using the resource owner password credentials grant, the user provides the credentials (user name and password) directly to the application. The application then uses the credentials to obtain an access token from the OAuth token service. The resource owner password credentials grant is a grant workflow where the client application, together with its client identifier and secret, sends the user name and password in exchange for an access token. Instead of the user having to log in and approve the authorization request in a web interface, the user can enter the user name and password in the client application user interface directly. This workflow has different security properties than other OAuth workflows. The primary difference is that the user’s password is accessible to the application. This requires a strong trust of the application by the user. The resource owner password credentials grant has the following characteristics: The client is required to have knowledge of user credentials. Is not a browser-based end user interaction. A refresh token is allowed. An access token is in the context of the end user. In this OAuth flow: The user clicks a link in the client application requesting access to protected resources. The client application requests the resource owner's user name and password. The user logs in with their user name and password. The client application exchanges those credentials for an access token, and often a refresh token, from the identity domain authorization server. The identity domain authorization server returns the access token to the client application. The client application uses the access token in an API call to invoke the integration.	This grant can be used by applications that want to programmatically invoke the integration without any user intervention. Use this grant only with trusted first-party clients that securely handle user credentials. Even though this grant type can be used by client applications to acquire an OAuth access token to use for sending the request to invoke an integration in a programmatic manner, Oracle Integration does not recommend the resource owner password credential grant because of the following risks: Risks This grant type carries a higher risk than other grant types because it maintains the password anti-pattern this protocol seeks to avoid. The client can abuse the password or the password can unintentionally be disclosed to an attacker (for example, through log files or other records kept by the client). The application can request a scope with complete access to user resources once it possesses the password credential. Passwords expire. This grant is currently in a deprecated state. Usage See Prerequisites for Client Credentials and Resource Owner Password Credentials.

Use OAuth 2.0 Grants in Identity Domain Environments

To use an OAuth 2.0 grant type with this adapter in an identity domain environment of Oracle Integration, you must perform the following prerequisites.

• Access the Identity Domain
• Prerequisites for JWT User Assertion
• Prerequisites for Client Credentials and Resource Owner Password Credentials
• Prerequisites for Authorization Code

Access the Identity Domain

• Log in to the Oracle Cloud Infrastructure Console with your identity domain administrator credentials.
  1. In the navigation pane, click Identity & Security.
  2. Click Domains.
  3. Select your compartment.
  4. Select the identity domain.
  5. In the menu bar, click Integrated applications.

     This is the location at which you create the client application for your grant type.

     
     
     

Prerequisites for JWT User Assertion

• Generate the key
• Configure the client application
• Add a certificate as a trusted partner
• Generate the JWT user assertion
• Validate the client application

Generate the key

You must first generate the key to import when you configure the client application for the JWT user assertion.

1. Generate the self-signed key pair.

   keytool -genkey -keyalg RSA -alias <your_alias> -keystore <keystore_file> -storepass <password> -validity 365 -keysize 2048
    
   ##example
   keytool -genkey -keyalg RSA -alias assert -keystore sampleKeystore.jks -storepass samplePasswd -validity 365 -keysize 2048

2. Export the public key for signing the JWT assertion.

   keytool -exportcert -alias <your_alias> -file <filename> -keystore <keystore_file> -storepass <password>
    
   ##example
   keytool -exportcert -alias assert -file assert.cer -keystore sampleKeystore.jks -storepass samplePasswd
    
   ## This should show a success message e.g. Certificate stored in file <assert.cer>

3. Convert the keystore to P12 format.

   keytool -importkeystore -srckeystore <filename> -srcstorepass <password> -srckeypass <password> -srcalias <your_alias> -destalias <your_alias> -destkeystore <destFileName> -deststoretype PKCS12 -deststorepass <password> -destkeypass <password>
    
   ##example
   keytool -importkeystore -srckeystore sampleKeystore.jks -srcstorepass samplePasswd -srckeypass samplePasswd -srcalias assert -destalias assert -destkeystore assert.p12 -deststoretype PKCS12 -deststorepass samplePasswd -destkeypass samplePasswd
    
   ## This should show a success message e.g. Importing keystore sampleKeystore.jks to assert.p12...

4. Export the private key from the P12 keystore.

   openssl pkcs12 -in <destFileName> -nodes -nocerts -out <pem_file>
    
   ##example
   openssl pkcs12 -in assert.p12 -nodes -nocerts -out private_key.pem
    
   ## This should show a success message: MAC verified OK

Configure the client application

To trigger the integration with OAuth, a client application is required.

1. Click Add application.
2. Select Confidential Application, then click Launch workflow.
3. Enter a name. The remaining fields on this page are optional and can be ignored.
4. Click Submit.
5. Click the OAuth configuration tab, then the Edit OAuth configuration subtab.
6. In the Client configuration panel, select Configure this application as a client now.
7. For JWT user assertions, select JWT assertion and Refresh token in the Allowed grant types section.

   
   
   

8. Complete the following steps for the grant type:
   1. Leave the Redirect URL, Post-logout redirect URL, and Logout URL fields blank.
   2. In the Client type section, select Trusted for the client to generate self-signed user assertions and import your signing certificate.
   3. In the Certificate section, import the certificate created in section Generate the key. This action adds the certificate as a trusted partner.
   4. Bypass several fields and scroll down to the Token issuance policy section.
   5. Select Confidential in the Authorized resources section.
   6. Click the Add Resources toggle.
   7. Click Add scope.
   8. Find and expand the Oracle Integration application for your instance.
   9. Select the two scopes appended with the following details:
      • urn:opc:resource:consumer::all
      • ic/api/

      
      
      

   10. Click Add.

       The scopes are displayed in the Resources section.

   11. Ignore the Add app roles check box. This selection is not required.
   12. Click Submit.

       The details page for the client application is displayed.

   13. Click Activate, and then Activate application to activate the client application for use.
   14. In the General Information section, note the client ID and client secret values. These values are required for the third-party application that is communicating with the identity domain.

       
       
       

9. In the menu bar, click Oracle cloud services.

   
   
   

10. Click the specific application corresponding to the Oracle Integration instance.
11. In the navigation pane, click Application roles.
12. Expand ServiceInvoker, then click Actions next to Assigned applications.

    
    
    

13. Select ServiceInvoker, then click Manage users or Manage groups.
14. Based on your selection, click Assign users or Assign groups to select the users or groups, then click Assign.

Add a certificate as a trusted partner

In addition to importing the signing certificate into the client application, you are also required to include the certificate as a trusted partner certificate.

1. In the menu bar, click Security.

   
   
   

2. Scroll down to the Trusted partner certificates section.
3. Click Import certificate to upload the certificate created in section Generate the key.

Generate the JWT user assertion

1. Generate the JWT user assertion using the generated private key and simple Java code.

   Note:

   You can use the https://github.com/jwtk/jjwt library to generate the user assertion. There are many libraries listed at https://jwt.io/ for multiple technologies.

   Sample:
   header:
   {
   "alg": "RS256",
   "typ": "JWT",
   "kid": "assert"
   }
    
   payload:
   {
   "sub": "ssaInstanceAdmin",
   "jti": "8c7df446-bfae-40be-be09-0ab55c655436",
   "iat": 1589889699,
   "exp": 1589909699,
   "iss": "d702f5b31ee645ecbc49d05983aaee54",
   "aud": "https://identity.oraclecloud.com/"
   }

   Where:

   • sub specifies the user name for whom user assertion is generated.
   • jti is a unique identifier
   • iat is issued (epoch seconds).
   • exp is the token expiry (epoch seconds).
   • iss is the client ID.
   • aud must include the identity domain audience https://identity.oracle.com/. The signing algorithm must be RS256.
   • kid specifies the key to use to verify the signature. Therefore, it must match with the uploaded certificate alias.

Validate the client application

1. Once you generate the JWT user assertion, generate the access token as follows.

   ##Syntax
   curl -i -H 'Authorization: Basic <base64Encoded clientid:secret>' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<Identity_Domain_Service_Instance>.identity.oraclecloud.com/oauth2/v1/token -d 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=<user assertion>&scope=<app_scope>'
     
   ###where
   #### grant type - urn:ietf:params:oauth:grant-type:jwt-bearer
   #### <base64-clientid-secret> - Base 64 encode clientId:ClientSecret
   #### <user assertion> - User assertion generated
   #### <app scope> - Scope added while creating application in client configuration section (Ends with urn:opc:resource:consumer::all)

2. Capture the access_token from the response.

   {
       "access_token": "eyJ4NXQjG...dfsdfsFgets2ed",
       "token_type": "Bearer",
       "expires_in": 3600
   }

3. Use an access_token in the authorization header to invoke the Oracle Integration trigger endpoint.

   curl --location --request GET 'https://OIC host/OIC endpoint' \
   --header 'Authorization: Bearer eyJ4NXQjG...dfsdfsFgets2ed'

Prerequisites for Client Credentials and Resource Owner Password Credentials

To trigger the integration with OAuth, a client application is required. The prerequisites for the client credentials and resource owner password credentials grant types are very similar.

• Configure the client application
• Add roles to the client application

Configure the client application

1. Click Add application.
2. Select Confidential Application, then click Launch workflow.
3. Enter a name. The remaining fields on this page are optional and can be ignored.
4. Click Submit.
5. Click the OAuth configuration tab, then the Edit OAuth configuration subtab.
6. In the Client configuration panel, select Configure this application as a client now.
7. Select the grant type to use:
   1. For client credentials, select Client credentials in the Allowed grant types section.

      
      
      

   2. For resource owner password credentials, select Resource owner and Refresh token in the Allowed grant types section.

      
      
      

8. Complete the following steps for either grant type:
   1. Leave the Redirect URL, Post-logout redirect URL, and Logout URL fields blank.
   2. For Client type, ensure that Confidential is selected.
   3. Bypass several fields and scroll down to the Token issuance policy section.
   4. Select Confidential in the Authorized resources section.
   5. Click the Add Resources toggle.
   6. Click Add scope.
   7. Find and expand the Oracle Integration application for your instance.
   8. Select the two scopes appended with the following details:
      • urn:opc:resource:consumer::all
      • ic/api/

      
      
      

   9. Click Add.

      The scopes are displayed in the Resources section.

   10. Ignore the Add app roles check box. This selection is not required.
   11. Click Submit.

   The details page for the client application is displayed.

9. From the Actions menu at the top, select Activate, and then Activate application to activate the client application for use.
10. In the General Information section, note the client ID and client secret values. These values are required for the third-party application that is communicating with the identity domain.

    
    
    

Add roles to the client application

1. In the menu bar, click Oracle cloud services.

   
   
   

2. Click the specific application corresponding to the Oracle Integration instance.
3. In the menu bar, click Application roles.
4. If configuring the client credentials grant type, select the following:
   1. Expand ServiceInvoker, then click Actions next to Assigned applications.

      
      
      

   2. Select to assign users, groups, and applications to the instance application.
5. If configuring the resource owner password credentials grant type, select the following:
   1. Select ServiceInvoker, then click Manage users or Manage groups.
   2. Based on your selection, click Assign users or Assign groups to assign users or groups to the instance application, then click Assign.
6. Validate the client application for the grant type you are using.
   1. For the client credentials grant type:
      1. Fetch the access client to make an access token request with the client credentials.

         ##Syntax
         curl -i -H 'Authorization: Basic <base64Encoded clientid:secret>' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<Identity_Domain_Service_Instance>.identity.oraclecloud.com/oauth2/v1/token -d 'grant_type=client_credentials&scope=<app scope>'
         ###where
         #### <base64-clientid-secret> - Base 64 encode clientId:ClientSecret
         #### <app scope> - Scope added while creating application in client configuration section (Ends with urn:opc:resource:consumer::all)
          
         ##Example
         curl -i -H 'Authorization: Basic OGQyM...ZDA0Mjcz' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<identity_domain_host>/oauth2/v1/token -d 'grant_type=client_credentials&scope=https://<Resource APP Audience>urn:opc:resource:consumer::all'

         Where Identity_Domain_Service_Instance is the value in the Domain URL field of the Details tab of the instance application.

         
         
         

      2. Capture the access_token from the response.

         {
             "access_token": "eyJ4NXQjG...dfsdfsFgets2ed",
             "token_type": "Bearer",
             "expires_in": 3600
         }

      3. Use the access_token in the authorization header to invoke the trigger endpoint.

         curl --location --request GET 'https://OIC host/OIC endpoint' \
         --header 'Authorization: Bearer eyJ4NXQjG...dfsdfsFgets2ed'

   2. For the resource owner password credentials grant type:
      1. To fetch the access client, make a request with the user name and password in the payload.

         ##Syntax
         curl -i -H 'Authorization: Basic <base64Encoded_clientid:secret>' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<Identity_Domain_Service_Instance>.identity.oraclecloud.com/oauth2/v1/token -d 'grant_type=password&username=<user-name>&password=<password>&scope=<App_Scope>%20offline_access'
          
         ###where
         #### <base64-clientid-secret> - Base 64 encode clientId:ClientSecret
         #### <username> - user for token needs to be issued (must be in serviceinvoker role).
         #### <password> - password for above user
         #### <app_scope> - Scope added while creating application in client configuration section (Ends with urn:opc:resource:consumer::all)
         ##Example
         curl -i -H 'Authorization: Basic OGQyM...ZDA0Mjcz' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<identity_domain_host>/oauth2/v1/token -d 'grant_type=password&username=sampleUser&password=SamplePassword&scope=https://<Resource_APP_Audience>urn:opc:resource:consumer::all%20offline_access'

      2. Capture the access_token and refresh_token from the response.

         {
             "access_token": "eyJ4NXQjG...dfsdfsFgets2ed",
             "token_type": "Bearer",
             "expires_in": 3600,
             "refresh_token": "AQAgY2MzNjVlOTVhOTRh...vM5S0MkrFSpzc="
         }

      3. Use the access_token in the authorization header to invoke the Oracle Integration trigger endpoint.

         curl --location --request GET 'https://OIC host/OIC endpoint' \
         --header 'Authorization: Bearer eyJ4NXQjG...dfsdfsFgets2ed'

      4. To update the access token, use the refresh token and make a request.
      5. Capture the access_token and refresh_token from the response for further use.

         curl -i -H 'Authorization: Basic <base64-clientid-secret>' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<Identity_Domain_Service_Instance>.identity.oraclecloud.com/oauth2/v1/token  -d 'grant_type=refresh_token&refresh_token=<refresh_token>'
          
         ##Example
         curl -i -H 'Authorization: Basic OGQyM...ZDA0Mjcz' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<Identity_Domain_Service_Instance>.identity.oraclecloud.com/oauth2/v1/token  -d 'grant_type=refresh_token&refresh_token=AQAgY2MzNjVlOTVhOTRh...vM5S0MkrFSpzc='

Prerequisites for Authorization Code

• Configure the client application
• Validate the Oracle Integration application and user roles
• Validate the client application

Configure the client application

To trigger the integration with OAuth, a client application is required.

1. Click Add application.
2. Select Confidential Application. then click Launch workflow.
3. Enter a name. The remaining fields on this page are optional and can be ignored.
4. Click Submit.
5. In the Client configuration box, select Configure this application as a client now.
6. Select the grant type to use:
   1. For authorization code, select Refresh token and Authorization code in the Allowed grant types section.

      
      
      

   2. In the Redirect URL field, enter the redirect URL of the client application. After user login, this URL is redirected to with the authorization code. You can specify multiple redirect URLs. This is useful for development environments in which you have multiple instances, but only one client application due to licensing issues.

      Note:

      If you don't know the following information, check with your administrator:

      • If your instance is new or upgraded from Oracle Integration Generation 2 to Oracle Integration 3.
      • The complete instance URL with the region included (required for new instances).

      For Connections…	Include the Region as Part of the Redirect URL?	Example of Redirect URL to Specify…
      Created on new Oracle Integration 3 instances	Yes.	https://OIC_instance_URL.region.ocp.oraclecloud.com/icsapis/agent/oauth/callback
      Created on instances upgraded from Oracle Integration Generation 2 to Oracle Integration 3	No. This applies to both: New connections created after the upgrade Existing connections that were part of the upgrade	https://OIC_instance_URL.ocp.oraclecloud.com/icsapis/agent/oauth/callback

   3. In the Client type section, click Confidential.
   4. Bypass several fields and scroll down to the Token issuance policy section.
   5. Select Confidential in the Authorized resources section.
   6. Click the Add Resources check box.
   7. Click Add scope.
   8. Find and expand the Oracle Integration application for your instance.
   9. Select the two scopes appended with the following details:
      • urn:opc:resource:consumer::all
      • ic/api/

      
      
      

   10. Click Add.

       The scopes are displayed in the Resources section.

   11. Ignore the Add app roles check box. This selection is not required.
   12. Click Submit.

       The details page for the client application is displayed.

   13. Click Activate, and then Activate application to activate the client application for use.
   14. In the General Information section, note the client ID and client secret values. These values are required for the third-party application that is communicating with the identity domain.

       
       
       

Validate the Oracle Integration application and user roles

1. In the menu bar, click Oracle cloud services.

   
   
   

2. Click the specific application corresponding to the Oracle Integration instance.
3. In the navigation pane, click Application roles.
4. Expand ServiceInvoker, then click Actions next to Assigned applications.

   
   
   

5. Select to manage users, groups, and applications for the instance application.
6. Based on your selection, click Assign users or Assign groups to select the users or groups, then click Assign.

Validate the client application

1. To fetch the authorization code, make the following request from the browser.

   ##Syntax
   GET https://<Identity_Domain_Service_Instance>.identity.oraclecloud.com/oauth2/v1/authorize?client_id=<client-id>&response_type=code&redirect_uri=<client-redirect-uri>&scope=<app_scope>%20offline_access&nonce=<nonce-value>&state=<unique_value>
    
   ###where
   #### <client-id> - ID of Client application generated.
   #### <client-redirect-uri> - Redirect URI, in client application.
   #### <app_scope> - scope added while creating application in client configuration. (Ends with urn:opc:resource:consumer::all)
   #### nonce - Optional, unique value to mitigate replay attacks
   #### state - Recommended, Opaque to IDCS. Value used to maintain state between the request and the callback
   ##Example
   GET https://<identity_domain_host>/oauth2/v1/authorize?client_id=<clientID>&response_type=code&redirect_uri=https://app.getpostman.com/oauth2/callback&scope=https://<Resource_APP_Audience>urn:opc:resource:consumer::all%20offline_access&nonce=121&state=12345544

2. If the user is not already logged in, you are challenged to authenticate your user credentials. (For authentication, the user assigned the ServiceInvoker role must be used.)
   After authentication is successful, the client URL is redirected to with the authorization code and state added to the URL.

   ##Response URL
   https://<redirect_URL>?code=<code_value>=&state=<state_value>
    
   ###Client should validate state received is same as one sent in request.

3. Capture the code value from the above response and make the following request to get the access token.

   ##Syntax
   curl -i -H 'Authorization: Basic <base64-clientid-secret>' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<Identity_Domain_Service_Instance>.identity.oraclecloud.com/oauth2/v1/token -d 'grant_type=authorization_code&code=<authz-code>&redirect_uri=<client-redirect-uri>
    
   ###where
   #### <base64-clientid-secret> - BAse 64 encode clientId:ClientSecret
   #### <authz-code> - code value received as response on redirect.
   #### <client-redirect-uri> - Redirect URI, in client application.
    
   ##Example
   curl -i -H 'Authorization: Basic MDMx..NGY1' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<identity_domain_host>/oauth2/v1/token -d 'grant_type=authorization_code&code=AQAg...3jKM4Gc=&redirect_uri=https://app.getpostman.com/oauth2/callback

4. Capture the access_token and refresh_token from the response.

   {
       "access_token": "eyJ4NXQjG...dfsdfsFgets2ed",
       "token_type": "Bearer",
       "expires_in": 3600,
       "refresh_token": "AQAgY2MzNjVlOTVhOTRh...vM5S0MkrFSpzc="
   }

5. Use the access_token in the authorization header to invoke the Oracle Integration trigger endpoint.

   curl --location --request GET 'https://OIC host/OIC endpoint' \
   --header 'Authorization: Bearer eyJ4NXQjG...dfsdfsFgets2ed'

6. To update the access token, use the refresh token and make the request.
7. Capture the access_token and refresh_token from a response for further use.

   curl -i -H 'Authorization: Basic <base64-clientid-secret>' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<Identity_Domain_Service_Instance>.identity.oraclecloud.com/oauth2/v1/token  -d 'grant_type=refresh_token&refresh_token=<refresh_token>'
    
    
   ##Example
   curl -i -H 'Authorization: Basic OGQyM...ZDA0Mjcz' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST https://<Identity_Domain_Service_Instance>.identity.oraclecloud.com/oauth2/v1/token  -d 'grant_type=refresh_token&refresh_token=AQAgY2MzNjVlOTVhOTRh...vM5S0MkrFSpzc='