Oracle Fusion Cloud ERP

Overview

Clarity’s Oracle Fusion Cloud ERP connector reads users and roles, and provisions user accounts and role assignments, through Fusion’s SCIM REST API (/hcmRestApi/scim).

The connector supports two authentication methods:

• Basic auth — a Fusion service-account username + password.

• OAuth 2.0 JWT user assertion — Oracle’s documented pattern for service-to-service Fusion API access. Clarity signs a short-lived JWT asserting your Fusion service-account user and exchanges it with your identity domain (IDCS) for an access token issued as that user. No password is ever stored with Clarity, and you can revoke access on your side by rotating or removing the signing certificate.

Naming note: Oracle’s product is Oracle Fusion Cloud ERP (part of Oracle Fusion Cloud Applications). The application currently appears in Clarity’s integration catalog as “Oracle Cloud Fusion ERP” — the same connector under an older label.

Note: the OAuth client_credentials grant is not supported. Fusion rejects app-identity tokens with a 403 on every API call, so a token without a user subject can never work. If you previously configured only a Client ID and Client Secret, you must add the signing key and service-account username described below (or use Basic auth) — the connector will tell you exactly that if the OAuth configuration is incomplete. (The optional Last Access Date credentials in Step 3 do use client_credentials, but they talk to the identity domain’s own admin API, not to Fusion — they are not an authentication method for this connector.)

Prerequisites

• A Fusion service account (integration user) that can be granted the roles the connector’s API calls are authorized against — see Step 1.

• Identity domain / IDCS administrator access to the identity domain that fronts your Fusion pod, with permission to create confidential applications and import trusted partner certificates.

• openssl (or an equivalent tool) to generate the RSA signing keypair and its X.509 certificate — required for the OAuth JWT user-assertion method, not for Basic auth.

• For the optional Last Access Date only: a Fusion environment that has been through the Fusion Identity Upgrade (25B+), so an OCI IAM identity domain exists that exposes lastSuccessfulLoginDate. Nothing else in the connector depends on this.

Step 1 — Create the Fusion service account

Required for both authentication methods.

1. In Fusion, create (or designate) an integration user — e.g. CLARITY_INTEGRATION.

2. Grant it the roles your use of the connector requires. Reading users and roles and managing user accounts through the SCIM API is typically covered by an integration role such as Integration Specialist; your security administrator may use a custom role instead. OAuth does not change this — API calls are authorized against this user’s roles, exactly as with Basic auth.

Step 2 — Configure OAuth (JWT user assertion) in the identity domain

Skip this step if you are using Basic auth. All steps happen in your Oracle Identity Domain / IDCS console (the identity domain that fronts your Fusion pod).

1. Generate a signing keypair. Create an RSA keypair and a matching X.509 certificate (self-signed is fine), for example:

• openssl req -x509 -newkey rsa:2048 -keyout clarity-signing.key -out clarity-signing.crt -days 730 -nodes

1. Create (or reuse) a confidential application in the identity domain:

   • Enable the client configuration and allow the JWT assertion (urn:ietf:params:oauth:grant-type:jwt-bearer) grant.

   • Mark the client as a Trusted client and import the X.509 certificate (clarity-signing.crt) as the trusted partner certificate. Note the certificate alias you give it — Clarity can send it as the JWT kid header.

   • Under the app’s resources, add the Fusion Applications resource and grant the scope urn:opc:resource:consumer::all.

   • Record the Client ID and Client Secret.

2. Find your IDCS instance ID. Your identity domain URL looks like https://idcs-<idcs-id>.identity.oraclecloud.com. Clarity requests tokens from https://idcs-<idcs-id>.identity.oraclecloud.com/oauth2/v1/token (the full URL set is published at /.well-known/idcs-configuration on that host).

3. Build the scope string. The Fusion audience and the scope name must be concatenated with no space between them:

• urn:opc:resource:fa:instanceid=<instance-id>urn:opc:resource:consumer::all

• A space between the instanceid=<id> audience and urn:opc:... makes the token endpoint return invalid_scope. (Clarity also closes this specific boundary automatically if a space or line break slips in.)

Step 3 — Optional: Last Access Date via the OCI IAM identity domain

Skip this section entirely unless you want a Last Access Date on this application’s users. Leave the three fields below blank and the sync runs exactly as it does today.

Fusion’s SCIM API carries no last-login attribute. The value lives in the OCI IAM identity domain that Fusion created during the Fusion Identity Upgrade (25B+), which exposes lastSuccessfulLoginDate per user. Clarity reads it with a separate, read-only connection and attaches it to this ERP application’s users.

Two things to get right before you start:

• It must be the Fusion-created identity domain — not the default OCI Console domain. Every Fusion environment (Dev / Test / Prod) has its own domain, so you need one set of credentials per Fusion environment.

