Authentication policies deployment guide

In the continuously changing world of technology, every organization strives to find the right balance between the highest levels of security, best user experience, and improved agility. Organizations want to enable frictionless access to resources while reducing the risk of security incidents, and adopt modern security frameworks while continually factoring in contextual and adaptive policies for accessing apps.

Fundamental user behavior has also changed. It is now common for users to access critical organizational resources on their personal devices. Organizations face the challenge of enabling such access without the risk of data loss.

What can authentication policies do?

Authentication policies allow organizations to model security outcomes for application access based on industry-accepted, digital identity practices outlined by US-based National Institute of Standards and Technology (NIST). Authentication policies are deployed in conjunction with Global Session Policies to allow granular control at the time of access to a specific application.

With authentication policies, organizations can enable contextual, conditional access to apps based on the risk and security posture when a user accesses an application. Authentication policies enforce user authentication in the context of the requested application. The user's location and profile (also identified by the Global Session Policy) are verified against the authentication policy's group membership and authentication criteria.

Every app in your org has one authentication policy, but multiple apps can share a policy. Okta provides some preset policies with standard sign-on requirements, including a default policy for new apps. The default policy allows access with a single factor, and if you want to keep it in place for an app, you can.

However, you can customize multiple levels of access by creating your own authentication policies. You can create a unique policy for each app in your org, or just create a few policies and share them across multiple apps. If you decide later to change an app’s sign-on requirements, you can modify its policy or switch to a different policy. 

Remember that the definitions of factor and authenticators have changed, and a policy with two-factor authentication now requires two distinct factors. Two authenticators of the same factor (Knowledge, Possession, or Inherence) are not acceptable; you must use a different factor for each authenticator. For example, a policy requiring two factors cannot be satisfied by using the Email and Phone authenticators because they both belong to the Possession factor type. For instructions on setting up authenticators, refer to Add an authenticator.

Add an authentication policy rule to customize the level of application access. For example, you may want to challenge all default Okta users to provide a password, but challenge Okta users in a designated group to provide password and email factors. To accomplish this, you can create a rule that challenges default users to provide a password, and then create a second rule that challenges all group members for email and password authenticators.

Benefits of authentication policies

Authentication policies offer these benefits:

  • Passwordless authentication to specific resources
  • More robust authentication methods, even if the user has less robust methods enrolled (for example, SMS OTP, Email OTP, or Voice OTP) 
  • Custom number of factor types required for each app
  • Custom strength of the authenticators required for each app (for example, phishing-resistant or bound to devices
  • Custom factor lifetime for each app

As an Okta admin, you determine which authenticators and authentication methods are available. If a policy requires an authenticator the user has not enrolled in, Okta Verify will prompt them to enroll dynamically.

With authentication policies, you can:

  • Require higher security for critical apps.
  • Require phishing-proof or hardware-bound authenticators.
  • Allow passwordless authentication.
  • Allow strong factors on in-app transactions.
  • Leave some combinations of factors undefined.
  • Align better with NIST guidelines.
  • Let users choose the most convenient factor.
  • Require fewer factor prompts. If a user provides a strong factor for a critical app, and then signs in to a non-critical app with less stringent authentication requirements, they will not be prompted again.

Next steps

Review key concepts and considerations

Review and implement use cases