QueryWell
For integration & reporting technical leads

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

Basic authentication over HTTPS still works for Oracle Fusion REST APIs — but Oracle is steering customers toward OAuth 2.0, newer services require it, and SSO-enabled users can't use basic auth at all. Here's what's actually happening, what the authoritative sources say, and what it means for how you connect.

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

Three things Oracle has actually done — not rumoured

Practitioner forums are full of speculation about a forced cut-off. Here's what the published sources say.

Basic auth is discouraged, not disabled

Oracle's October 2025 SaaS Cloud Security blog calls basic authentication "the least secure option" and "strongly discouraged." But disabling it requires a customer-initiated service request through WAF for SaaS — it's opt-in, not platform-mandated. Oracle SaaS Cloud Security blog, Oct 2025

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
  • 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

BI Publisher's report service takes credentials inside the request, so QueryWell runs reports with basic authentication over HTTPS — 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.

Where OAuth fits

QueryWell ships OAuth 2.0 PKCE sign-in — browser consent, tokens in the OS keychain, no client secret on disk. BI Publisher's SOAP surface requires in-envelope credentials, so execution today uses basic auth; the OAuth plumbing is ready for the day Oracle opens a token path to the reporting surface.

What this means for your integration landscape

If your Fusion pod still accepts basic auth and your integration users are local (not SSO-federated), your existing integrations are not at immediate risk. But every new integration should use OAuth 2.0 — and any integration that copied an OPC Apps client secret needs to be re-registered under its own confidential application. Oracle's direction of travel is clear even without a hard deprecation date: the WAF basic-auth block is available, OIC Gen3 requires OAuth, and the OPC Apps secret deprecation is already in effect.

References

Authoritative sources, not forum speculation

Oracle official

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