Introduction

With the evolution of OCI IAM Domains and the growing adoption of Oracle Integration Cloud (OIC Gen3), integrating with Oracle Fusion Applications (FA) now offers a flexible and secure foundation for enterprise integrations including cross-domain scenarios.

Oracle provides multiple OAuth-based patterns that enable versatile integration models across identity domains. However, implementing these patterns consistently requires a clear understanding of:

• Cross-domain identity handling
• OAuth trust configuration
• Certificate management
• Resource application setup
• Token validation and authorization behavior (401 vs 403)

Without this clarity, teams often introduce unnecessary complexity, configuring trust models or components that may not be required for their specific use case.

This blog provides a practical, end-to-end guide to implementing OAuth 2.0 for secure communication between OIC and Fusion Applications across IAM domains. It focuses on Authorization Code (user-based) and Client Credentials (service-based) flows and demonstrates how to apply them consistently for both REST and SOAP integrations.

Objective

When OIC and Fusion reside in different IAM domains, the following challenges arise:

1. Token Trust Issues
   • Fusion only trusts tokens issued by known identity providers
   • External IAM tokens are rejected unless explicitly trusted – Requires issuer + certificate configuration
2. Identity Resolution Problems
   • Valid token ≠ Authorized request
   • Fusion validates token first, then resolves user locally, then applies RBAC – If user does not exist → request fails
3. Overuse of Complex Patterns
   • Creating unnecessary resource applications
   • Uploading certificates when not required
   • Using external IAM when Fusion IAM is sufficient

The objective of this blog is to:

• Explain how OAuth 2.0 works across different IAM domains in Oracle Cloud
• Provide a clear implementation pattern for OIC to Fusion integrations using Authorization Code and Client Credentials flows can be used effectively
• Minimizes unnecessary complexity
• Ensures secure and working integrations
• Differentiates between-
  • When trust is required
  • When it can be avoided

Architecture Overview

There are two primary patterns for OIC → Fusion integration.

• Approach 1 — Fusion IAM Native (Recommended)
  • OIC → Fusion IAM → OAuth Token → Fusion APIs
  • Token issuer = Fusion IAM → No trust required
  • Characteristics
    • Simplest setup
    • No certificate upload
    • No trust configuration
    • Uses pre-integrated Fusion resource Works for both:
      • Authorization Code
      • Client Credentials

• Approach 2 — External IAM (Cross-Domain Trust)
  • OIC → External IAM → OAuth Token → Fusion (via trust)
  • Token issuer ≠ Fusion IAM → Trust must be established
    • Characteristics
      • Requires OAuth trust setup
      • Requires certificate upload
      • Requires resource application
      • Supports enterprise identity models – User authenticating in external IAM must exist in Fusion with the same username, otherwise Fusion will reject the request during authorization phase.

Fusion validates requests in two stages: token validation (OAuth) and authorization (user/service identity and roles), Authentication validates the token, while authorization determines whether the identity has access.

---

Implementation Details

---

Approach 1 – Using Fusion IAM Domain (Recommended)

When to Use

• OIC can use Fusion IAM for authentication
• No enterprise requirement for centralized external identity
• Simpler architecture preferred

Using OAuth 2.0 Authorization Code Flow

Best suited for user-context operations where actions must run on behalf of a Fusion Applications user.

Steps –

Step 1: Create Confidential Application in Fusion IAM

1. Login to IAM in same domain which is domain of FA
2. Navigate to Identity > Domain> Choose FA Domain
3. Go to Integrated Application, Press Button – Add Application
4. Choose Confidential Application.
   • Configure this application as a client now
5. Select Client Configuration
   • Authorization Code
   • Refresh Token
6. Add the Redirect URI for OIC Gen3:
   • https://<oic_instance>/icsapis/agent/oauth/callback
   • https://<oic_instance>/ic/pub/oauth2callback
