Add behavior condition in an authentication policy rule
Authentication policies enforce end user authentication in the context of the requested application. Configure behavior conditions in authentication policies using Expression Language.
Before you begin
- Create a new or use an existing authentication policy.
- Adaptive MFA must be enabled.
- Ensure that no more than 10 conditions are included in a heuristic.
- The Expression Language for Security Context supports a subset of operators such as:
- ||, OR
- &&, AND
- !, NOT
- ==
- !=
For more information, see Okta Expression Language Overview.
Start this task
-
In the Admin Console, go to .
-
Select the authentication policy that you want to add a rule to.
-
Click Add rule page.
-
Type a Rule name to describe the rule.
-
Configure the appropriate IF conditions to specify when the rule is applied.
In setting conditions, keep in mind that some conditions are primarily useful for auditing and filtering events and shouldn't be treated as the basis for defining your security posture.
For example, a malicious actor could easily spoof a device platform, so you shouldn't use the device platform as the key component of an authentication policy rule.
-
Configure the appropriate THEN conditions to specify how authentication is enforced.
-
Configure the re-authentication frequency, if needed.
-
Click Save.
- Configure IF conditions. These conditions specify when the rule is applied.
IF Description IF User's user type is Accept the default or specify user types to include and exclude. AND User's group membership includes Accept the default or specify user groups to include and exclude. AND User is Accept the default or specify users to include and exclude. AND Device state is Accept the default or select Registered to apply this rule only to devices enrolled in Okta Verify. See Device registration. AND Device management is If you selected a Registered device state, indicate whether the rule is applied to only devices managed by a third-party device management solution. AND Device assurance policy is If you selected a Registered device state, you can specify device assurance policies to be satisfied. See Add a device assurance policy. AND Device platform is Accept the default or select specific platforms. AND User's IP is Accept the default or specify network zones that you want to include or exclude. You can sort by zones defined or not defined in Okta, or by dynamic zones. AND Risk is By default, this rule applies to authentication attempts of any risk level. Selecting a level limits the rule to only the specified risk level. See Risk scoring. AND The following custom expression is true Optional. Specify additional conditions with Expression Language (EL). See About behavior and sign-on policies and Okta Expression Language. - Configure the THEN conditions. These conditions specify how authentication is enforced.
THEN Description THEN Access is Deny the user's access or allow it after successful authentication. If you deny access, skip to the last step to save your rule. AND User must authenticate with Choose the authentication requirements that you want to enforce for app access. For a description of factor types, see Multifactor authentication.
1 factor type: To enable one-factor authentication, choose from:
- Password requires users to enter their password every time the rule requires re-authentication.
- Possession factor requires users to provide a possession factor such as Okta Verify or email to access the app.
- Any 1 factor type allows users to provide any single factor to access the app.
- For one-factor passwordless authentication options, see Set up passwordless sign-in experience.
- Password + Another factor
- Any 2 factor types
- For two-factor passwordless authentication options, see Configure Okta FastPass.
AND Possession factor restraints are These options aren't available if only Password is selected in User must authenticate with. Use these settings to specify possession factor characteristics. - Phishing-resistant: Requires users to provide possession factors that cryptographically verify the login server (the origin). Currently, only FIDO2 (WebAuthn) satisfies this requirement. Because phishing resistance implies Device bound, that constraint is selected automatically when Phishing-resistant is selected.
- Hardware protection: Requires that keys being used to authenticate are stored in secure hardware (TPM, Secure Enclave) on the device. Currently, only Okta Verify meets this constraint. Because hardware protection implies Device bound, that constraint is selected automatically when Hardware protection is selected.
By default, Okta Verify attempts to store the Okta Verify keys on the secure hardware of the device: trusted platform module (TPM) for Windows and Android devices, or Secure Enclave for macOS and iOS devices. If secure hardware isn't available, software storage is used. When software storage is used, Okta Verify doesn't satisfy the app sign-on policy if Hardware protection is selected as an AND Possession factor restraints are THEN condition. To identify how Okta Verify keys are stored for a device, view the
secureHardwarePresentdevice attribute in the Admin Console, or use an Okta Expression Language (EL) expression to determine the value ofdevice.profile.secureHardwarePresentview. If this value is true, secure hardware is used. See Okta Expression Language and View device details. - Device bound (excludes phone and email): Requires the factor's keys to be stored securely on the device and aren't transferable to another device without re-enrolling the factor. Email and SMS are the only possession factors that aren't device-bound. This constraint is selected automatically if either of the other constraints are selected.
AND Access with Okta FastPass is granted These options allow you to choose whether to require end users to prove that they're physically present when using Okta FastPass to authenticate. - If the user approves a prompt in Okta Verify or provides biometrics (meets NIST AAL2 requirements): This option requires users to prove that they're physically present.
- Without the user approving a prompt in Okta Verify or providing biometrics: If you select this option and the app sign-on policy requires a possession factor, Okta Verify may perform certificate-based authentication thatallowsallows users to access the resource without proving that they're physically present. This option doesn't meet NIST AAL2 requirements. Also, if you select this option, you won't be able to use Security Question as an additional factor.
Re-authentication frequency is This setting allows you to specify how often end users are required to re-authenticate. - Every sign-in attempt: Users must re-authenticate every time they try to access the app.
- Never re-authenticate if the session is active: Once users authenticate from their device, they aren't prompted to authenticate again until either the maximum session lifetime is reached or they sign out of Okta.
- Re-authenticate after: Specify how often end users are required to re-authenticate. Users are prompted to re-authenticate only if they try to access the app and haven't re-authenticated within the time interval you specified and their session hasn't expired.
A 10-second grace period applies after a user authenticates with their password. During this grace period, users aren't prompted for their password again if Every sign-in attempt is selected.
Password re-authentication frequency is These two options appear only when Password + Another Factor is selected. They allow you to specify a different re-authentication interval for the password and the other factor. For example, you might want to require users to re-authenticate with their password if it has been more than eight hours since they last authenticated, and with a possession factor every time they access the app. Re-authentication frequency for all other factors is - Click Save.