Web Development

SSO has already been mentioned, but expanding on that for those that aren't familiar:

When you have a big organization with lots of people that needs to access maybe dozens of sites to do their work, it quickly becomes a nightmare to manage. You'd have to invite the user on dozens of sites, you can't easily control their access, it's easy to forget about some accesses. You have to care about users using a good enough password, make sure to sign up with their work email, etc.

Enter SSO. The company maintains a central directory for their users, where they can enforce password policies, enforce the use of 2FA authentication, and can out users into groups which grants them access and permissions to external services. So they can make say, a "developers" group and it gives you access to a testing AWS environment, read only access to logs in DataDog, access to some settings in Cloudflare, etc. They put your user into that group and you automatically get access to all that.

Of course at that point, you don't have a password for any of those sites. But you need a way to log in. So that's why the login process is multistep: you first enter your email and submit that. From there, the site can determine if you belong to an SSO organization and redirect you to the SSO flow where you'll authorize the log in and your company can also grant or deny the access to that site through your company email account. And then you're in, no password required because supposedly you're already logged in to your company email or logged in as a side effect of logging in to a company computer.

If you have a regular account, then the site can prompt you for your password, and optionally your 2FA code. They could just put all 3 fields on the same page, but at that point you don't know if the user needs a password, or if they need an MFA code as well.

Plus, if you don't have an account at all, it can then show you a registration page to enter the rest of your details, so you don't even need a separate registration flow either.

As the other person said, this is a classic SSO pattern. Your email or sometimes just organization ID that you enter in that field will send you off somewhere else to sign in, then you don’t get the password field at all.

On applications I've worked on, pretty much every time we've integrated SSO using oauth we've modified the entire login form to look the same. That means enter email, and we either send you to your provider login page or we show a password prompt after. Not a good reason in my opinion, but one that shows a similar UI regardless of login type.

Paginated login

Microsoft enabled it in ADFS on WS 2019. I know there are plenty other places it's used, but It's the example I'm most familiar with.

There can be a security element to it depending on how the server handles paginated auth as it separates the password field away from the user ID. You can also interject the second factor first before the password to protect brute forcing.

But the larger reason I've read is that it's easier for end users to use. Here's MS talking about it with ADFS.

"Instead of a long form to fill out, a new flow takes you through the sign-in experience step-by-step. Our research shows that with this approach, our customers have more successful sign-ins."

https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/ad-fs-paginated-sign-in

Whether this is true or not is debatable. I'd love to see passwords die out. I doubt I'll see that in my lifetime though.

This makes using a password manager super annoying, because I have to trigger the autofill twice.

Some - if not most - password managers let you configure the auto-type-sequence for each password individually (e.g. KeePassXC). Just change the default {USERNAME}{TAB}{PASSWORD}{ENTER} to {USERNAME}{ENTER}{DELAY X}{PASSWORD}{ENTER} with X being a delay in milliseconds that pauses the sequence until the new page has loaded completely.

I don’t have an answer for your original question, but I have noticed some forms still auto fill the password field. Guessing it’s handled by hiding and un-hiding via css, so the extension can still find it and auto fill

I think PayPal may be one off the top of my head if I’m not mistaken

If the transition was anything but fake (i.e. they do something with the user name before showing the passwordfield) I feel like that would be a bigger security hole. A leak of some sort of info about the username maybe.

It's done this way for SSO. Sometimes instead of providing the password you will be redirected to your company's SSO based on the email address domain.

As others have said, likely SSO related. We do this with our sites at the company I work for. Some sites are internal, some are client-facing. But you can be logged into all at the same time through one SSO portal. If you’re an internal user, you’re redirected over to the internal SSO after entering your email, whereas external users get a generic password screen.