7. Add Resource >> Add Scope
8. Oracle Applications Cloud (Fusion)
9. Press Next for Configure Policy
10. Finish
11. Activate Application.
12. Make note of the application’s Client ID and Client Secret & Scope.

Step 2: Configure Connection in OIC Gen3

1. Create a new REST/SOAP Connection.
2. Enter WSDL URL Information ending with ?wsdl in case of SOAP
3. Enter REST API Base URLin case of REST.
4. Choose OAuth 2.0 Authorization Code as the security policy.
5. Enter:
   • Client ID & Client Secret (from IAM app).
   • Authorization Code URI (FA IAM/oauth2/v1/authorize).
   • Access Token URI (FA IAM/oauth2/v1/token).
6. Optional Security
   • Scope (Defined from IAM app – Resource/Scope)
   • To obtain a refresh token (required for Authorization Code flow so OIC can automatically refresh the token), add the scope – offline_access in addition to the Fusion resource Scopes ,
   • Eg..urn:opc:resource:fa:instanceid=XXXXX urn:opc:resource:consumer::all
   • offline_accessoffline_access is mandatory only for Authorization Code to ensure OIC receives a Refresh Token.
   • Client Authentication – Send client credential as basic auth header
7. Test the connection – you’ll be prompted for consent.
8. Enter Fusion Application Username/password.
9. Post Consent, test, validate and save connection.

Using OAuth 2.0 Client Credentials Flow

Best suited for system-to-system/ scheduled integrations where no user interaction is required.

Steps –

Step 1 – Create Confidential Client in FA IAM

1. Login to IAM in same domain which is domain of FA
2. Navigate to Identity > Domain> Choose FA Domain
3. Go to Integrated Application, Press Button – Add Application
4. Choose Confidential Application
   • Configure this application as a client now
5. Select Client Configuration
   • Client Credentials
6. No redirect URI is needed.
7. Add Resource >> Add Scope
   • Oracle Applications Cloud (Fusion)
8. Press Next for Configure Policy
   • Finish
9. Activate Application.
10. Make note of the application’s Client ID and Client Secret & Scope

Step 2 – Create the Client ID as a user in Oracle Applications Cloud

In Client Credentials flows, any call is invoked in the context of the application itself and not in the context of a user. Therefore, you must model the application’s client ID as a user in Oracle Applications Cloud.

By creating the Client ID as a user, you are indicating that the user (application) has the necessary role and privileges and is authorized to access the resources.

Complete the following steps to create the Client ID as a user:

1. Sign in to Oracle Application Cloud.
2. On the Security Console, click Users.
3. Click Add User Account.
4. Under User Information in the Username field, specify the Client ID of the application that you registered with Oracle IDCS.
5. Enter the other details under User Information.
6. Click Add Role.
7. Based on the resources that you want this application to access, add the appropriate roles

Step 3 – Configure Connection in OIC Gen3

1. Create a new REST/SOAP Connection.
2. Enter WSDL URL Information ending with ?wsdl in case of SOAP
3. Enter REST API Base URLin case of REST.
4. Choose OAuth 2.0 Client Credentials as the security policy.
5. Enter:
   • Client ID & Secret.
   • Access Token URI – Token Endpoint.
6. Test connection – OIC will request a token automatically.
7. Optional Security
   • Scope (Defined from IAM app – Resource/Scope)
   • Client Authentication – Send client credential as basic auth header
8. Test the connection
9. Validate and Test  – save connection.

---

Approach 2 – Using External IAM Domain (Cross-Domain Trust)

When to Use

• Enterprise mandates centralized IAM (External IAM)
• OIC cannot use Fusion IAM directly
• Multi-system identity standardization required

Steps –

When using an External IAM domain, you must perform these additional trust setup steps before creating client applications

Step 1  : Update OAuth Issuer in the External IAM Domain

