Strategic considerations when deploying authentication policies
Authentication policies in Identity Engine are a great way to implement a holistic approach to Identity Access Management (IAM) that focuses on results and outcomes. Okta designed authentication policies to allow Okta administrators to operate at a higher level of abstraction by defining the context and user type depending on an application's requirements.
Key concepts and definitions
Authentication policies, along with Device Context and Okta FastPass, are a cornerstone of Identity Engine. When evaluating whether a user can be granted access, Identity Engine inspects the context (user itself, device, network, and risk) that the user brings, first at org level and then at app level. It then determines the authentication methods that will be offered based on both Global Session Policies and authentication policies.
Authenticators and authentication methods
An authenticator is a credential owned or controlled by a user, such as a secret phrase, an email account, or an instance of a downloaded app.
An authenticator can have one or more authentication methods. The following table lists authenticators and the authentication methods they offer.
|Phone||SMS or voice|
|Password||Secret string or phrase|
|Okta Verify||One-time password, push notification or proof of possession key, Okta FastPass|
Authenticators have a factor type. Factor types are something the user knows (knowledge factor), something the user has (possession factor), or something the user is (inherence factor).
The introduction of authenticators allows for the addition of specific security characteristics.
The Possession factor type supports the following characteristics. Each is valuable to achieve specific outcomes.
- 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.
- 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.
- Device bound: Requires that the factor's keys be stored securely on the device, and that they cannot be transferred 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 is selected.
Authenticator Assurance Levels
Authenticator Assurance Levels (AALs) are included in the National Institute of Standards and Technology (NIST)'s guidelines for digital identity. AALs define an app's level of confidence that the credential presented for access is truly in the possession of the person whose identity is being asserted to the app. For example, is the one-time password (OTP) or biometric information presented actually tied to the username entered for access?
NIST recommends three levels, expressed as AAL1, AAL2, and AAL3, that represent the strength of the authentication process and the binding between an authenticator and the user's identity. AALs define the characteristics of the authentication methods that need to be verified before a specific level of authentication is achieved, such as the number of factors presented or whether the factors are required to be phishing resistant.
Authentication assurance policies
When creating an authentication policy, the administrator can specify the combination of authenticators, authentication methods, and factor types that are required. This allows them to define the proper assurance level, including:
- How the user must authenticate, using one or two factor types
- Which constraints (specific characteristics required for the authentication method) should be applied to possession factors
- Whether access with Okta FastPass is allowed, and under which constraints (prompt or biometrics)
This constitutes the authentication assurance policy for the app to which the policy is applied.
When users present themselves to the authentication process, they bring a context with them. This context is a set of information and states about:
- The user, their groups (if any), and risk assessment attached to them
- The network the user is connected to
- The device the user is using
For a complete description of these aspects see the Device Context Deployment Guide.
Device Context is another cornerstone of Identity Engine. It provides maximum visibility on the information and state that the device presents to assess the authentication methods required to grant access to Okta-managed apps. Device Context is a superset of Device Trust. With Device Context, the Okta administrator has access to a rich set of data about the user's device:
- Context data and state for managed devices, also known as Device Trust. Device Trust in Identity Engine provides a unified approach for assessing the trust posture of desktop and mobile devices, including:
- Indication of whether the device is managed by a 3rd-party management tools
- Data or signals collected by 3rd-party EDR tools, such as whether a firewall or antivirus solution is present on the device
- Whether the device is registered in Okta Universal Directory
This information can be used to create sophisticated policies.
Global Session Policies and authentication policies
Global Session Policy is the first gate for policy evaluation. That policy includes the ability to delegate to the authentication policy for authentication method selection.
How global session policies and authentication policies work together
In Identity Engine, authentication requests for SAML and OIDC apps must meet the assurance requirements of both the global session policy and the authentication policy. The global session policy evaluates the user's global session, and the authentication policy evaluates the specific app's requirements. If a valid Okta session already exists, only the authentication policy is evaluated.
To understand how these concepts work together, review the following setup for an Okta tenant:
- Global session policy has a primary factor requirement of Any factor used to meet the Authentication Policy rules, has no secondary factor requirement, and has a session expiration of two hours.
- Application 1 authentication policy is set to Any 1 factor type / IdP and re-authentication frequency is set to two hours.
- Application 2 authentication policy is set to Any 2 factors types and re-authentication frequency is set to two hours.
- Application 3 authentication policy is set to Any 1 factor type / IdP and re-authentication frequency is set to one hour.
When the user tries to directly access Application 1, the global session policy is evaluated because an Okta session does not exist yet. Because Multifactor authentication isn't selected, the user is prompted only for a single factor, as defined by the requirements set on Application 1's authentication policy. The user can use any of their enrolled authenticators to satisfy Application 1 assurance requirements. For this example, assume they use their password.
Next, assume that the user tries to access Application 2 in the same browser window, immediately after accessing Application 1. Because Application 2 requires two distinct factor types, and because the user already supplied their password during the Okta session, they have to supply a different factor type (for example, Okta Verify Push) to satisfy the assurance requirements for Application 2.
Finally, assume the user has another session (for example, on a different device or browser) where they were able to access Application 1 using their password as a factor. If the user tries to access Application 3 after one hour of inactivity, they are prompted to re-verify with any of their enrolled factors, which includes password. This is true despite the fact that they already verified with their password previously in the session, because the authentication policy for Application 3 is shorter than the Okta session specified in the global session policy.
Before deploying authentication policies
These key considerations should shape your approach to implementing authentication policies:
- Applications: Some might be simple and have low security requirements (think about a portal to the company cafeteria). Others will have much higher security risks (financial transactions or intellectual property). It's a good practice to start with a simple model containing three assurance levels: low, medium, and high.
- Users: Put them into categories based on the intrinsic risk they bring to the organization. Employees might have different clearance levels. Some third parties might go through security screening, while others might not. These categories will be the foundation to create your user groups in Identity Engine.
- Devices: Consider the devices used to access applications. Personal devices or corporate devices are obvious cases. Also consider public devices and devices belonging to friends of an employee.
- Network requirements: Consider whether your users access your org from corporate network, a home network, or a public network.
- Authenticators and authentication methods: Consider which are available and can be enabled for your users. This consideration should include an assessment of the user experience you will deliver.
- User education: Users are the last line of defense. Giving them a basic understanding of the policies and the reason behind them will make them better supporters.
Defining your authentication policy strategy is a multi-dimensional exercise that requires rigor and attention to detail. The following example model illustrates a strategy to deploy app sign-on security to protect your applications.
Authentication policies are a paradigm shift in IAM for enterprise apps. Keep the following considerations in mind when articulating your strategy, and before deployment:
- IAM is the last line of defense before accessing applications or resources. When designing policies, consider the first lines of defense such as your ISP, routers in your corporate network, and firewalls. The context presented by a user might already have been filtered by other defenses such as IP address ranges or geolocation. However, in a zero-trust scenario, you should assess the context within the policy itself.
- Global session policies supply the context necessary for the user to advance to the next authentication step. They also specify actions to take, such as allowing access, prompting for a challenge, and setting the time before prompting for another challenge. When configuring how frequently users will be prompted for MFA, be aware of how the options support other conditions like Risk and Behavior:
- When signing in with a new device cookie: This option reduces MFA for a group of users. Because it allows users to bypass MFA if they appear to be signing in from the same device (based on a browser cookie), it's only appropriate for low-risk, low-assurance use cases. It shouldn't be used with behavior conditions.
At every sign in: This option prevents users from controlling their own MFA prompts. This option is suitable for use with behavior conditions, which detect high-risk sign-in events.
After MFA lifetime expires for the device cookie: This option means that users aren’t challenged again for MFA for the duration of their session unless an app's authentication policy requires it. You can set both a factor lifetime and a session expiration, but be aware that MFA lifetime is only enforced when a new session is created or if the user changes devices. Per session is only appropriate for low-risk, low-assurance use cases and shouldn't be used with behavior conditions or risk conditions.
- Make sure you thoroughly understand the global session policy to authentication policy flow. If you choose to delegate to Any factor used to meet the Authentication Policy rules, pay extra attention to the authentication policy. For example, if the authentication policy is set to Any 1 factor type and email is enrolled as an authenticator, then the user will have access granted with a simple magic link email.