From Service Accounts to User Context: OAuth and JWT Patterns for Oracle OIC to Fusion Integrations

There is a quiet problem in many Oracle Fusion and OIC implementations:

integrations work, but the audit trail tells the wrong story.

The business user creates or updates a transaction from an extension, but Fusion shows the integration service account as the creator. Technically the integration is successful. Functionally the transaction is created. But from an audit, RBAC, and compliance perspective, the identity chain is blurred.

Recently I worked through this pattern in an Oracle Fusion / OIC environment and validated a cleaner approach using OCI IAM, OAuth Authorization Code, OAuth Client Credentials, and JWT User Assertion. The goal was simple: remove password-based Basic Authentication where possible, and preserve the actual logged-in user where the business transaction is user-driven.

The Problem

Many OIC connections to Fusion are still configured with Basic Authentication or Username Password Token. This creates three issues:

→ Password rotation can break integrations.

→ CSF or credential dependencies become operational baggage.

→ Fusion audit fields such as Created By and Updated By show the integration user instead of the actual business user.

For pure back-office automation, a service account may be acceptable. But when VBCS or another user-facing extension triggers OIC to create invoices, suppliers, customers, or journals, the transaction should run in the context of the logged-in user

What We Validated

We validated multiple working patterns:

Integration Area → Security Pattern Validated →Best Fit

Fusion Report SOAP Service → OAuth Client Credentials and OAuth Authorization Code → Password less service/report calls

Fusion FSCM REST → OAuth Authorization Code and JWT User Assertion | Service-user or actual-user REST operations

ERP Cloud Adapter → OAuth Authorization Code and JWT User Assertion → ERP operations with service or user context

ERP FBDI importBulkData → ERP Cloud Adapter Services → ErpIntegrationService → importBulkData with JWT User Assertion → FBDI/ESS submission as actual logged-in user

The most important learning was around ERP Cloud Adapter and FBDI.

The native “Import Bulk Data into Oracle ERP Cloud” adapter option is convenient, but in our tested path it did not expose ‘Security Properties -> Subject’ in the mapper. Without that target Subject, we could not dynamically run the import as the logged-in user.

The working solution was to stay within ERP Cloud Adapter, but use:

ERP Cloud Adapter → Services → ErpIntegrationService → importBulkData

Security: OAuth using JWT User Assertion

Mapper: source Subject -> target Security Properties / Subject

This gave us the best of both worlds: ERP Cloud Adapter usage and actual user-context propagation.

The Decision Rule

Here is the rule I now use:

• Use OAuth Authorization Code when the integration should run as a controlled integration user.

• Use JWT User Assertion when the transaction must run as the logged-in Fusion/VBCS user.

• Use ERP Cloud Adapter Services → ErpIntegrationService → importBulkData when FBDI/ESS must run in user context.

• Use the native ERP Adapter Import Bulk Data action for system-context imports where service-account ownership is expected.

Why JWT User Assertion Matters

JWT User Assertion lets OIC request a token for the asserted user. In the mapper, the incoming user identity can be passed into the outbound Fusion connection:

Source Security Properties / Subject → Target Security Properties / Subject

That one mapping changes the execution model. Fusion receives the call in the user’s context, applies that user’s RBAC and data access, and the transaction audit can reflect the actual business user rather than the integration service account.

What About Callbacks?

For FBDI importBulkData, the submit integration and callback integration are separate conversations.

The submit integration uploads the file and submits the import. The callback integration is configured separately using ERP Cloud Adapter as a trigger to receive completion of the same FBDI process.

For the direct ErpIntegrationService/importBulkData pattern, remember to populate job options. A practical pattern is:

Callback URL = #NULL

Job Options = ExtractFileType=ALL,InterfaceDetails=<ID>,ImportOption=Y,PurgeOption=N,EnableEvent=Y

If callback processing must continue as the original submitter, persist a correlation record during submit, such as request id, file name, group id, and original Subject. Then reuse that Subject in the callback flow’s next Fusion invoke.

CSF and Password Impact

This was another important clarification.

For the outbound OIC-to-Fusion call using JWT User Assertion, no Fusion username/password CSF key is needed. The trust moves to certificate/private-key based signing and IAM configuration.

For callbacks, current OIC3 ERP event handling uses token-based authentication for Fusion-originated event messages. In older or legacy environments, CSF/event subscription settings may still exist and should be validated, but those callback credentials do not decide the ESS submit user.

Final Takeaway

Moving from Basic Authentication to OAuth is not just a security cleanup. Done properly, it improves audit quality, preserves user RBAC, reduces password-change risk, and gives teams a cleaner mental model for OIC-to-Fusion integrations.

The real design question is not “Can OIC connect to Fusion?”

The better question is:

→ Should this integration run as a service account, or as the actual business user?

Once that is clear, the security policy almost chooses itself.

OracleCloud #OracleIntegrationCloud #OCI #OracleFusion #IAM #OAuth #JWT #ERPCloud #VBCS #IntegrationArchitecture