End user sign-in process

First sign-in attempt

Okta processes all sign-in attempts from new devices by evaluating the same set of conditions:

  • If your org uses email for Single Sign-On (SSO), then the email and password sign-in options are always available to users, even when the user profile doesn't exist or the user can't sign in.

  • If your org doesn't use email for SSO, the user is always prompted for a password.

  • The user can't sign in if authentication errors occur.

  • When the same user attempts to sign in again on the same browser, a full list of available authenticators is displayed.

Email used for SSO

If your org has email enabled for SSO, end users who try to access an app on a new device see the identifier-first Sign-In Widget.

  1. The end user enters their full app Username, including the domain, and then clicks Next. If you enabled the Multiple Identifiers EA feature, users can enter one of the configured identifiers instead of their username.
  2. If the end user's profile exists, the security method page displays Email and Password options.
    1. If the end user selects Password, they enter their password and then click Next.
    2. The Sign-In Widget prompts the end user for email verification.
    3. The end user selects Email, and then authenticates by clicking a link provided in the email.
  3. If the end user's profile doesn't exist, the security method page displays Password as the only option.
    1. The end user enters their password and then clicks Next.
    2. The Sign-In Widget displays the message Unable to sign in.

When email is configured as a required policy authenticator and is set to Authentication and recovery, the end user can either click a magic link provided in the email or authenticate using the provided OTP code. See Configure the email authenticator

  • If no subsequent factors are required, the link signs the user in automatically, as long as the user clicks it in the same browser.
  • If the user opens the magic link in a separate browser (or on a different device entirely), the user can use the OTP code in the original browser to complete the sign-in process. See Sign in using an email magic link or one-time password.

Future sign-in attempts

You can reduce friction for the sign-in experience even further by enabling the Stay signed in option. This feature enables a session that extends beyond browser lifetimes. See Organization Security.

Related topics

Sign-in flows

Multifactor authentication

New sign-in experience (Documentation for end users)