Authentication method chain

Early Access release. See Enable self-service features.

When you add an authentication policy rule, you can create an authentication method chain. This requires users to verify with multiple authentication methods in a specified sequence. You can create multiple authentication method chains in the rule to accommodate different use cases and scenarios.

How it works

In an authentication policy rule, you can specify which authenticators a user must authenticate with to access an app. Each authenticator fulfills certain factor type and method requirements as described in Multifactor authentication. You can require users to verify with multiple authenticators to meet your assurance requirements.

With the Authentication method chain option, you can set the order in which these authentication methods are prompted to the user. This gives you more granular control over how the users authenticate into an app.

  • Specify the sequence of authentication methods: You can specify the order in which authentication methods are prompted to the users. For example, require users to first authenticate with a possession factor, such as a one-time passcode (OTP) on their phone. Then require a biometric factor such as Okta Verify with biometric user verification. Or when accessing sensitive apps, require them to authenticate with two phishing-resistant authenticators such as first with WebAuthn then with Okta FastPass.
  • Specify method characteristics for authenticators: For authenticators that have different characteristics depending on the method, you can specify which method characteristic is required. For example, require user interaction for Okta FastPass or require a hardware-protected Smart Card.
  • Specify multiple authentication method chains: You can customize the authentication method chain for different scenarios or to provide users with multiple starting authenticators. For example, offer password and Okta Verify as the first authenticators from two different chains. If the user authenticates with a password then require FIDO2 (WebAuthn) as a second authenticator. If they authenticate with Okta Verify then require Google Authenticator as a second authenticator.
  • Specify multiple authentication methods in a single step: You can customize each step of the chain to offer multiple authentication methods. The user can verify with any of these methods to progress to the next step. For example, allow password or phone OTP as the first authenticators and then require FIDO2 (WebAuthn) as the second authenticator in a single chain.

Set up an authentication method chain

  1. In the authentication policy rule, go to the User must authenticate with dropdown menu and select Authentication method chain.

  2. Specify the first authentication method. Repeat this step to add multiple methods at this level.

    1. In the First authentication method dropdown menu, select an authentication method.

    2. Depending on the authenticator, these options related to method characteristics may appear:

      • Phishing resistant

      • Hardware protected

      • Require user interaction

      • Require PIN or biometric user verification

      Select the required characteristics for the method.

    3. Optional. Click + Add to add another first authentication method.

  3. Specify the next authentication method in the chain. Repeat this step to add more authentication steps.

    1. Click Add step to add the next authentication method in the chain.

    2. If available, select the required factor constraints for the method.

    3. Optional. Click + Add to add another authentication method at this level.

  4. Optional. Click Add authentication method chain to add another authentication method chain. Repeat the above steps to add authentication methods in the chain.

  5. In Prompt for authentication, specify how often the user should be prompted for authentication. This is also called the reauthentication frequency.

    • Every time user signs in to resource: Users must authenticate every time they try to access the app. This is the most secure option.

    • When it's been over a specified length of time since the user signed in to any resource protected by the active Okta global session: Users are prompted to authenticate when they exceed the time interval you specify.

    • When an Okta global session doesn't exist: Users are prompted to authenticate if they never established an active Okta global session.

  6. Click Save.

To remove an authentication method or chain, click the X button for the corresponding method or chain.

End user experience

When the user tries to access the app, they're prompted with the first authenticator you've specified in the authentication method chain. After they successfully complete this prompt, they're prompted with the next authenticator in the chain. When they successfully complete all the authenticator prompts in the chain, they're allowed access to the app.

If you've specified multiple authentication chains for an app, all of the first authenticators from these chains appear as options on the user's authentication page. The user selects one of these authenticators and completes the prompt. Depending on the first authenticator they choose, the corresponding authentication method chain is triggered. After they successfully complete the first authenticator prompt, they're prompted with the next authenticator in that chain. When they successfully complete all the authenticator prompts in the chain, they're allowed access to the app.

Sometimes, the user has already authenticated using one of the first authentication methods for another activity, such as signing in to Okta or another app, or resetting their account or password. If this authentication prompt is within the reauthentication frequency window, they're directly prompted for the next authentication method in the corresponding authentication method chain.

If the user had previously authenticated using any of the first authentication methods, they're by default presented with the same method on their next sign-in attempt. They can use the Back to sign in or Verify with something else options to choose a different first authentication method.

If the Global Session Policy requires a password, the users are first prompted for the password. After they provide the correct password, the authentication method chain for the app is triggered. Similarly, if User Enumeration Prevention is enabled, the user must first verify with a password or email on an unknown device regardless of the authentication method chain setup.

If Identity Threat Protection is enabled in the org, the order of the authentication methods isn't enforced for Post auth session evaluations. If the user has successfully verified using the authentication methods for the applicable rule during the Post auth session evaluation, the session is marked compliant.