Why Login Screens Are Multiplying

The two-page login pattern has become increasingly common: you enter your email on one screen, click continue, and only then are you asked for a password on a separate page. On its face, this adds friction — an extra step for what should be a simple task. But the pattern exists for real reasons, and the question is whether those reasons justify the cost.

The core problem any login form must solve is that people forget things. They forget which email they registered with, and they forget which authentication provider they used last time — Google, Twitter, Apple, or something else. A common remedy is to remind users of their last sign-in method and offer it as a default. That approach, however, reveals account details that could be a privacy or security concern.

An alternative is to ask for the email first, then look up which service that account uses and redirect the user accordingly. That is precisely the idea behind the two-page login.

The Single Sign-On Problem

The main driver of two-page logins is Single Sign-On (SSO). Large organizations commonly require employees to authenticate through corporate SSO, which means users log in once per day with a single set of credentials. This simplifies regulatory compliance, makes provisioning and revoking access straightforward, and allows all of an ex-employee's accounts to be deleted in one operation.

When a company serves both business and private customers, the two-page flow lets the system check the entered email against its SSO configuration. If the address belongs to a corporate domain, the user is redirected to the proper SSO provider. This works well for SSO users, but for regular, non-SSO customers the experience is frequently frustrating.

Users often hold multiple accounts with the same service — one personal, one business. Two-page logins also break autofill and password-manager behavior, and most users find typing login and password on one page significantly faster.

Dedicated corporate login pages exist, but employees often go directly to the tools they use — Gmail, Figma, and so on — and attempt to sign in there. Those attempts fail because SSO is mandatory, which forces them to locate the correct entry point anyway.

A Better Flow With Conditional SSO

There is a workaround that avoids forcing two-page logins on everyone. The idea is to keep the traditional single-page form with email and password fields as the default. As the user types their email, the system looks up whether SSO is enabled for that address:

  • If SSO is enabled, reveal an SSO login option and make it the default. The password field can be optional or disabled.
  • If SSO is not enabled, proceed with the regular email and password login.

This approach adds near-zero effort for non-SSO users while routing SSO users to the correct provider. It preserves autofill and password-manager compatibility, and it saves both private and business account holders from unnecessary screen changes.

Considerations and Caveats

The conditional-reveal pattern has not been widely tested, so treat it as a promising alternative rather than a proven solution. Remember that SSO authentication does not always involve a password — logins can happen via YubiKey, Touch ID, or third-party OAuth providers. The detection logic must account for those cases.

Lockouts are inevitable no matter the flow, so magic links are useful for password recovery. Do not, however, force magic links as the regular login method — switching between applications is slow and error-prone. Instead, encourage users to enable two-factor authentication (2FA), which offers a good balance of usability and security.

Most importantly, test the login flow with the tools your customers actually use. Users relying on password managers or security software can experience a surprisingly broken sign-in process if the form does not behave as those tools expect.