Oracle Integration OAuth Migration: What Fusion Customers Must Do

Oracle Integration OAuth migration is now required for any Oracle Integration (OIC) connection that reaches Oracle Fusion Applications REST or SOAP services with a password. In a November 6, 2026 announcement, Oracle said it is deprecating password-based authentication for those services and that affected customers must move to a supported OAuth method before March 31, 2027. The change happens at the connection level, but those connections often carry the Oracle Fusion ERP, HCM, and CX processes your teams rely on every day, so a little planning now keeps them running after the deadline.

• Oracle requires affected Oracle Integration connections to Fusion Applications to move to a supported OAuth method before March 31, 2027.
• The Oracle ERP Cloud, Oracle HCM Cloud, and Oracle CX Sales and B2B Service adapters are in scope, along with REST and SOAP adapters that use password policies to reach Fusion Applications.
• Existing Oracle Integration connections will not switch to OAuth automatically, so your team will need to reconfigure, test, and validate each affected connection and the integrations that depend on it.

Oracle Fusion Applications is replacing password-based authentication for its REST and SOAP services with OAuth token-based authentication. Instead of sending a username and password with each request, the Oracle Integration adapter presents an access token. Fusion Applications checks that token with OCI IAM, Oracle's identity and access service, before it accepts the call.

Oracle lists two supported policies for affected connections: Authorization Code Credentials and JWT User Assertion. Neither one is the right answer for every connection. The best fit depends on the adapter, the Fusion service being called, and how your identity domains are set up. Oracle's documentation on invoking Fusion Applications endpoints with OAuth explains how the resource application can live in the Fusion Applications identity domain or in a separate domain, such as the Oracle Integration identity domain.

It also helps to keep the scope in perspective. This changes how services authenticate. It does not mean every Fusion user account or every integration needs rework.

What matters is the security policy a connection uses, not the adapter alone. Oracle has flagged these configurations for both invoke and trigger connections:

• Oracle ERP Cloud Adapter and Oracle HCM Cloud Adapter using Username Password Token or Username Password Token with PGP Key Support.
• Oracle CX Sales and B2B Service Adapter using Username Password Token.
• REST Adapter using HTTP Basic Authentication to connect to a Fusion Applications instance.
• SOAP Adapter using HTTP Basic Authentication, Username Password Token, or other password policies to connect to a Fusion Applications instance.

Once Oracle begins enforcement, requests that still rely on password-based authentication may fail. Depending on your architecture, that could interrupt financial interfaces, employee data synchronization, scheduled processing, and other automated transactions that depend on Fusion REST or SOAP services.

Connection reuse raises the stakes. A single connection often supports several integrations, so changing its security policy can affect multiple business processes at once. Plan for regression testing from the start rather than treating it as a final check.

Start with an inventory. List every Fusion-facing connection across development, test, and production, along with its security policy, the integrations that use it, its business owner, and how critical it is. Sorting that list by security policy quickly shows which OIC connections need attention and which do not.

Next, choose the right OAuth policy for each affected connection and complete the setup. Depending on the method, that can mean configuring an identity domain, registering an application, granting the right permissions, and, for JWT User Assertion, managing signing keys.

Then migrate in nonproduction first. A successful connection test confirms the setup works, but it does not prove that dependent integrations, scheduled processes, and error handling still behave as expected. Move production changes through your normal change-management process, and leave enough time to test and monitor before the deadline. Starting the work in the final weeks leaves little room to fix what testing uncovers.

If your team would like support, we can work alongside you to inventory affected connections, plan the cutover, and validate the integrations your business depends on. That work is part of our technology consulting and managed services engagements with organizations running Oracle ERP Cloud, HCM, and other Fusion Applications.

This is a targeted authentication change, but its operational impact depends on how widely your affected connections are reused. A clear inventory, a controlled cutover, and end-to-end testing give you the best chance of finishing your Oracle Integration OAuth migration on schedule and without disruption. For the full list of affected adapters and required actions, read Oracle's announcement on moving Fusion Applications connectivity to OAuth.