Compare Identity Engine and Classic Engine

Some features in Identity Engine have a new user interface and are configured differently than in Classic Engine.

Authentication and policy changes

Identity Engine changes the definitions of authenticators and factors to provide an industry-standard differentiation:

  • Factors are different categories that define how authentication takes place and the means in which they are controlled by end users.
  • Authenticators are used to verify one or more multiple factors such as Knowledge, Possession, and Inherence/Biometrics.

See Multifactor Authentication.

The use of one or more authenticators and its characteristics determine an assurance level. Assurance is the degree of confidence that an end user signing in to an application is the same end user who previously signed in to the application.

Assurance is enforced by sign-on policies. Identity Engine requires that the assurance specified in the Okta and app sign-on policies is satisfied before it allows the end user to access an app. See Sign-on policies and rules.

Authenticator deactivation

An authenticator must be disabled from all policies before it can be deactivated at a global level. For example, if the Security Question authenticator is used in an MFA enrollment policy and a Group Password policy (for self-service password reset), it can't be disabled at the org level until it has been disabled from both policies.

OIDC app sign-on policies

App sign-on policy evaluation is different for OIDC apps.

If your OIDC app (web or single-page) is configured to Redirect to app to initiate login (OIDC compliant), its app sign-on policy isn’t evaluated immediately upon access. This is a change from Classic Engine, where an OIDC app’s sign-on policy is evaluated immediately when the user selects it. When Identity Engine users select an OIDC app, they are first redirected to the initiate login URI. Then, when the app issues an authorize request, the app sign-on policy is evaluated. Users are prompted for additional MFA after they’re redirected back to Okta.

See Create OIDC app integrations using AIW.

Expiry time of email links

Configuring the expiry of email links is handled differently in Identity Engine.

In Classic Engine, you configure email links, including expiry times, in two places:

  • In a password policy for self-service password reset conditions and times
  • In the Email Authentication factor under the Security > Multifactor menu for self-service account unlock and multifactor authentication

The default time for expiry is one hour.

In Identity Engine, you configure the expiry of email links for self-service password reset, self-service account unlock, and multifactor authentication in one place: the Email Authenticator under the Security > Authenticators menu.

The default time for expiry in Classic Engine is five minutes, and you can configure an expiry time in five-minute increments up to 30 minutes.

See Configure email authenticator.

Navigation changes

Some Classic Engine features have moved or been renamed in Identity Engine

Classic Engine

Identity Engine

Welcome Wizard The Welcome Wizard has been replaced with the Sign-In Widget.
Security > Multifactor Security > Authenticators. All authenticators (formerly referred to as factors) can be configured here, as well as the Password policy.
SecurityMultifactor > SMS Security > Authenticators > Phone. Configuring SMS or Voice enrolls users in a Phone Authenticator associated with the end user’s phone number.
SecurityMultifactorVoice Security > Authenticators > Phone. Configuring SMS or Voice enrolls users in a Phone Authenticator associated with the end user’s phone number.
DirectorySelf Service Registration Security > Profile Enrollment. Self Service Registration has been replaced by the Profile Enrollment policy.
DirectorySelf Service Registration > Default redirect SettingsCustomization > Default Application for Sign-In Widget. End users who sign in without a specific app in context, or recovered end users who perform password or MFA resets, go to this app redirect instead of the dashboard.
SecurityGeneralRemember me SecurityGeneralRemember user on sign in. The Remember me feature has been replaced by Remember user on sign in and Keep me signed in.

Sign-In Widget changes

End user enrollment now occurs entirely in the Sign-In Widget when the user attempts to sign in to their org or to a specific app. This allows you to customize the entire onboarding experience.

Identity Engine changes the Sign-In Widget in a few significant ways.

Security image

There is no security image in Identity Engine. Users aren't prompted to select a security image during activation.

Remember me

Remember me and Remember my device have been replaced by a single Keep me signed in checkbox.

In Classic Engine, Remember me serves two purposes. By default, it pre-populates the Username field on the Sign-In Widget. But admins can also configure it so that users' sessions continue after their browser is closed and reopened.

In Identity Engine, these features are separate. Admins can configure one or both in Security > General:

  • Remember user on sign in pre-populates the Username field on the Sign-In Widget for the lifetime of the browser window or until the user clears their cookies. Remember user on sign in doesn't keep the user signed in or store MFA preferences.
  • Keep me signed in enables a session that extends beyond browser lifetimes. It also remembers MFA authenticators from previous sessions. Keep me signed in keeps a user signed in for the amount of time defined in the Okta sign-on policy.

See Organization Settings.

  Classic Engine Identity Engine
Sign-In Widget Sign-in Widget - Okta Classic Sign-in Widget - Okta Identity Engine
Multifactor authentication Sign-in Widget - Authenticator - Classic Sign-in Widget - Select Security Method - OIE
Select an authenticator/security method Sign-in Widget - Select an authenticator - Classic Sign-in Widget - Select Security Method - OIE
Reset password Sign-in Widget - Reset Password - Classic

MFA enrollment

  • Identity Engine doesn’t distinguish between SMS and voice phone enrollment. When the Phone authenticator is enrolled, both methods may be activated.

  • If users skip enrolling any optional authenticators that can be used for account recovery, such as Phone, they will not receive periodic reminders to complete enrollment.

Related topics

Get started

Limitations

Typical workflow for configuring your org