One OAuth client per connection

Integration security in an Oracle estate is decided one connection at a time, usually under deadline, usually by whoever is building that integration that week. Left to accumulate, the result is an estate with a dozen authentication styles and no inventory. Our standard is short enough to enforce.

The standard

1. OAuth, not Basic. Every Oracle Integration Cloud connection to Fusion authenticates with OAuth 2.0. Basic authentication is permitted only with a documented review and an exception signed by the integration owner and the security owner, with an expiry date.
2. Confidential clients. The OAuth client is a confidential application in the identity domain, with the client secret held in a vault and rotated on a schedule, never pasted into a connection by hand and forgotten.
3. One client per connection. Each integration connection has its own OAuth client. No sharing, even between two integrations built by the same team on the same day.

The first two rules are widely agreed. The third is the one that gets argued with, and the one that matters most in production.

Why one per connection

A shared OAuth client is convenient: one registration, one secret, one set of scopes. It works in testing, and it works in production for a while.

Then two integrations that share the client run at the same time and both find their access token near expiry. Each requests a refresh. The identity service issues a new token to one and, depending on configuration, invalidates the previous grant for the other. The second integration fails its next call with an authentication error, retries, and may succeed or may fail again. From the outside it looks like an intermittent outage in an integration that has not changed. The logs point at authentication. The team rotates the secret, which fixes nothing, because the cause is contention, not credentials.

A shared client turns two healthy integrations into one intermittent fault that nobody can reproduce on demand.

One client per connection removes the contention. It also gives each integration its own audit trail in the identity domain, its own scope grant, and its own blast radius when a secret has to be revoked. Those are the properties an auditor asks about, and they come free with the rule.

The inventory

You cannot enforce a standard against connections you have not listed. Phase 4 of our method inventories every PaaS integration: each Oracle Integration Cloud connection, each Visual Builder application, each function or API gateway route that talks to Fusion or to OCI services. For each we record the authentication method, the identity it runs as, the scopes it holds, where the secret lives and when it was last rotated.

The inventory almost always surfaces the same three things: connections on Basic authentication with a named user account, clients shared between integrations, and secrets that have never been rotated because nobody knew the rotation would break something. Each becomes a numbered finding with a remediation path.

Migrating without breaking things

Moving a connection from Basic to OAuth, or splitting a shared client, is not risky if it is sequenced. Register the new confidential client and grant it the scopes the integration actually uses, which is usually fewer than the shared client had. Update the connection in a non-production instance and run the integration's own test cases. Promote the connection configuration, not the secret; the production secret is set in production from the vault. Retire the old client only after the audit log shows it idle.

We write that sequence into the build document as a runbook, once, and it is reused for every connection thereafter. The first migration takes a day. The tenth takes an hour.

What this buys you

An estate where every integration authenticates the same way, is listed in one place, and fails independently of its neighbours. That is a modest ambition, and it is the difference between an integration layer that can be audited and one that can only be explained.