Okta Identity Engine (OIE) is the latest upgrade of our leading identity and access management platform. OIE is a significant step in the evolution of our SaaS solution: it provides a strong foundation that makes it easier to create outcome based policies for all your applications. In addition, OIE unlocks new scenarios such as Passwordless authentication and Zero Trust. Furthermore, OIE comes with a number of new features such as Device Context, Flexible Account Recovery just to name a couple.

In this series of blog posts, we will take a practical approach to upgrading from Okta Classic to OIE to unlock its full potential. We want you to be able to determine the level of effort needed for your environment and be comfortable with the overall experience throughout this quick journey.

First, the subject of this post, we will cover some of the fundamentals of the framework, such as assurance levels and the new policy framework, starting with the vocabulary. In future posts, we will explore new security improving capabilities, like Fastpass and Device Context, as well as broader subject areas like Zero Trust and what a full end to end Passwordless experience would be.

Okta OIE offers a new approach to security policies that is based on defining the desired security outcomes, these are identified as “assurance models” and use an application-first authentication approach. We will dive into the why and then we will cover the differences with Okta Classic.

But first, let’s cover the new vocabulary introduced by OIE.

New vocabulary

In Okta Classic, as an administrator, you are used to the traditional IAM terms: authentication, password, sign-on, factors and MFA. While these are still in essence applicable, they do not align with the more latest standard-based definitions.

In OIE, we have been aligning to a more rigorous vocabulary, which is also consistent with industry standards such as NIST.  

For example “Authenticator Assurance Level [AAL]”, “assurance_level ”, “attestation”, “identifier”, etc

Authenticators & Authentication Methods

In Classic, we use the term “factor”. In OIE, factors are replaced by “authenticator”.

An authenticator is something that your user possesses and has control of (a password, a security question, an authenticator App such as Okta Verify or Google Authenticator, a Ubikey, etc) really any object or data structure that authoritatively is bound to an identity. Authenticators have one or several authentication methods which satisfy different factor types (see next section). 

For example: 

• A password as an authenticator as only one authentication method, the password string itself. 
• An authenticator App can have several authentication methods such as a TOTP or a push notification.
• Authenticators can even be layered with multiple methods

Factor Types and True MFA

Factor types are the cornerstone of true Multi-Factor Authentication (MFA) outcome. There are defined into three factor types:

• Possession factor type - something that you hold physically or “possess”, like a phone
• Knowledge factor type - something that you hold in memory or “know” like a password or even the secret answer to a security question
• Inherence factor type - something that you are physically very unique, to your person commonly referred to as “Biometric”, like a fingerprint or facial scan

According to common security standards, true MFA is defined as a combination of two authentication methods of different factor types. 

Note that as a result:

• A password (knowledge) PLUS an answer to a security question (knowledge) is not true MFA
• A password (knowledge) PLUS a TOTP (Possession) is true MFA
• Okta Verify on a mobile phone with biometrics is true MFA in a single App as it combines a possession factor type (the App on your device) with and inherence (your biometrics)

Note: Device Assurance/Management/Trust are NOT considered a “possession factor type“ for authentication; it is just an additional layer of context that can be added to the wider security outcome posture.

Advisory: SMS and Voice are both considered the SAME “factor type”, this is because the same level of possession is required to answer a voice call as it is to read the text message. It is just the delivery modality used in the challenge response flow.

Assurance Model

Assurance is defined as the degree of confidence that your organization meets its security requirements. In simple terms, how confident are you that a certain individual is who she/he says he/she is. This correlates to the degree in which the credential can be taken/stolen from the user.

Assurance is achieved by using authenticators (who provide authentication methods as covered in the vocabulary section), and relying on one or more factor types (MFA).

An assurance model is usually achieved by creating several ‘tiers’ based on the criticality or security requirements of specific apps. For each tier, a specific combination of authentication methods (and their factor types) can be selected depending on the security requirements.

Here is an example of an assurance model with three classification tiers: low, medium & high.

In a future post, while not part of the Authenticator Assurance model, we will enhance confidence by adding the concept of Device Assurance, which brings the context (type, OS, personal or managed, etc) of the device into the picture as well. This can even extend further into who “owns/manages” the device when we leverage “Device Trust” together with a device management solution.

Since the assurance is dependent on the information accessed within the applications, this model puts the applications at a central point in your authentication strategy, This is referred to as “application-first authentication”. 

Note: Because of this app foundation, even though OIE can can manage policies across multiple applications, it is still commonly referred to as an “application-level policy”

Combined with Authenticators and Authentication Methods, this framework is very powerful and flexible.

OIE Authenticators List

Application-first Authentication and the anatomy of an OIE Sign-in Policy

Conceptually there are always 2 levels of challenging Sign-in Policies: “Global” & “Application”; The global applies to all applications, whilst the application is only applied when the application is accessed. 

In Okta Classic, you create a password policy, a sign-on policy, and then you can turn on MFA and tweak it with different factors and sequences to meet your security requirements.

OIE simplifies this logic and yet has made a more sophisticated and flexible model based on a global session policy and authentication (application) policies:

• the Global Session Policy: this policy is evaluated first and acts as a gateway. At this level, you can decide if a password is always required system wide to authenticate or if this decision is delegated at the application level
• If the Global Session policy delegates to the app-level policy, then the authentication policy where the app is categorized is evaluated.
• The Application Authentication Policy: is an app-level policy in which the administrator specifies a required level of assurance. OIE automatically determines the required authentication methods and prompts the end user accordingly, this is fundamentally different from factor sequencing: you do not need to worry about the order in which the challenges are completed, OIE does that for you. Note that an authentication policy can be applied to several apps.

Global Sign In Policies

Below is a screen capture that shows how the global sign-on policy materialises in OIE. 

In this example, OIE will behave very similarly to Okta Classic by enforcing a password and MFA. Depending on the needs, administrators can still have a blanket “global MFA policy” and not offer any refinement for applications. 

However, the direction for many is to have a few classifications of applications and the respective assurances they need, requiring the ability to raise and lower the assurance based on the application classification (like above). Below is what the policy will look like.

Application level policies

Every Application in OIE has been assigned to an authentication policy, once the end user has passed the global session policy, the app-level policy is evaluated. OIE authentication policy framework offers a more abstract approach to creating policies, if you look at the THEN clause in the policy, you will see that you have a specified assurance level (and related parameters).

Extract from an OIE app-level policy

In the “User must authenticate with” field, you will just specify the factor types you require, “Any 2 factor types” in our example above. OIE will conveniently display the authenticators and authentication methods (based on the authenticators you have made available) that will satisfy the policy, very useful for sanity checks.

Note that Okta offers the following possible assurance levels:

• 1 factor type
  • Password
  • Possession factor
  • Any 1 factor type
• 2 factor type
  • Password + another factor
  • Any 2 factor types

You should now start to envision how to make all this work together for the simple example of three assurance levels we presented earlier.

In the second part of this OIE Fundamentals blog post we will look out to implement a basic assurance model practically in OIE.