1. Before configuring trust in Fusion, ensure the external IAM domain issues tokens with a unique issuer (different from the default).
2. Navigate to: Identity > Domains > [Your External Domain] > Security > OAuth Configuration (or Token Issuance).
3. Ensure the IAM domain URL is configured consistently as the issuer, as this value appears in the token as the iss claim and must match the trusted issuer configured in Fusion.
   • https://idcs-<domain>.identity.oraclecloud.com
4. This must match the issuer (iss) claim in the issued OAuth token – refer

Step 2 : Get Certificates from External IAM

1. Enable Access Signing certificate
   • Navigate to Identity>Domains>[Your External Domain] >Settings>Domain settings>>Access Signing Certificate
   • Enable Configure Client Access using Checkbox.
   • This will Allow you download IAM Certificates
2. Download certificates from IAM
   • Get the signing certificates from the Oracle OCI IAM identity domain’s JWK endpoint
   • Get the URL of the Oracle OCI IAM JWK endpoint that gives you the signing certificates
   • <OCI IAM identity domain URL>/admin/v1/SigningCert/jwk
   • Call the JWT endpoint in your browser to retrieve the payloads of the certificates
   • There are two values in the “x5C” sections within the output
   • First value: OCI identity domain certificate – Save it in file as oci_identity_domain_signing.cer
   • Second value: Certificate authority (CA) certificate – Save it in file as oci_identity_domain_ca.cer
   • Copy each certificate value into a separate file. Note that the headers and footers in the files must be in the following exact format without any additional preceding or trailing characters to be successfully uploaded to Oracle Fusion Applications
     —–BEGIN CERTIFICATE—–
     MIIDZjCCAk6gAwIBAgIGAZyQll3…..
     —–END CERTIFICATE—–
   • You can validate the certificate chain by running below commands
     • openssl x509 -in oci_identity_domain_ca.cer -noout -text
     • openssl x509 -in oci_identity_domain_signing.cer -noout -text

Step 3 : Create API Authentication Provide in Fusion Applications.

