1 Introducing Oracle Advanced Authentication

Oracle Advanced Authentication (OAA) is a standalone microservice that can be used by applications to establish and assert the identity of users.

1.1 About Oracle Advanced Authentication (OAA)

Oracle Advanced Authentication (OAA) is a standalone micro-service that supports establishing and asserting the identity of users. It provides a comprehensive solution that is simple to deploy and use.

OAA provides strong authentication using Multiple Authentication Factors (MFA). A wide range of authentication (challenge) factors are available out-of-the-box for establishing the identity of users.

It supports integration with Oracle Access Management (OAM) and Oracle Radius Agent (ORA) to provide MFA capabilities.

1.2 Features of Oracle Advanced Authentication (OAA)

Oracle Advanced Authentication (OAA) constitutes unique features that facilitate deployment, configuration, and integration with other products.

Following are the features of OAA:

  • Runs as a standalone micro-service on a Kuberenetes platform and is deployed using Helm charts.
  • Supports integration with the following clients to enable Multi-factor Authentication (MFA):
    • Clients providing web-based user login flows, such as Oracle Access Management (OAM). OAA integrates with OAM through Trusted Authentication Protocol (TAP).
    • Clients providing API-based user login flows, such as Oracle Radius Agent (ORA). OAA integrates with ORA through REST APIs. This type of integration enables clients to manage its own user-flow orchestration.
  • Provides OAAAuthnPlugin for integrating with OAM. The plugin also enables migration of user data from the identity store on OAM to OAA.
  • Provides web UI (admin UI console) for administrators to create and manage client registrations, assurance levels and policies. Administrators can also achieve all the administration tasks using REST APIs.
  • Provides web UI (user preferences UI) for end-users to manage and register their challenge-factors. User self-registration and management can also be performed using REST APIs.
  • Web UIs are secured by OAM OAuth and OIDC.
  • Provides the following challenge-factors out-of-the-box:
    • TOTP (OMA, Google, and Microsoft)
    • OTP (E-MAIL and SMS)
    • Yubikey OTP
    • FIDO2

1.3 System Architecture and Components

OAA consists of multiple components that run as micro-services on a Kubernetes cluster, managed by Helm charts.

OAA is composed of micro-services, web applications, platform abstractions and authentication factor providers along with an RDBMS used for storing user preferences and service data/metadata.

The following system architecture shows the main components that make up OAA:

Clients that integrate with OAA and the external data storage are shown outside the OAA boundaries in the system architecture. Also the other components that are outside of OAA, such as the load balancers, event data viewers, K8s environment hosts, and so on are not shown in the system architecture.

OAA Runtime and API

This component is the main processing unit of the system and provides REST APIs for managing user challenge flows and orchestrating the flow using challenge factors.

This runtime component integrates with API-based clients, for example, Oracle Radius Agent (ORA).

OAA Runtime UI

This component provides User Interface (UI) pages for managing user challenge flow. For the end-user, it provides user interface for choosing challenge, going back and forth with challenge factors during the flow.

This runtime component integrates with clients running browser-based flows, for example, Oracle Access Management (OAM), using OAuth and OpenID Connect (OIDC).

It provides the following UI Pages:

User Challenge Choice Pages: This renders the available challenges for users to choose from. It also provides an option to remember the choice the next time. After user chooses the challenge, it redirects to the User Challenge Answer Page.

User Challenge Answer Pages for factors: Challenge answer page retrieves the answer from the chosen second factor specified by the user. Based on the type of challenge, the page provides dialog box to type the answer in, for example, for factors Email, SMS, and TOTP. If the challenge factor requires an assertion outside the browser, for example FIDO2 and Yubikey, the page renders a timed wait. If verification fails it asks for the answer again, or sends back the user to choose another challenge, or timeout. If verification succeeds users are redirected back to the agents.

This page also allows the user to abandon the flow or go back to the challenge choice page.

OAA Policy Admin UI and API

This component provides REST APIs and admin UI to manage agents, assurance levels, policies and groups. Policies are defined for each client. Administrators can configure required challenge outcomes with the REST APIs or UI.

Self-Service UI and API

This component allows the end-user to see and manage their challenge factor registration using UI or the user-preferences REST APIs.

Challenge Factors

Challenge factors are realized as service or containers that integrate with OAA runtime using REST API or UI. Challenge factors can be configured using the configuration API.

Persistent Store

This component is used for storing user preferences data and policy metadata. OAA supports database installation external to the Kubernetes cluster and provides the database schema to be imported.


Data monitoring is enabled for OAA service and policy management API.

1.4 Understanding Oracle Advanced Authentication

Following is the terminology used in OAA:


In OAA, the clients that integrate with OAA are referred to as agents. The integration can be either REST-API-based, for example, Oracle Radius Agent (ORA) or browser-based through TAP, for example, Oracle Access Management (OAM).

Agents can be registered with OAA and managed through Admin Console UI.

Assurance Level

Assurance Level indicates the level of assurance that is needed by the agent. It is a key to contract between the agent and OAA that enforces the policy to be run for the user-login-flow. OAA runs the linked policy for that flow and determines Multi Factor Authentication (MFA) orchestration.

Assurance Levels can be defined to closely align with the NIST recommendations. However, this is not mandatory and Assurance Levels can be named in a reader-friendly way.

An agent can be assigned with multiple Assurance Levels, however, an Assurance Level can be associated with only one agent. Following are some examples of Assurance Levels:

  • The Radius agent can define an Assurance Level named Radius_DB12_AL to indicate that the agent manages users from DB12 client
  • OAM Server can define an Assurance Level named OAM_AuthLevel6 to indicate that the resources are protected at auth-level 6 with OAM.
  • OAM Server can define an Assurance Level named PasswordLess1 to indicate that the resources are protected by a Passwordless scheme.

Challenge Factor

A Challenge Factor presents a challenge to the user and verifies if the user has correctly provided the expected input.

OAA supports the following factors out-of-the-box: Email, SMS, Time based PIN (TOTP), Fido2, and Yubikey.


Policies are based on rules. Each agent can have multiple assurance levels, and each assurance can have a policy with multiple rules in it. Each rule can have its own outcome of factors.

Rule: A Rule is an expression that contains attributes of user, such as UserID, IP address, and so on combined with conditions. At run time the actual values are substituted in this expression and the rule outcome as group of actions is calculated.

Conditions: Conditions are expressions that compare the attributes with operators like equals, not equals, in group, and so on based on the context