QueryWell
For integration & reporting technical leads

Oracle Fusion API authentication:
what's changing and what still works

Oracle has announced it is deprecating password-based authentication for Fusion REST and SOAP services, and has told Oracle Integration customers to migrate before 31 March 2027. Here's what's actually happening, what the authoritative sources say, and what it means for how you connect. Read our guide to the deadline.

Start a free 14-day trial How QueryWell handles auth
The landscape

Three things Oracle has actually done

Here's what the published sources say.

Password sign-in is being deprecated

In November 2026 Oracle said Fusion REST and SOAP services are moving to OAuth tokens, that Oracle Integration customers must migrate before 31 March 2027, and that password requests "may fail to authenticate" after enforcement begins. Oracle Integration blog, Nov 2026

OIC Gen3 already requires OAuth

Oracle Integration Cloud Generation 3 connections to Fusion do not support basic authentication for Factory REST APIs or REST endpoints. Anyone on Oracle's modern integration stack has no choice. Oracle Community, OIC Gen3 discussion

OPC Apps OAuth secrets deprecated (April 2026)

As of 30 April 2026, Oracle-provisioned OAuth client secrets from "OPC Apps" are deprecated. Any integration that copied a client secret from an Oracle-provisioned application must now create its own confidential application under Integrated Applications. OCI Service Change Announcements, March 2026

What still works today

  • Basic authentication over HTTPS to Fusion REST APIs — for non-SSO users, on pods where WAF basic-auth blocking hasn't been enabled, until Oracle's enforcement reaches your pod
  • OAuth 2.0 with authorization code grant (user-present flow) — the most widely documented path
  • OAuth 2.0 with client credentials grant (server-to-server) — supported but requires service-account setup at the user level, not just the application level
  • SAML 2.0 bearer tokens and JWT assertions — documented alternatives for enterprise identity scenarios

What breaks silently

  • Basic auth when the Fusion user is SSO-federated — credentials don't exist in the local identity store, so REST calls return 401
  • Client credentials grant when the OAuth client is provisioned at the application level rather than the user level — returns invalid_client
  • Any integration still using an OPC Apps client secret copied before April 2026 — Oracle is revoking these
  • Desktop SQL tools (Toad, SQL Developer) — Fusion exposes no SQL*Net or JDBC; these tools cannot connect regardless of auth method
The migration path

OAuth 2.0 client credentials: the setup that trips teams up

The most common server-to-server pattern — and the one with the most undocumented failure modes. Here's what the Oracle Community threads show.

Practitioner reality

The four things that go wrong

  1. 1

    Application-level vs user-level provisioning

    The OAuth client must be provisioned at the user level (Security Console → User → Service Account → OAuth 2.0 client credentials), not just at the application level. Teams that skip this step hit invalid_client with no clear diagnostic. Oracle Community thread, April 2024–present

  2. 2

    IDCS certificate trust

    For OIC Gen2 connections, the Fusion Applications side must trust the IDCS signing certificate — uploaded via Security Console → API Authentication Provider. Gen3 with Fusion SaaS Identity Domain skips this step. OAuth Setup for Fusion ERP Connections, July 2025

  3. 3

    Scope format is pod-specific

    The OAuth scope follows the pattern urn:opc:resource:fusion:{podname}:boss/ — the pod name must match your instance exactly. A typo here produces a valid token that's rejected by the resource server.

  4. 4

    Third-party tools may send the wrong auth header

    Some ISV platforms (SailPoint ISC, for example) include a Basic authorization header by default when requesting an OAuth token — Oracle's IDCS endpoint rejects this format. The fix is to exclude the Basic header on the token request. SailPoint Developer Community, May 2026

QueryWell's approach

What QueryWell actually does

QueryWell connects to Fusion through Oracle's supported BI Publisher surface. Report execution authenticates the way BI Publisher requires, and the app is honest about what that means.

Basic auth, done properly

Most QueryWell connections run reports with basic authentication over HTTPS and a dedicated service account — the API path Oracle's own MFA-enforcement guidance explicitly exempts ("authentication for REST/SOAP APIs does not require MFA"). Credentials live in the OS keychain, and a green Test means a real, executable login: 401 and 403 fail loudly.

Token sign-in, in Preview

Production execution today uses basic auth with in-envelope credentials. From version 7.1, JWT User Assertion and OAuth authorization code connections are in Preview for connection tests, the worksheet, the catalog and the AI tab. Your BI Administrator must enable OAuth for BI Publisher SOAP services, and a green Test means your pod answered a real call with that token. Data Loader and Schema Mirror still need a password-based account.

What this means for your integration landscape

Plan now for every integration that signs in with a password, and ask Oracle Support what applies to BI Publisher on your pod and release. Any integration that copied an OPC Apps client secret also needs to be re-registered under its own confidential application.

References

Authoritative sources, not forum speculation

Oracle official

Sources checked 8 November 2026. Check your pod's release notes each quarter.

Practitioner & community

Connect to Fusion the way BI Publisher actually authenticates

Evaluate QueryWell on your own Fusion pod for 14 days — connect your pod, run your first BI Publisher SQL, and export a hashed result in minutes.

Start a free 14-day trial See the security model