The Complete Guide To Okta Authentication Policies

Here it is – everything you need to know about using Okta’s Authentication Policies to enhance your identity security posture.

Okta is a leading independent cloud identity provider. It helps you manage user identities, synchronize legacy or on-premises identities to the cloud and provides single sign-on (SSO) access to both Infrastructure-as-a-Service (IaaS) and Software-as-a-Service (SaaS) applications.

Recent incidents have highlighted the importance of secure identity management. Misconfigurations in identity services like Okta have been exploited by threat actors, leading to significant data breaches. These incidents underscore the necessity of robust security controls and Authentication Policies to safeguard against such attacks.

In this article, we will guide you through setting up Okta’s authentication journey and the available security configurations to ensure your identities are fully protected. By following these best practices, you can fortify your Okta environment against potential threats and maintain a strong security posture.

Okta Sign-In Journey Policy Evaluation

When an Okta user signs in to an application via Okta, two policy types are evaluated: 

1. The first, applicable if the user does not have an active Okta session, is the Global Session Policy. This policy enforces the necessary security controls required to authenticate to the Okta tenant successfully. 
2. Once the user is signed in to Okta, the next policy evaluated is the Authentication Policy, which mandates specific user, device, or security measures for the user to access the target application.

Both policy types enforce MFA settings. The Global Session Policy can require a specific type of MFA (or none at all) to establish an Okta session. In contrast, the target application’s Authentication Policy can demand stricter access security controls.

The relationship between these policies can be complex and may lead to errors when managing multiple authentication policies with various rules. 

In the next section of this article, we will delve into the configuration of each policy type and clarify potential areas of confusion.

Understanding the policy evaluation process is crucial for maintaining a secure tenant posture. A single misconfiguration could allow unauthorized access to multiple sensitive applications.

Okta Policy Structure

Okta policies have a similar structure. Multiple policies of the same types can be configured and applied to user groups or applications while maintaining a prioritized evaluation. The highest-prioritized policy/rule for an entity will apply. After a policy or a rule is evaluated successfully, the rest of the policies/rules are not evaluated – just like firewall rules.

Each policy has at least one rule. Each rule represents a set of conditions that must be met for successful authentication. The following table explains the differences between the Global Session and Authentication policies:

	Global Session Policy	Target App Authentication Policies
Controls Access To	The Okta tenant	Specific target applications
Policy Assignments	Assigned to groups	Assigned to applications
Rule Assignments	Assigned to the group that is assigned to the containing policy.  Each rule can exclude specific users or groups.	Assigned to the users that are authorized to sign in to one of the target apps covered by the policy.  Each rule can be narrowed down to specific groups and users out of the application-assigned users.
Prioritization	The authentication policies are priority-based as are the rules within a policy.	Authentication policies are not priority-based since each application can be associated with one authentication policy. However, the rules within the policy are priority-evaluated.
Unique Controls	BehaviorsExternal IdP conditionsTenant session lifetime	Specific factor type requirementsOrigin device-based conditionsExtra MFA validation (even if the global session is valid)

Policies Deep-Dive: Security Controls Technical Walkthrough

Authenticators Enrollment 

Another important policy type is the Authentication Enrollment policy which sets the required factors for each Okta group and the circumstances in which users can register a new authentication method. 

When a user signs in to Okta and has not yet enrolled in the required authentication methods (for example, on their first sign-in), the enrollment policy identifies the gaps and will require the user to configure the missing controls. While this policy does not authorize application access, it is important to be aware of the security gaps that might arise if this policy is misconfigured (along with the other two policies mentioned earlier, the Global Session Policy and the Target Application Authentication Policy).

Authenticators Setup

On your Authenticators Setup page, administrators can configure which types of authentication methods are available and for what purpose (authentication, recovery, or both)

There are three available authenticator types in Okta:

1. Knowledge (something you KNOW): This is considered the weakest type (e.g., password).
2. Possession (something you HAVE): Authenticate successfully only while using a specific device owned by the authenticating user.
3. Biometric (something you ARE): Uses facial recognition or fingerprint to authenticate the user. 

In addition, the different types of authenticators also have different characteristics like device-bound or phishing-resistant.

Click on ‘Add authenticator’ to review the available authentication methods supported by Okta.

Rezonate Tips:

1. Prefer strong factor types: device-bound possession and biometric factors are more secure than knowledge-based factors.
2. Protect sensitive applications with phishing-resistant factors.
3. Passwords have policies of their own. It’s important to allow password recovery using strong factors. User credentials compromise is likely to lead to email compromise as well, hence email (a non-device-bound possession factor) should not be allowed for recovery.
   

