Multicloud is the new black. In addition to OCI, you are likely to run workloads in other cloud environments like AWS, Azure, or GCP, and leverage platforms such as GitHub Actions for your CI/CD pipelines. These workloads probably need frequent access to OCI APIs but traditional approaches, such as provisioning users into OCI IAM or embedding long-lived API keys, introduce operational overhead and risk.

OCI IAM Workload Identity Federation (WIF) enables external workloads to securely exchange third-party OpenID Connect tokens (in the form of JSON Web Tokens) for OCI-issued User Principal Session Tokens (UPST). OCI UPSTs are short-lived tokens that leverage asymmetric cryptography to help optimize security while facilitating access. This approach preserves the workload’s existing identity context while enabling secure access to OCI APIs while eliminating the need for static credentials or identity duplication.

This WIF token exchange capability unlocks:

  • Secure access across cloud boundaries without duplicating identities to OCI.
  • Short-lived, scoped tokens prevent standing access and improve usability and security for hybrid applications.
  • DevOps pipeline alignment between OCI and orchestration/automation hosted in Azure, AWS, GCP, or GitHub.

WIF plays a foundational role in Oracle’s multicloud initiatives which include solutions for running Oracle Cloud Database Services at Azure, Google Cloud, and AWS. These services allow customers to run applications at other clouds while leveraging Oracle’s best-in-class database and infrastructure capabilities.

Key Benefits

  • Eliminate static API keys: Replace long-lived credentials with short-lived, identity-bound tokens.
  • Secure by design: Cryptographic proof-of-possession (PoP) limits use to legitimate token holders.
  • Optional impersonation: Maintain the user context or optionally impersonate OCI service users.
  • Fully auditable: Token issuance and usage are logged end-to-end and linked by a request identifier.
  • Multicloud ready: Easily integrate OCI into your existing cloud workflows without user duplication.
  • Native fit for multicloud workflows: Optimized for Oracle multicloud services.

How it works

The WIF token exchange process starts when an externally-hosted workload obtains an OpenID Connect token (JSON Web Token or JWT) from its native Identity Provider and exchanges it for a short-lived OCI UPST token using OCI’s token exchange API. The UPST token, embedded with the caller’s public key, is then used to securely call OCI APIs with Proof-of-Possession enforcement.

OCI IAM Workload Identity Federation (WIF) Token Exchange Process
OCI IAM Workload Identity Federation (WIF) Token Exchange Process

The diagram above helps visualize the steps involved in the WIF token exchange process:

  1. The external workload authenticates with its local Identity Provider and receives a OIDC token in JWT format.
  2. The workload calls the OCI Token Exchange API and submits the JWT along with its public key.
  3. OCI IAM performs trust validation by verifying the JWT’s signature, audience claim, caller authorization, and impersonation rules (if configured).
  4. OCI issues a short-lived UPST token which embeds the workload’s public key for proof-of-possession.
  5. The workload uses the UPST token (signed with its private key) to securely call OCI APIs. OCI verifies the signature using the sender’s public key.
  6. Token issuance and API usage are fully auditable, enabling end-to-end traceability through a unique request identifier (opc-request-id).

Security Considerations

  • Proof-of-Posession (PoP): Each request must be signed by the workload using its private key. OCI verifies the signature against the JSON Web Key embedded in the UPST.
  • Key Management: Private/public key pairs are managed and rotated by the caller. OCI does not store the private keys used for these transactions.
  • Least Privilege via IAM Policies: Customers should use IAM Policies to tightly scope permissions for the service user (UPST principal). This helps ensure Least Privilege access to OCI resources is being enforced.

Auditing and Traceability

OCI captures detailed audit logs for every token exchange, recording the identity of the requester, the trusted identity provider, and the type of token presented. Each exchange operation generates a unique request identifier (opc-request-id), which links the token issue event with downstream OCI API activity.

The audit trail includes the time of issuance, request status, and token metadata, providing end-to-end visibility from the incoming token to UPST issuance and subsequent resource access—enabling traceability across the full authentication and authorization flow.

Want to Know More?

To learn more about Oracle Cloud Infrastructure, start with an Oracle Cloud Free Trial or select Contact Us to reach the Oracle Security sales team for a demo.

To learn more about how Oracle Cloud can help you build secure, credential-free multicloud integrations: