Oracle's 31 March 2027 password deadline:
what it means for BI Publisher
On 6 November 2026 Oracle said it is deprecating password-based authentication for Fusion Applications REST and SOAP services, and told Oracle Integration customers to migrate before 31 March 2027. Here is what the notice covers, what it leaves open for BI Publisher, and what to do now.
The notice in plain terms
What is changing
Oracle says Fusion Applications is moving from password-based to OAuth token-based authentication for its REST and SOAP services. After enforcement begins, password requests "may fail to authenticate". Oracle Integration blog, 6 November 2026
Who it names
Oracle Integration connections using the ERP Cloud, HCM Cloud and CX Sales adapters with Username Password Token, and the REST and SOAP adapters with password-based policies when they connect to Fusion.
What replaces passwords
Oracle lists two OAuth policies: Authorization Code Credentials and JWT User Assertion. Client credentials is not on that list.
BI Publisher is not named in the notice
BI Publisher reports run over SOAP, so treat the deadline as relevant. Whether tokens work on your pod is something to test, not assume.
What Oracle documents
- BI Publisher SOAP web services accept tokens from the JWT User Assertion grant, sent as an
Authorization: Bearerheader - The userID and password fields stay empty in the request
- A BI Administrator must first set Enable OAuth for SOAP Webservices to True
Why you should still verify it
- Community reports conflict: one Oracle Community post cites knowledge article KB33531 as saying JWT is not supported on BI Publisher, while a reply reports it working
- We have not been able to confirm either report, so ask Oracle Support what applies to your pod and release
- The notice gives a date for Oracle Integration customers. It gives no separate date for other clients
Four steps before March
- 1
List what signs in with a password
Include Oracle Integration connections, scheduled extracts, custom scripts and desktop tools. Reporting accounts are easy to miss.
- 2
Ask Oracle what applies to BI Publisher
Raise a service request for your pod and release, and ask for the current position on token sign-in for BI Publisher web services.
- 3
Prepare a non-production pod
Have your BI Administrator enable OAuth for SOAP web services, then create a confidential application in the pod's identity domain with a trusted certificate and the JWT assertion grant.
- 4
Test every dependent report
A token that signs in is not proof that a report runs. Run the reports you depend on, under the user the token acts as.
Token sign-in is in Preview from version 7.1
We would rather tell you exactly what is proven than promise continuity we have not tested.
Available in Preview
- JWT User Assertion and OAuth authorization code connections, with keys held in the OS keychain
- Connection Test, the SQL worksheet, the report catalog and the AI tab can use a token
- Test turns green only after your pod answers a real BI Publisher catalog call with that token
Not done yet
- We have not yet run a report with a real token on a live pod, so this remains a Preview
- Data Loader and Schema Mirror still need a password-based service account
- OAuth changes how you sign in, not what the data model can read: BI Publisher SQL still runs as the connection-pool user
Check your own pod before the deadline
Connect a non-production pod, try token sign-in, and see the result of a real BI Publisher call.
Sources checked 8 November 2026.