Compare Identity Engine and Classic Engine
Some features in Identity Engine have a new user interface and are configured differently than in Classic Engine.
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.
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.
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.
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.
Some Classic Engine features have moved or been renamed in 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.|
|Security > Multifactor > SMS||Security > Authenticators > Phone. Configuring SMS or Voice enrolls users in a Phone Authenticator associated with the end user’s phone number.|
|Security > Multifactor > Voice||Security > Authenticators > Phone. Configuring SMS or Voice enrolls users in a Phone Authenticator associated with the end user’s phone number.|
|Directory > Self Service Registration||Security > Profile Enrollment. Self Service Registration has been replaced by the Profile Enrollment policy.|
|Directory > Self Service Registration > Default redirect||Settings > Customization > 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.|
|Security > General > Remember me||Security > General > Remember user on sign in. The Remember me feature has been replaced by Remember user on sign in and Keep me signed in.|
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.
There is no security image in Identity Engine. Users aren't prompted to select a security image during activation.
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.
|Classic Engine||Identity Engine|
|Select an authenticator/security method|
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.