From enterprise identity to a shared foundation for people, workloads and AI

Oracle’s identity and access management (IAM) modernization brings enterprise identity and cloud infrastructure authorization together in a unified platform. Building on the enterprise anchors OAM, OIF, OIM and OID, the journey moved to Oracle Identity Cloud Service (IDCS), Oracle’s first cloud-native identity service for application access, federation, lifecycle management, provisioning and directory services. OCI IAM’s infrastructure authorization and IDCS’s SaaS identity services then converged within OCI IAM, combining identity domains with IAM policies. Customers gained a shared platform for common security practices across infrastructure, SaaS, workloads and AI.

Open standards have guided this journey and helped us build a comprehensive identity security strategy for Oracle. We unified SaaS identity by bringing Fusion Applications and Oracle Health and AI (OHAI) natively onto IAM. The resulting foundation supports Oracle’s own employee and operator access and gives security teams controls to help keep bad actors out of systems.

Today, the platform is available across all OCI regions and realms and serves billions of human and machine identities. The goal is to give each identity the right access at the right time and for the right duration. This blog follows how we unified that foundation, strengthened its security capabilities and put it to work inside Oracle.

Unifying Infrastructure and SaaS IAM

The enterprise starting point comprised Oracle Access Manager (OAM), Oracle Identity Federation (OIF), Oracle Identity Manager (OIM) and Oracle Internet Directory (OID). These provided the access, federation, lifecycle, provisioning and directory capabilities that anchored the move to cloud identity.

Cloud adoption extended those responsibilities beyond the enterprise environment. We introduced Oracle Identity Cloud Service (IDCS) to bring sign-in, federation, lifecycle management and provisioning into a cloud service. Its SCIM integration supported user and group synchronization across connected applications. The work that had mattered on premises still mattered in the cloud, with customers connecting accounts and access across more environments.

Alongside that change, OCI IAM was governing access to cloud infrastructure. Cloud identity established the user and supported application access; OCI IAM policies governed the actions an identity could perform on OCI resources. A person could sign in to an application and then request work that required infrastructure permissions. Customers increasingly needed these capabilities to work together.

Bringing those foundations together was a defining step in the journey. IDCS instances became IAM identity domains, preserving users, groups and security configuration. Identity domains brought authentication, lifecycle management, SCIM provisioning and application services alongside OCI IAM policies for infrastructure. We could now improve account management and access on a shared foundation while keeping the authorization responsibilities of applications and OCI resources clear.

Open standards connected each phase of this journey. SAML and OpenID Connect support federation and sign-in; OAuth supports delegated authorization; SCIM supports configured lifecycle integration; and FIDO2 enables passkeys. These standards-based identity interfaces give customers common integration patterns across enterprise and cloud environments, forming the basis for a comprehensive identity security strategy.

Adopting unified identity across infrastructure, SaaS, OHAI and AI workloads

The value of that foundation lay in the work it could support. Identity had to serve employees and consumers, practitioners and patients, workloads and AI agents. Their needs differed, but each needed a trustworthy connection between identity, permitted access and the service being used.

Infrastructure (OCI): For cloud infrastructure, the platform connects trusted identities with policies governing resource operations. Establishing who is acting and controlling what they can do belong in the same access path, whether the actor is a person or a workload.

SaaS/Fusion Applications(FA):Bringing Fusion Applications onto OCI IAM unifies authentication, SSO and MFA with the broader cloud identity foundation. Fusion Applications identity domains also support extensions and integrations, while application roles, provisioning workflows and data security continue to govern their respective responsibilities inside Fusion Applications.

OHAI (Oracle Health and AI):Native IAM integration extends the shared identity foundation into Oracle Health services. Oracle Health Clinical Data Exchange, for example, uses identity domains and scoped OAuth bearer tokens for API authentication. Practitioner and patient access must still fit the person, workflow and service involved; Oracle Health security connects those requirements with authentication, access and privacy monitoring.

Workloads / AI: Automated work made another kind of identity increasingly important: software. Workloads need credentials scoped to their execution. AI agents acting for people need delegated authority that remains connected to the person and the approved task. The identity foundation has to carry that context as work moves between them.

Across these environments, we wanted protection to follow the work: from creating an account to signing in, authorizing an action, evaluating risk and delegating to an agent. For users, those steps should let them get on with the task. For security teams, they should keep access governed and leave evidence of what happened. Workload identity federation extends that principle to software without relying on long-lived credentials.

Lifecycle management and provisioning: The journey starts before a user signs in. An account needs to be created, connected to applications and kept current as responsibilities change. Configured provisioning integrations can suspend or remove accounts when access is no longer needed. SCIM lifecycle automation helps automate those changes, supporting onboarding and reducing the risk of accounts remaining active after offboarding.

AuthN (Authentication): Once the account exists, sign-in is the first experience the user sees. OpenID Connect and SAML federation connect applications to a trusted identity provider, while single sign-on reduces repeated authentication across integrated applications. MFA adds verification, and FIDO authentication enables passkeys through security keys or platform authenticators. One-Click Sign-In with Passkeys also lets users access supported applications without entering a username. Stronger authentication can make access easier for legitimate users. 

AuthZ (Authorization): After sign-in, the requested action still needs permission. OCI IAM policies govern infrastructure access; identity-domain and application roles govern their respective boundaries; and OAuth scopes constrain delegated access. The receiving service enforces the permissions for the operation. This lets users complete authorized work while administrators control its scope.

