Factor Sequencing on OIE: Authentication Method Chains

When OIE was released it championed assurance levels rather than specific authenticators. This provided a better experience for the majority of users and administrators. This ease of use came at the cost of easily being able to specify specific factors or factor orders which some customers required typically for compliance or regulatory reasons. Many of these scenarios could be addressed via the Policy API at OIE launch as I wrote about in my first ever post here: Choosing Specific Factors in OIE with the API. Unfortunately, while this satisfied the need of some power users it didn’t solve all authentication scenarios. Okta has now addressed this gap with the release of Authentication Method Chains.

With the Authentication method chain option, you can set the order in which 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.

Setting up an Authentication Method Chain

The steps to set up an Authentication Method chain are straightforward.

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.
   • In the First authentication method dropdown menu, select an authentication method.
   • 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.
   • 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.

Below is an example policy that requires FastPass with user verification and then Verify Push and then a FIDO2 (WebAuthN) authenticator. This may be a desired target state where you require strong phishing resistant authentication on a computer with a second device.

You can also present the user with additional method chains by adding another method chain and repeating the above steps. This allows users to start with any of the First Authentication Methods listed in any chain. Users are only given the option to chose between first authentication methods to initiate the authentication chain. An authentication method can be used in multiple chains however it can only be the First Authentication Method in one chain.

Note: If you are not presented with the option to use an Authentication Method Chain you may need to enabled self-service features.