• This is a different application from the JWT-assertion one in Step 2. That app asserts a Fusion user against the Fusion API; this one authenticates as itself against the identity domain’s own admin API.

Tip — can you reuse credentials you already have? If you already have an Oracle Cloud Identity Domain connection in Clarity, compare the host in that application’s Tenant URL against the OAuth IDCS ID on this ERP application (Step 2.3). If the idcs-<id> portions match, they are the same domain and those credentials can be reused verbatim. If they differ, they front different Fusion environments and you need a confidential app per environment.

If you also run Clarity’s Oracle Cloud Identity Domain connector, see the Oracle Cloud Identity Domain setup guide — the same confidential application can be reused when the idcs-<id> matches.

1. Sign in to the Fusion-created identity domain’s console (https://idcs-<idcs-id>.identity.oraclecloud.com) — the <idcs-id> is the one configured on this ERP application.

2. Create a confidential application in that domain:

   • Enable the client configuration and allow the Client Credentials grant. No redirect URL and no user assertion are needed.

   • Record the Client ID and Client Secret.

3. Grant it read access to users. Assign the application an identity-domain administrator role that permits reading Users — Identity Domain Administrator works, but the least-privileged role your security team allows that can GET /admin/v1/Users is preferable. Clarity only reads.

4. Clarity requests its token with the scope urn:opc:idm:__myscopes__ — nothing to configure, but your security team may ask.

Known limitation

lastSuccessfulLoginDate is an identity-domain attribute — it records the last successful authentication to the domain, not ERP module usage. If that domain fronts multiple Fusion pillars (ERP + HCM), a login to any of them updates the single timestamp; its effective meaning is “last login to this Fusion environment.”

That is a weaker signal than an app-specific report and weaker than a custom BI report measuring actual ERP usage. If you intend to retire such reports, validate this on non-production first against known ERP-only and known HCM-only users before your next user access review depends on it.

The lookup also pages the identity domain at most 100 times (100,000 users); if a domain is larger than that the sync logs a warning that Last Access Date is incomplete and keeps the accounts it did read.

Last Access Date is stored to the whole second in UTC, truncated rather than rounded (2026-09-04T10:30:28.546Z is stored as 2026-09-04 10:30:28), so it matches the second the Oracle console shows for that user.

Step 4 — Enter the credentials in Clarity

In Clarity, add (or edit) the Oracle Cloud Fusion ERP application and fill in:

The OAuth set is all-or-nothing. All of Client ID, Client Secret, Signing Private Key, Service Account Username — plus the OAuth IDCS ID that identifies the token host — are required for the JWT user-assertion grant. If only the Client ID/Secret pair is present, the connector falls back to Basic auth when a username/password is configured, and otherwise fails with a message naming the missing fields.

The three Identity Domain fields are all three or none. Fill in all of them to turn Last Access Date on, or leave all three blank and the sync runs exactly as it does today with Last Access Date empty. They are entirely separate from the authentication fields above — they never change how Clarity authenticates to Fusion. If the identity domain is unreachable or the credentials are wrong, the user and entitlement import still completes; Clarity logs a warning and leaves Last Access Date empty. A single-identity sync (one user re-synced on demand) never clears a Last Access Date it already recorded — if that per-user lookup fails or finds nothing, the previously stored value stays.

Save, then use Clarity’s Test credentials action to confirm connectivity before the first sync.

Step 5 — Credential rotation / revocation

• Rotate the signing key: generate a new keypair, import the new certificate on the confidential app, update the private key (and alias) in Clarity, then remove the old certificate.

• Revoke Clarity’s access: remove the trusted partner certificate (or deactivate the confidential app). No password reset is needed — Clarity never holds the service account’s password under OAuth.

• Rotate the Last Access Date credentials independently: regenerate the secret on the identity-domain confidential application and update the Identity Domain Client Secret field. Nothing about Fusion authentication changes.

Troubleshooting

What Clarity does NOT do

• No client_credentials against Fusion — the grant was removed because Fusion rejects app-identity tokens with a 403 on every call. The only supported methods are Basic auth and the OAuth JWT user assertion.

• No writes to the identity domain — the optional Last Access Date connection is read-only (GET /admin/v1/Users only). Clarity never creates, modifies, or disables identity-domain users, applications, or roles.

• No ERP module usage measurement — Last Access Date is a domain-level last login, not evidence that anyone used an ERP module. See “Known limitation” above.

• No password storage under OAuth — the JWT user-assertion method never holds the Fusion service account’s password. Only Basic auth stores one.

• No user deactivation or deletion — the connector creates users and adds/removes their role assignments, but has no disable, suspend, or delete operation against Fusion.

• No attribute write-back — beyond the fields set when creating a user, Clarity does not push identity attributes back into Fusion.

• No non-SCIM Fusion data — only /hcmRestApi/scim Users and Roles are read. Financials, procurement, and other ERP module data are out of scope.

Need Help?