Policy Settings

The configuration of the Authenticator Enrollment policy is straightforward. It is assigned to Okta groups and enforces which types of authenticators are either required, optional, or disabled.

Rule Settings

The Authenticators Enrollment rules are also simple. The rules configure the network origins from which users can enroll policies. For example, you can deny or allow MFA enrollment from specific countries or IP ranges.

Global Session Policy

The global session policy configures the required controls and user context to authenticate to the Okta tenant. It means that an Okta user must be allowed by the Global Session policy before the application-specific Authentication Policy is even evaluated. It is the first line of your Okta tenant defense.

A default Global Session policy is created for each Okta tenant and is applied to the Everyone built-in group, which contains every Okta user in the tenant. The default configuration permits access using a password, Identity Provider (IdP), or any factor specified by the authentication policies. Like any security control, the Global Session policy should be tailored to your specific organizational preferences, scenarios, and needs.

Rezonate Tips: 

Create multiple Global Session policies and assign them to different job or technical functions. You should create a “strictness ladder” where the first prioritized policy is assigned to the most sensitive users and applies the most strict security controls, while the lower-prioritized policies are assigned to less sensitive users with lower security standards.

Rule Settings

In this section, we will break down the available security controls that the Global Session rules provide. Each Global Session policy can include multiple prioritized rules and each can exclude specific users.

Before diving into the available configurations, two controls will be further explained because we, at Rezonate, believe they can make a strong positive impact.

Network Zones

A network zone is a customizable object that can be used to control access to an Okta tenant based on the origin of an authentication request.

There are two types of network zones:

1. IP zone: An aggregated list of IP addresses and ranges.
2. Dynamic zone:  One or more conditions based on IP address metadata such as geo-location, ASN number, and other incriminating characteristics such as a Tor exit node and a proxy address detected by Okta.

Once a network zone is configured, it can be used as a condition by Global Session Policies and Application Authentication Policies.

Behaviors

Okta behaviors are a list of calculated attributes that Okta uses to alert users about potential identity misuse. Each behavior can be configured to address a specific behavior-based conditional access. A behavioral profile helps in verifying that a human using an identity is who they claim they are. The behavioral profile creates a baseline for each identity. When there is a deviation from the baseline, it might suggest that the identity is compromised.

For example, a user has always signed in from Germany in the past year and suddenly made a sign-in from Argentina.

The available behavior types are:

• IP Address: Detects an IP address that was used for the first time by an Okta user.
• Location (Country, City, Geo-Location): Derived from the IP address. Detects new sign-in locations of Okta users.
• Device: Detects new devices that were used to sign in Okta users.
• Velocity: Detects suspicious sign-ins by calculating the distance between two successful sign-in events that originated from different locations. The behavior detection is triggered if the time that passed between the two sign-ins is physically impossible. An example would be a user who signed in from the US and two hours later signed in from Europe.

You can set the thresholds of the behavior detection rules on the behavior detection page in the Okta Admin Console (Security > Behavior Detection).

The behavior detection outputs a set of boolean values that can be used as conditions in your policies. For example, you can create a Global Session Policy rule that requires presenting a biometric MFA if the user logs in from a new device combined with a new geographic location.

Rezonate Tip: 

When behaviors are being evaluated in one of your policies, the Okta audit log reflects it in the audited events.

Conditions

Each rule of a Global Session policy dictates if a sign-in is allowed or denied based on the combination of the following conditions:

1. The user’s IP is included or excluded from a network zone (or all of them).
2. The identity provider is Okta itself, or any other external IdP trusted by Okta.
3. Authenticates via a specific authentication interface.
4. Behavior is true for one of the available behavior detections.
5. Risk scoring, which is calculated by Okta, is low, medium, or high.

If a rule evaluates a sign-in request all the above conditions are True, the Access can be allowed or denied based on the administrator’s configuration.

MFA Settings

If the rule allows access, MFA settings are also configured in it. 

The available settings are:

1. Establish the user session: Use either a password or any factor used to meet the Authentication Policy requirements. The second option is very common but must be configured with caution since it passes the first-factor decision to the target application’s supported factors.
2. MFA is either required or not. 
3. Users will be prompted for MFA in one of the following cases:
   1. At every sign-in.
   2. When signing in with a new device cookie.
   3. After the MFA lifetime expires for the device cookie (Okta will not prompt the user to represent MFA if the user selects the “Keep me sign in” option). If this option is selected, the Admin must configure the MFA lifetime.

