Propagate OAuth User Identity Between Services

Oracle Integration provides support for OAuth identity propagation when invoking REST API operations. OAuth identity propagation enables you to securely transfer the same user identity and access credentials across services. The services involved may use the same identity domain within Oracle Integration, a different identity domain outside Oracle Integration, or a third-party identity provider.

How Identity Propagation in Oracle Integration Works

It is a common business requirement to propagate the identity of a user between multiple services. For example:
  • You log in to a VBCS application and call Oracle Integration, which is using the identity domain in its tenancy.
  • Oracle Integration then invokes an Oracle Fusion Applications endpoint, which is using a separate identity domain in a different tenancy. The Oracle Fusion Applications endpoint must know the end user making the call to drive its business logic.
  • Oracle Integration also invokes a Salesforce endpoint, using a third-party identity provider outside of Oracle. The Salesforce endpoint must also know the end user making the call to drive its business logic.
Identity propagation works as follows for these types of scenarios:
  • User Authentication - A user authenticates with an identity provider using their credentials.
  • Token Issuance - Upon successful authentication, the identity provider issues a JWT access token containing the user's identity information and authorized scopes.
  • Token propagation - When the user accesses a different service, the JWT access token is propagated with the request.
  • Token validation - Each service receiving the request validates the JWT access token by verifying its integrity, expiration, and issuer.
  • Getting the identity - After a successful token validation, the service extracts the user's identity from the JWT access token's claims.
  • Access Controls - Based on the identity, appropriate access controls are applied to determine the user's access to resources.

Oracle Integration provides support for OAuth identity propagation with the OAuth using the JWT User Assertion security policy. This security policy is available if you need to use the following adapters as invoke connections to call REST API operations.

  • REST Adapter
  • Oracle ERP Cloud Adapter
  • Oracle HCM Cloud Adapter
  • Oracle CX Sales and B2B Service Adapter

No identity propagation configuration tasks are required on the Connections page or in the Adapter Endpoint Configuration Wizard for these adapters. Instead, you configure the user identity to propagate in the mapper with the Subject element under Security Properties.

Note:

  • To use identity propagation with an invoke connection created prior to Release 25.04, open the adapter in the Adapter Endpoint Configuration Wizard, click through each page, and click Save. These actions create the necessary Subject source and target elements in the mapper.
  • Identity propagation is an optional feature. If you do not want to use identity propagation with the OAuth using JWT User Assertion security policy, leave the Subject elements empty.

Propagate User Identity

This section provides an overview of propagating user identity.

  1. Create a trigger connection (for example, with the REST Adapter).
  2. Create a new invoke connection with the REST Adapter.
  3. Configure the invoke connection to use the OAuth using JWT User Assertion security policy, uploading the necessary header and payload files, specifying the private key alias uploaded on the Certificates page, and specifying the scopes under Optional security.


    The Security section includes fields for Security policy, Access Token URI, JWT headers in json format, JWT payload in json format, and JWT Private Key Alias. Below this is the Optional security section that can be expanded.

  4. Create an application integration.
  5. Drag the trigger and invoke connections into the integration canvas for configuration with the Adapter Endpoint Configuration Wizard.
  6. Open the mapper.


    The integration shows a trigger connection, mapper, and invoke action.

  7. Set the user that has permission to execute the integration through either of two options in the mapper:
    • Expand Security Properties in the Sources and Target areas and map the user in the source Subject element to the target Subject element.


      The Sources, Mapping canvas, and Target sections are shown. The Sources Security Properties node and Target Security Properties node have been expanded. A Subject element in the Sources section is mapped to a Subject element in the Target section.

    • Expand Security Properties in the Target area and manually set the user for the Subject element in the Expression Builder. For this example, this option is demonstrated. The user name is specified in the Expression Builder as "l1serviceadmin".


      The Sources, Mapping canvas, and Target sections are shown. The Subject target element is shown with a value of l1serviceadmin in the Expression Builder at the bottom of the page.

  8. Complete design of your integration.
  9. Activate and run the integration as the l1serviceadmin user specified in the mapper.

    The activity stream indicates the run was successful.

    If you run the integration with a different user than that configured in the Subject element of the mapper, you receive the following error:
    Request to access token failed. Cause: status = 400 Error: 
{\"error\":\"invalid_grant\",\"error_description\":\"Invalid user assertion: 
The user name that you entered is invalid. Contact your system administrator.\"

    When you map the subject from trigger to invoke, the identity of the user who invokes the flow overrides the user configured in the JSON file. For example, at runtime, user1, user2, and user3 can run the integration flow and they'll all get tokens for each specific user. The JWT payload JSON file remains unchanged.