An authentication policy scenario for Okta FastPass
When you configure rules in an authentication policy, it's important to consider how those rules will affect device access to applications.
Example 1: device access is denied
In this policy, a device that is part of user group B is denied access if one of these conditions is true:
-
Silent device probing is not successful (this can occur when the Okta Verify service is not running in the background, trying to sign in to a Windows universal app like the native mail app, or when using an unmanaged iOS device)
-
Okta Verify is not installed (the device is not registered)
OR
Access is denied because only rule 4 is true.
Rule | User group | IF | THEN |
---|---|---|---|
1 | A | Require registered device, managed device | Allow with 1FA |
2 | A | Any device state | Allow with 2FA |
3 | B | Require registered device | Allow with 1FA |
4 | Catch all | Any | Deny |
In this situation, the device is allowed access if:
-
An administrator adds a new rule to the policy that allows User group B, with IF condition "Any device state", and THEN condition "Allow with 2FA".
-
The Okta Verify Sign in with Okta Verify button is used to sign in, instead of entering their username.
OR
Example 2: device access is allowed
In this policy, example 1 is modified. An additional rule was added for user group B that allows a device with any device state to obtain access. Rule 4 is true for this device, so it is allowed access.
Rule | User group | IF | THEN |
---|---|---|---|
1 | A | Require registered device, managed device | Allow with 1FA |
2 | A | Any device state | Allow with 2FA |
3 | B | Require registered device | Allow with 1FA |
4 | B | Any device state | Allow with 2FA |
5 | Catch all | Any | Deny |