Sign-in flows

The Sign-In Widget is a little different in Identity Engine:

  • There’s no security image.
  • The Remember me checkbox is now Keep me signed in.

In Classic Engine, Remember me serves two purposes. It populates the Username on the Sign-In Widget, and admins can configure it so that users' sessions continue after they close and reopen their browser.

In Identity Engine, these features are separate. Admins can configure one or both on the Security > General page:

  • Remember user on sign in populates the Username field on the Sign-In Widget. The end user is still required to authenticate. It doesn't remember recent MFA authenticators or previous sessions.
  • Keep me signed in enables a session that extends beyond browser lifetimes. It also remembers MFA authenticators from previous sessions for the amount of time defined in the global session policy.

Sign-in flows for registered end users

The sequence of a sign-in flow depends on the authentication requirements that you set in your global session policy.

  • Password-first flow: If the user session is established with a password, the password field appears on the same page as the username field.
  • Identifier-first flow: If the user session is established with any factor used to meet the authentication policy requirements, the username prompt appears first.

Password-first flow

The password-first flow is the traditional sign-in flow found in Classic Engine. In Identity Engine, the sequence is the same. Only the Keep me signed in checkbox is different.

  1. The end user goes to your sign-in page.
  2. The Sign-In Widget displays Username and Password fields.
  1. The end user enters a full username, including the domain, and a password.
  2. The end user selects Keep me signed in if they want to store these values on the device.
  3. The end user clicks Next.
  4. If either of your sign-on policies requires a secondary factor, the Sign-In Widget displays the available security methods.
  5. The end user selects a security method and completes the verification step.
  6. The end user accesses the application.

If this is the flow that you want for your org, create a global session policy rule that establishes the user session with a password. You can then enforce secondary factors in your global session policy or in an authentication policy.

Identifier-first flow

Identifier-first flows are new to Identity Engine.

  1. The end user goes to your sign-in page.
  2. The Sign-In Widget displays a Username field.
  1. The end user enters a full username, including the domain.
  2. The end user selects Keep me signed in if they want to store their username and authentication method on the device.
  3. The end user clicks Next.
  4. The Sign-In Widget displays the security methods allowed by your sign-on policies.
  5. The end user selects a security method and completes the verification step.
  6. The end user accesses the application.

If you want this flow for your org, create a global session policy rule that establishes the user session with any factor used to meet authentication policy requirements. You can then enforce secondary factors in your global session policy or in an authentication policy.

Identifier-first flow with biometric

If your sign-on policies allow a biometric authenticator, the Sign-In Widget shows an identifier-first page with Okta FastPass optimized.

  1. The end user goes to your sign-in page.
  2. The Sign-In Widget displays two options: Sign in with Okta FastPass and the Username field.
  1. If the end user chooses to sign in with a username, they continue through the steps of the identifier-first flow.
  2. If the end user chooses Sign in with Okta FastPass, they automatically authenticated through their device enrollment.

If this is the flow that you want for your org, set up Device Trust and create a passwordless authentication policy.

Related topics

Global session policies

Authentication policies

Okta FastPass