Oracle Fusion OAuth Migration: Deadline 31 March 2027
Picture this. It's the first week of April 2027, month-end close is in full swing, and your AP team notices that supplier invoices stopped landing in Fusion Payables three days ago. Nobody touched the integration. Nothing was deployed. The connection simply stopped authenticating.
Oracle Fusion OAuth Migration: What Your Integration Team Needs to Do Before 31 March 2027
That's the scenario Oracle is warning about. On 6 November 2026, Oracle confirmed it is deprecating password-based authentication for Oracle Fusion Applications REST and SOAP services. If your Oracle Integration (OIC) connections still sign in to Fusion with a username and password, they need to move to Oracle Fusion OAuth before 31 March 2027.
The good news: the change is well defined, and for most teams it's a few weeks of careful work, not a re-platforming project. The bad news: Oracle won't do it for you, and the deadline lands right after year-end close.
Here's what is changing, how to tell if you're affected, and the plan we use with clients across the UAE and GCC.
What exactly is Oracle changing?
Until now, many integrations called Fusion APIs using basic authentication or a Username Password Token. A service account, a password, and you're in. It's simple, which is why it is everywhere.
Oracle is replacing that with OAuth token-based authentication. Instead of sending a password on every call, the integration gets a short-lived access token from your Oracle identity domain and presents that token to Fusion.
In Oracle Integration, Oracle supports two OAuth policies for this:
- Authorization Code Credentials. A user grants consent once, and OIC then works with tokens issued for that user, refreshing them as needed.
- JWT User Assertion. OIC signs a JSON Web Token with a certificate and exchanges it for an access token. No interactive login is involved, which suits most system-to-system flows.
Which one fits depends on the adapter, the Fusion service, and how your security team manages certificates and integration users. In practice, we see JWT User Assertion chosen for most back-office integrations because it doesn't depend on a person clicking "consent".
Is your OIC environment affected?
Oracle lists these Invoke and Trigger connections to Fusion as in scope when they use password-based security policies:
| Adapter | Password-based policies affected |
|---|---|
| Oracle ERP Cloud Adapter | Username Password Token; Username Password Token With PGP Key Support |
| Oracle HCM Cloud Adapter | Username Password Token; Username Password Token With PGP Key Support |
| Oracle CX Sales and B2B Service Adapter | Username Password Token |
| REST Adapter (calling Fusion) | HTTP Basic Authentication |
| SOAP Adapter (calling Fusion) | HTTP Basic Authentication, Username Password Token, other password-based policies |
There are also two places teams tend to miss:
- Systems outside OIC. A bank platform, an AP automation tool or a custom app may call Fusion REST APIs directly with basic auth. Oracle's notice focuses on OIC, but the Fusion-side change is about REST and SOAP services in general, so review these too.
- Jobs that rarely run. A quarterly allocation feed or a year-end HR extract won't fail until the day it runs. Those are the ones that surprise people.
What breaks if you miss the deadline?
Oracle says requests that keep using passwords may fail to authenticate once enforcement begins, which can interrupt integration flows and scheduled processing. For a finance or HR function, that tends to look like:
- Supplier invoices stuck outside Payables
- Bank statements and payment files not loading at month end
- New joiners missing from payroll because the HR sync stopped
- Orders and customer records no longer moving between Fusion and your CRM
If you're in the UAE or Saudi Arabia, there's an extra edge to this. Invoice integrations increasingly feed e-invoicing obligations, so a silent authentication failure can turn into a compliance issue, not just an IT ticket.
A practical Oracle Fusion OAuth migration plan
This is the sequence we follow. It works for a 10-connection setup and scales to a few hundred.
- Build the inventory. Export or list every OIC connection that points at Fusion. For each, note the adapter, the security policy, the integrations that use it, and how often they run. Add any non-OIC systems that call Fusion APIs.
- Decide the OAuth policy per connection. Pick Authorization Code Credentials or JWT User Assertion. Then set up the confidential application in your Oracle identity domain, and agree who owns certificate renewal. An expired certificate causes exactly the outage you're trying to avoid.
- Change one connection end to end in a non-production environment. Swap the security policy, add the OAuth details, test the connection. Use it to write a short runbook for the rest.
- Regression-test, then roll through the rest. Run real transactions through every dependent integration, including error paths and scheduled jobs. Confirm tokens refresh correctly on long-running flows.
- Cut over to production on a quiet day. Avoid month-end, payroll cut-off and year-end close. Keep the old configuration documented for rollback, and monitor for at least one full business cycle.
A rough guide on effort: under 20 Fusion connections is usually two to four weeks including testing. Larger estates, or ones with lots of direct API callers, deserve a proper project plan with an owner and sign-offs per environment. Whatever the size, aim to be done by the end of January 2027 so you aren't migrating during the year-end.
The upside nobody mentions
It's easy to see this as compliance busywork. It isn't only that. Shared integration passwords tend to live in too many places and rarely get rotated. Tokens are short-lived and scoped, and certificate-based JWT flows are far easier to audit. You also come out of the exercise with something most companies don't have: a clean, current map of every Fusion integration you run.
How Innovage Cloud can help
Our Oracle ERP integration team has built and supported 200+ integrations across Oracle Fusion, OIC and third-party platforms. For OAuth, we can run the whole migration: inventory, OAuth design, identity domain setup, regression testing and a controlled cutover. If you already have a partner, we're happy to do an independent review of your connections instead.
After the move, our Oracle Fusion support team can keep an eye on certificates, token errors and new integrations so this doesn't creep back.
We'll review your Fusion connections and tell you exactly which ones need to change before 31 March 2027.
Frequently asked questions
What is the deadline for the Oracle Fusion OAuth migration?
Oracle asks customers to move affected connections to OAuth token-based authentication before 31 March 2027.
Will Oracle migrate my OIC connections automatically?
No. The new security policies are available, but existing connections stay as they are until you update and test them.
Which OAuth options does Oracle Integration support for Fusion?
Authorization Code Credentials and JWT User Assertion. JWT User Assertion is usually the better fit for unattended, system-to-system integrations.
Do all Fusion integrations need to change?
No. Only connections using password-based policies, such as Username Password Token or HTTP Basic Authentication. Connections already on OAuth aren't affected.
What happens if we don't migrate in time?
Once enforcement begins, password-based requests may fail to authenticate, which can stop integration flows and scheduled jobs.
How long does an Oracle Fusion OAuth migration take?
For most mid-sized setups, two to four weeks including testing. It depends on the number of connections, direct API callers and how quickly test environments are available.