Rezonate Tip: 

Require MFA and configure a reasonable MFA lifetime. We recommend, depending on the user privilege, that the MFA lifetime should not exceed 9 hours (or the equivalent of a full working day). 

Session Lifetime Settings

The rules also set the session lifetime (when the user has to re-authenticate). The available settings are:

1. Maximum Okta global session lifetime is either not limited or limited to a specific timeframe.
2. Maximum Okta global session idle time which can be set at max to the same timeframe that was configured in the previous setting. It only applies if the user is logged in but was inactive during an active Okta session. 
3. Okta global session cookies persist across browser sessions and are either disabled or enabled.

Rezonate Tips: 

1. Set a session time limit. Require your users to authenticate at least once a day.
2. Configure the idle time to be equivalent to half of the working day time, or less to keep your session secured and lower the chance of session hijacking.
3. Disable persistent cookies to lower the chance of session hijacking. 

Application Authentication Policies

Okta Authentication Policies validate users’ security controls when they access Okta applications. Authentication Policies share overlapping controls with the Global Session Policies but for different purposes. Authentication Policies protect application access – not identities.

An Authentication Policy can protect access to multiple applications while an application can only be assigned to one authentication policy. Like Global Session Policies, the Authentication Policies can hold multiple rules to tackle different access use cases in a prioritized manner. 

Rezonate Tip: 

Create an authentication policy tailored to the security requirements of your target applications based on their sensitivity. For instance, implement a policy that mandates the strongest type of MFA for highly sensitive applications, such as admin consoles or data lakes containing PII. For less sensitive applications, establish a second, less restrictive policy.

Rule Settings

Authentication Policies are more granular than Global Session Policies. With the correct configuration and prioritization, a single Authentication Policy can validate every possible authentication use case. 

Conditions

These are the available conditions for authentication rules:

1. Entity rules
   1. The user’s user type: Differentiate between user types that are configured in the Directory Profile Editor page in the admin console.
   2. User’s group membership includes: Use group memberships as conditions.
   3. User is: Assign the rule to specific users.
2. Device rules
   1. The device state is: “Registered” or “Any.” Meaning, if Okta Verify is installed as an authenticator on the device that was used in the authentication.
   2. The device management is: Managed or not as configured in the Device Integration page in the admin console.
   3. The device assurance policy is: Check if the authentication origin device passes one or more Device Assurance policies. 
   4. The device platform is: Assign the policy to authentication attempts from a specific operating system.
3. Miscellaneous 
   1. The user’s IP condition: Same as the Global Session condition.
   2. Risk condition: Same as the Global Session condition.
   3. The following custom expression is true: If the above conditions somehow do not support one of your requirements, you can create custom conditions using the Okta Expression Language.

If the combination of all the above is True, you can either allow or deny access to a target application.

MFA Settings

If access is allowed by the rule, you can configure the following MFA requirements:

1. The user must authenticate with: This setting controls what type of factors are required by the target application for successful authentication.
   1. One-factor type – A password, a possession factor, or any other authenticator supported by your Okta tenant. 
   2. Two-factor types – A password and any other supported factor, or any combination of two supported factors.
2. Possession factor constraints are: Sets the required possession factor characteristics if a possession factor is used. Can be used to exclude specific factor types (like SMS and Email) or require hardware-bound/phishing-resistant factors.
3. If Okta FastPass is used: Can be used to require biometric verification.

When you complete the MFA settings configuration, you can look at the diagram below (on the Rule Configuration page) to review the result of your configuration.

Rezonate Tip: 

If you require your users to use any combination of two factors, you should make sure that you do not allow authentication with two weak type factors like a password and a security question.

Re-Authentication Settings

Session lifetime settings, in addition to the Global Session lifetime settings, are specific to the target applications protected by this rule. Use these settings to require different authentication settings from the Global Session requirements. 

An example would be an organization with one Global Session policy that requires weak factor authentication but has multiple authentication policies. A user can first authenticate to a non-sensitive application and obtain the global Okta session while authenticating with a weak factor type. Then, the same user, with the same global Okta session tries to access the Okta admin console that requires Okta FastPass. Other authentication use cases can be found in Okta’s documentation for Authentication Scenarios.

Below you can find an example of a single Authentication policy that supports eight different authentication use cases, where each use case is enforced by a different rule:

1. Trusted Location, Trusted Device, Privileged User.
2. Trusted Location, Trusted Device, Non-Privileged User
3. Trusted Location, Non-Trusted Device, Privileged User
4. Trusted Location, Non-Trusted Device, Non-Privileged User
5. Non-Trusted Location, Trusted Device, Privileged User
6. Non-Trusted Location, Trusted Device, Non-Privileged User
7. Non-Trusted Location, Non-Trusted Device, Privileged User
8. Non-Trusted Location, Non-Trusted Device, Non-Privileged User

Each rule can mandate varying levels of security controls, ranging from the most strict (like use cases number 7 and 8, which are essentially Zero-Trust scenarios) to minimal controls (like use case number 2)

Real-Life Example: Zero-Trust Policy For Admin Authentication

In this section, we will configure policies to support a Zero-Trust scenario of Administrator authentication to sensitive applications.

1. Pre-requisites
   1. Creating at least one trusted network zone.
   2. Creating an administrative Okta group.
   3. Strict password policy.
2. Authenticators Configuration
   1. The only accepted type of MFA would be a phishing-resistant authenticator with a required biometric verification. Below you see that we will accept Okta Verify and FIDO authenticators in addition to a complex password.

3. Authenticator Enrollment Policy
   1. Below you’ll see that we require our administrators to use a password, Okta Verify, and optionally a FIDO2 authenticator by assigning the following policy to our administrative group.

2. Weak factors are explicitly disabled.
3. Below we configure a policy rule to allow Administrators to enroll authenticators only from the trusted network zone.

4. Global Session Policy
   Now, let’s create a new Global Session policy for our use case. The policy must assume that we deal with every administrative authentication flow, without any prior knowledge about the authenticating persona (Zero Trust):
   1. The policy will have the highest priority since this is our most sensitive authentication use case. First, we must make sure that this policy is evaluated first.

2. No Admins are excluded from the policy.
3. Every condition will be set to “any” to support every authentication use case.
4. Access will be allowed with a password and MFA is required at every sign-in. This is a strict configuration. We prefer security over convenience when it comes to sensitive access by a privileged user. 
5. We set the maximum session lifetime to 2 hours and the maximum idle time to 30 minutes. We don’t allow cookies to persist.

5. Authentication Policy
   1. We created an entirely new Authentication policy with a single rule. The same rule can be added to any other policy as the first priority.
   2. The rule is assigned to the Administrators’ group without any other condition to support every administrative authentication scenario (Zero Trust).
   3. Access is allowed with a combination of a password and a phishing-resistant factor (Okta Verify / FIDO2).
   4. The Admins will have to provide MFA every time they access one of the apps that will be assigned to the policy. Providing a password again is not required as long as an active Global Session exists.

Ensure Continuous Security for Your Okta Environment

Configuration is essential to maintaining a secure environment. The challenge occurs in highly dynamic and expanding environments. That’s where a solution like Rezonate can help. We provide security for your identity provider platforms as well as cloud and SaaS applications. From identity threat detection and response to identity security posture to streamlined access reviews and compliance, we can enable you to proactively secure identities and also be ready when an attack is underway with rapid threat detection and response. Request a demo today!

Get the Ultimate Okta Security Booster Kit

Cyber attackers continuously exploit user, system, and infrastructure vulnerabilities to gain unauthorized access to sensitive data. With 80% of data breaches involving compromised credentials, identity breaches can cause immediate financial losses and long-term reputational damage.

Proactive measures with leading identity providers like Okta are essential for preventing breaches. The key to success is ensuring proper configuration and maintaining a consistent and continuous effort to protect your identities. Download our Okta Security Essentials Booster Kit to fortify your defenses and stay ahead of threats.

What’s Included: 

• Top 10 Features To Enhance Your Okta Security Posture: Learn about underutilized Okta features that can significantly boost your security and could have mitigated recent Okta breaches.
• 19-Point Okta Security Checklist: Assess the security posture of your Okta tenant with this checklist, covering authentication, authorization, session policies, and logging capabilities to mitigate risks.

• Okta Threat Hunting Guide: Navigate Okta logs with this step-by-step guide. Turn raw data into actionable insights, detecting threats like brute force attacks, MFA fatigue, impossible traveler attempts, and privilege escalation techniques.
• 8 Okta Security Best Practices To Implement Now: Discover eight essential practices to get the most out of Okta and safeguard your digital identities against cyber attacks.