Factor Sequencing FAQ
What is Factor Sequencing?
In Classic Engine, this feature allows end users to sign in to their org by authenticating with a series of MFA factors in place of a standard password. This is a way of delivering a passwordless experience based on login context. Admins can sequence one or more factors in an authentication flow.
How do I know if Factor Sequencing is enabled in Classic Engine orgs?
In the Admin Console, go to Security > Authentication. On the Sign On tab, select a rule and click Edit. See the Factor Sequence option in the Authentication methods section.
How can I verify if Factor Sequencing is used in my orgs?
Review the sign-on policy for each org.
To view a policy, perform the following steps:
In the Admin Console, go to Security > Authentication.
On the Sign On tab, select a rule and click Edit.
- If the Factor Sequencing feature is enabled but there are no active chains, either Password / Any IDP or Password / Any IDP + Any factor option is selected in the Authentication methods section.
- If Factor Sequencing is enabled and there are active chains, the Factor Sequence option and a factor sequence chain are selected in the Authentication methods section.
After the upgrade, can I use Factor Sequencing to display the Okta username on the initial sign-in screen in an identifier-first flow?
Yes, after the upgrade, you can directly see the identifier-first experience. You no longer need to create an IDP routing rule with a placeholder domain.
After the upgrade, can I use Factor Sequencing to allow users to authenticate with any factor except password?
Yes, after you upgrade to Identity Engine, perform the following steps on the applications that require single factor passwordless authentication.
Switch to an identifier-first flow in the global session policy. Before you switch, carefully consider all implications of switching to an identifier-first flow from a password-first flow.
Create an authentication policy that allows users to authenticate with possession factors.
- In your Identity EngineAdmin Console, go to Security > Authentication Policies.
- Create an authentication policy called Passwordless Authentication.
- Create a rule called Single Factor Passwordless Authentication.
- From the User Must Authenticate dropdown, select Possession Factor. This results in the same behavior because the users in this group can now authenticate with any possession factors except password.
After you create the authentication policy, associate it with your applications. See Authentication policies.
After the upgrade, can I use Factor Sequencing so that users authenticate with a password and another factor?
Yes, after upgrade to Identity Engine, perform the following steps on the applications that require a password and another factor for authentication.
- Switch to an identifier-first flow in the global session policy. Before you switch, carefully consider all implications of switching from a password-first flow to an identifier-first flow.
- In the Admin Console, go to Security > Authentication Policies.
- Create an authentication policy called Password + Another Factor.
- Assign this rule to a group.
- Select Password/IDP + Another factor.
After the upgrade, can I use Factor Sequencing to restrict the factors that a user can authenticate with?
Yes, you can do this in a limited way in Identity Engine by applying constraints on possession factors.
- Switch to an identifier-first flow in the global session policy. Before you switch, carefully consider all implications of switching to an identifier-first flow from a password-first flow.
- Create an authentication policy with possession factor constraints.
Method characteristic Description Examples Device-Bound The device key or secret is stored on the device and can’t be transferred to another device without re-enrolling. All possession authenticators except for Email and Phone. Hardware-Protected An authenticator that provides hardware protection of secrets or private keys. The device key is stored on a separate device, in the Trusted Platform Module (TPM), in a secure enclave, or on a separate hardware token, such as RSA SecureID. Hardware protection isn't provided by all types of devices. Okta Verify proof-of-possession key Phishing-Resistant An authenticator that cryptographically verifies the login server. WebAuthn User Presence The user proves they have control of the authenticator by actively authenticating (interacting with the authenticator, such as touching a YubiKey or entering a one-time password) and demonstrates their physical presence. Every method except an Okta Verify verification signed by a proof-of-possession key.
If you need to restrict authenticators to specific factors, you can use the APIs for shareable authentication policies. See Constraints default example.
After the upgrade, what should I consider before I switch to an identifier-first flow from a password-first flow?
After the upgrade, keep the following considerations in mind.
- When you upgrade to Identity Engine, your existing Okta sign-on policies become global session policies with password-first flows. If you add a new global session policy after you upgrade, it uses the default any factor used to meet authentication policy requirement flow.
- The end-user experience in password-first flow is different.
- On the Sign-In Widget, end users now see the following changes:
- The security image is removed.
- The Don't Prompt or Remember me checkbox is replaced with a Keep me signed in checkbox.
- More assistance options are available for signing in.
- Authenticators are now listed on the Sign-In Widget instead of being nested inside a dropdown menu.
- Out-of-the-box support is available for two types of CAPTCHA and for social login.
- The end-user experience in identifier-first flow is different.
- If the user session is established with any factor used to meet the authentication policy requirements, the username prompt appears first. This is called an identifier-first flow.
- You must switch to the identifier-first flow in the global session policy to use any of the new functionalities unlocked by Identity Engine, such as Okta FastPass, Device Trust 2.0, CAPTCHA, Email Magic Link, profile enrollment. After you switch, here's what the end-user experiences:
- The end user goes to your sign-in page.
- The Sign-In Widget displays a Username field.
- The end user enters a full username, including the domain.
- Optionally, the end user selects Keep me signed in.
- The end user clicks Next.
- The Sign-In Widget displays the security methods allowed by your sign-on policies.
- The end user selects a security method and completes the verification step.
- The end user accesses the application.
- The end-user experience in identifier-first flow with biometrics is different.
- If your sign-on policies allow a biometric authenticator, the Sign-In Widget shows an identifier-first page with Okta FastPass optimized.
Here's what the end-user experiences:
- The end user goes to your sign-in page.
- The Sign-In Widget displays two options: Sign in with Okta FastPass and the Username field.
- If the end user selects Username, they continue through the steps of the identifier-first flow.
- If the end user selects Sign in with Okta FastPass, they’re automatically authenticated through their device enrollment.
- Embedded SDKs/ Embedded Widget compatibility
- Identity Engine is backwards compatible. Therefore, all apps continue to work (redirect/embedded/Direct APIs).
- After the upgrade, the authentication policy defaults to password-first so the custom sign-in pages continue to work.
- If you want to adopt the new features like Passwordless or Device Context 2.0, you need to change the authentication policy to enable them. You might also need to upgrade the custom sign-in pages for these apps that need the new features to use the new SDKs.