1. Login to Fusion Cloud Application & navigate to Tools>>Security Console>> API Authentication
2. Press Button – Create Oracle API Authentication Provider and press Edit button
3. Create a new Oracle API Authentication Provider. Set the Issuer to the exact external IAM domain URL
   (e.g., https://idcs-<your-external-domain>.identity.oraclecloud.com).

Step 4 : Upload Signing Certificate in Fusion

1. Upload OCI IAM domain certificates in Fusion Security Console
2. Within the “Oracle API Authentication Provider Details” page from the previous step under tab “Inbound API Authentication Public Certificates” upload both certificates download earlier.
   • OCI identity domain certificate
   • Certificate authority (CA) certificate
3. Note: In some Fusion environments, certificate upload may require raising a Service Request (SR) with Oracle Support. Check your tenancy policy.

Step 5 : Create Resource Application in External IAM

1. Create Resource Confidential Application for Fusion Applications in External Identity Domain
2. Navigate to Identity>Domains><DomainName>>Integrated applications
3. Press Button – Add Application
4. Choose Confidential Applications, choose Resource server configuration, Provide Name , in this case – FA Resource
5. In primary Audience add – Fusion Application URL
6. In Scope provide – /
7. Save and Activate Application

Using OAuth 2.0 Authorization Code Flow

Best suited for user-context operations where actions must run on behalf of a Fusion Applications user.

Steps –

Step 1: Create Confidential Application in External IAM

1. Login to the External IAM Domain
2. Navigate to Identity > Domains > [Your External Domain] > Integrated Applications.
3. Go to Integrated Application, Press Button – Add Application
4. Choose Confidential Application.
   • Configure this application as a client now
5. Select Client Configuration
   • Authorization Code
   • Refresh Token
6. Add the Redirect URI for OIC Gen3:
   • https://<oic_instance>/icsapis/agent/oauth/callback (primary)
   • https://<oic_instance>/ic/pub/oauth2callback (optional)
7. Add Resource >> Add Scope
8. FA Resource – Select the FA Resource application created earlier (in External IAM).
9. Press Next for Configure Policy
   • Finish
10. Activate Application.
11. Make note of the application’s Client ID and Client Secret & Scope.

Step 2: Configure Connection in OIC Gen3

1. Create a new REST/SOAP Connection.
2. Enter WSDL URL Information ending with ?wsdl in case of SOAP
3. Enter REST API Base URLin case of REST.
4. Choose OAuth 2.0 Authorization Code as the security policy.
5. Enter:
   • Client ID & Client Secret (from IAM app).
   • Authorization Code URI (External IAM/oauth2/v1/authorize).
     Access Token URI (External IAM/oauth2/v1/token).
6. Optional Security
   • Scope (Defined from IAM app – Resource/Scope)
   • In scope to obtain refresh token along with access_token,  you need to add – offline_access, refer Scopes, eg..
   • urn:opc:resource:consumer::all offline_access
   • offline_access is mandatory only for Authorization Code to ensure OIC receives a Refresh Token.
   • Client Authentication – Send client credential as basic auth header
   • Test the connection – you’ll be prompted for consent.
   • Enter Username/password.
   • Post Consent, test, validate and save connection.

Using OAuth 2.0 Client Credentials Flow

Best suited for system-to-system integrations/scheduled integrations where no user interaction is required.

Steps –

Step 1 – Create Confidential Client in the External IAM domain.

1. Login to the External IAM Domain
2. Navigate to Identity > Domains > [Your External Domain] > Integrated Applications.
3. Go to Integrated Application, Press Button – Add Application
4. Choose Confidential Application.
   • Configure this application as a client now
5. Select Client Configuration
   • Client Credentials
6. No redirect URI is needed.
7. Add Resource >> Add Scope
8. FA Resource – Select the FA Resource application created earlier.
9. Press Next for Configure Policy
   • Finish
10. Activate Application.
11. Make note of the application’s Client ID and Client Secret & Scope.

Step 2 – Create the Client ID as a user in Oracle Applications Cloud

In Client Credentials flows, any call is invoked in the context of the application itself and not in the context of a user. Therefore, you must model the application’s client ID as a user in Oracle Applications Cloud.
By creating the Client ID as a user, you are indicating that the user (application) has the necessary role and privileges and is authorized to access the resources.

Complete the following steps to create the Client ID as a user:

1. Sign in to Oracle Application Cloud.
2. On the Security Console, click Users.
3. Click Add User Account.
4. Under User Information in the Username field, specify the Client ID of the application that you registered with Oracle IDCS.
5. Enter the other details under User Information.
6. Click Add Role.
7. Based on the resources that you want this application to access, add the appropriate roles.

Step3 – Configure Connection in OIC Gen3

1. Create a new REST/SOAP Connection.
2. Enter WSDL URL Information ending with ?wsdl in case of SOAP
3. Enter REST API Base URLin case of REST.
4. Choose OAuth 2.0 Client Credentials as the security policy.
5. Enter:
   • Client ID & Secret.
   • Access Token URI – Token Endpoint.
   • Test connection – OIC will request a token automatically.
6. Optional Security
   • Scope (Defined from IAM app – Resource/Scope)
   • Client Authentication – Send client credential as basic auth header
7. Test the connection
8. Validate and Test  – Save connection

---

Conclusion

This blog demonstrates that:

• The Fusion IAM native approach is the simplest and most effective in most scenarios
• Cross-domain trust should only be implemented when truly required

Most OAuth complexity in OIC to Fusion integrations does not come from OAuth itself, but from choosing the wrong identity architecture.

Use the Fusion IAM-native approach (Approach 1) wherever possible – it is the simplest, most secure, and recommended pattern. Introduce cross-domain trust (Approach 2) only when enterprise requirements (e.g., centralized identity with external IAM) truly demand it.

References

• Set Up the OAuth Authorization Code Credentials Security Policy with the Oracle Fusion Applications Identity Domain

• Set Up the OAuth Authorization Code Credentials Security Policy with a Non-Oracle Fusion Applications Identity Domain