Global Session Policy

In this scenario, the work is at the org level. All apps require a password and a secondary authentication method (from any authenticator made available). All apps have a default policy.

Note: We included this use case so you can see how to use a Global Session Policy in a similar fashion to how you use Okta sign-on policies in Classic Engine, but this use case does not use authentication policies. Everything is done by the Global Session Policy.

You can also optionally configure an authentication policy that requires one hardware-protected authentication method for an app with more rigorous security requirements. This authentication policy will limit the authenticators for the second authentication method to Okta Verify.

Setup and configuration

  • You can turn off Okta FastPass if it's already turned on in your org, but it won't be used by a Global Session Policy.
  • Optionally add a user and group to assign the Global Session Policy to.
  • Create an app integration so that the user has something to sign in to. If you're just testing the scenario, you can use a bookmark app to see how it works. In your scenario, the app would be one of your business apps. The app will use all default values and will also use the default catch-all rule so it applies to all users.

User sign-in experience

When a user signs in to the app, they see the Okta Sign-In Widget asking for a name and password. This is because the default catch-all rule only allows a password authentication method.

After the user enters a password, they see a dialog with choices for additional authentication methods that satisfies the Global Session Policy. The list contains the authenticators that the user has enabled.

Optional: add a higher assurance app

For one special higher assurance app, add an authentication policy that requires a hardware protected-authentication method. In this scenario, this limits the authenticators to Password or FIDO2(WebAuthn) + Okta Verify.

User sign-in experience

You can see the difference in the user sign-in experience. For example, when a user signs in to a low assurance app, they need two authentication methods to sign in. Both password and phone (SMS) are required. However, factors are not equal in terms of the protection they offer. You can require different factors to deploy different assurance levels. For example, if you change the requirements from a password to Okta Verify, it's more secure even though you haven't added a second factor.

Note: Okta Verify is both an inherence and possession factor type when you use biometrics. You can see this in action by using different authenticators when signing in.

  1. Sign in to the bookmark app. You should see the password and prompt.
  2. Sign in to the higher assurance app you created. Depending on what you have configured for the user, you should see a verification prompt for a push notification or other authenticator.
  3. In a new browser (or incognito tab), sign in to the bookmark app again, using password and Okta Verify.
  4. Sign in to the higher assurance app. You will not see an additional prompt because Okta Verify satisfies the authentication policy.