ITDR:Sign-in context gives us another way to protect access. A suspicious IP address or an implausibly distant location calls for further evaluation. Risky IP and Impossible Travel signals inform Adaptive Access, so a configured policy can require another authentication factor or deny higher-risk access.

Customers can tune that response to their environment. Risk providers inform risk-based sign-on decisions, while Network Controls use network perimeters to restrict access from configured locations. These capabilities let customers respond to suspicious context while keeping permitted access straightforward.

Agentic security: Delegation extended the access journey from a person to an AI agent. MCP authorization capabilities include OAuth authorization-server discovery, PKCE, Client ID Metadata Documents (CIMD) and resource indicators. Consent identifies the access being approved, and identity propagation carries the user’s context to the receiving service.

That connection matters to the person using the assistant. Approved scopes limit what is delegated, and backend systems continue to enforce the user’s permissions. The assistant can help with the task while access stays bounded by the authority the user has and the access they approve.

Audit: The access journey also needs a record. Identity audit covers sign-in and administrator activity, while OCI Audit records supported API activity. Configured exports can feed a SIEM system, and Cloud Guard activity detectors can analyze supported tenancy events. These records help security teams investigate the activity behind a workflow.

For customers, the benefits come together across that journey. Configured lifecycle integrations help address stale accounts. Single sign-on reduces repeated authentication, and passkeys reduce dependence on reusable passwords. Roles, policies and scopes constrain access; risk controls support responses to suspicious sign-ins; and audit supports investigation. A shared identity foundation gives customers ways to improve security alongside the experience of using their applications and services.

Strengthening Oracle’s security with unified IAM

The same access challenges existed within Oracle. Employees needed to use applications, operators needed to maintain production services, and workloads needed to perform automated tasks. Applying the platform to our own environment made the connection between identity modernization and security tangible. Our internal deployment also includes Cookie Hijacking Prevention, Session Management and Device Trust; these three controls are currently internal to Oracle.

OAM migration:Our migration program moves application access toward OCI IAM identity domains. OAM and cloud identity federation supports coexistence as applications adopt cloud identity integrations and security policies. Migration carries employee access forward while creating a shared place to apply stronger authentication and access controls.

Passwordless access: That cloud foundation also supports our passwordless access program. Employees can use FIDO2 passkeys through security keys or platform authenticators, replacing reusable passwords with a cryptographic sign-in flow. The change connects a better sign-in experience with less dependence on credentials that can be reused.

Internal session security: Protection also follows the employee after sign-in. Within Oracle, Cookie Hijacking Prevention helps protect against replay of stolen session cookies, Session Management governs session lifetime, and Device Trust brings device context into access decisions. These controls address authenticated access beyond the credentials presented at the start.

Operator security and just-in-time access: Production operations added a further question about how much authority should be available and for how long. In the developer and operator AI workflows covered by Oracle’s AI transformation, access moved to just-in-time grants for approved work and a limited duration. Least-privilege reviews and human approval for sensitive actions added controls, reducing standing production authority available to an agent in the user’s environment.

Workload identity: Automated work needed its own move toward temporary access. Our autonomous code scanners previously used provider API keys. Scanners running in Oracle Container Engine for Kubernetes (OKE) could use runtime identity to obtain temporary model access, removing long-lived provider keys from their configuration. Separately, Workload identity federation supports self-managed Kubernetes clusters on OCI, exchanging service-account identity for temporary access to OCI resources.

Temporary access matters for OCI resource operations too. Ephemeral workload identity federation can issue a principal session informed by verified repository, workflow or service-account claims. Machine access can then be tied to execution context and scoped to the work it is performing.

AI transformation: For agents helping employees, identity needed to preserve delegated authority through the connection. In Oracle’s AI transformation, Enterprise ChatGPT used MCP connections to reach internal information under employee permissions. Consent limited approved scopes, and backend systems enforced access. The identity foundation helped us bring AI into work while keeping information access bounded.

As that work extends to operations, OCI resource policies and MCP security protect their respective boundaries. An applicable Deny policy can restrict an operation despite broader Allow permissions, and human approval remains subject to that restriction. Authority stays governed when software acts on a person’s behalf.

Identity assurance and biometrics: New ways of working also bring us back to the person behind an account. Identity Assurance at Oracle uses facial-biometric verification against an enrolled template, with liveness detection to help resist impersonation. Policies determine who is covered and how often checks occur.

This adds a different check from unlocking a passkey. In the FIDO authentication model, biometric verification happens locally at the authenticator, and IAM validates the cryptographic response. Identity Assurance adds verification of the person after authentication. Supported identity-verification providers can establish initial identity, and facial biometrics can also be configured separately.

Across the covered workflows, these changes have a practical security effect: removing long-lived provider keys, limiting the duration of privileged grants and preserving employee permissions when agents act. Internal session and device controls help address session misuse, while identity assurance adds verification of the person using an account. The platform we modernized for customers also gives us a foundation for protecting Oracle’s own work.

Oracle’s IAM modernization connects platform unification with stronger security across the access journey. Customers can manage accounts, simplify sign-in, constrain permissions, respond to risk and investigate activity across integrated services. Oracle applies the same foundation to employee access, production operations, workloads and AI. The goal is to carry identity, permitted authority and evidence through the work, so access remains governed as applications and ways of working evolve.