[singpolyma3]

> don't have a form with just a login email and force the user to click to enter the password

This is required for any non trivial auth system though. You not know until the user is submitted if that user has a password or is using something else.

[kevincox]

This is true but some sites handle it well. My browser auto-fills the email and password properly even though they are on separate "steps". Other sites the email field doesn't auto-complete in any way (but the password later usually does).

I don't know what the magic is here. If I had to guess they have both fields in the DOM but one is visually hidden. Then if your email is marked as SSO it is just never read.

[fmajid]

It probably has the email on form autofill, as opposed to password manager login/email+password autofill, but I use a different email for each site and that doesn't help me. On which.co.uk or AliExpress I have to laboriously type [e-mail] or [e-mail] on page 1. Some form autofill is getting smarter and is scoped to the site.

[Vinnl]

Don't underestimate the magic in your browser's autofill :)

[qup]

So what if we don't know? We can find out at the same time.

We're trying to authenticate a pair: user/pass.

[extra88]

There is no pair for the enterprise users signing in with their company's SSO or those using Passkey.

I think what some sites do is have a visually hidden, not required password field that a password manager can fill in. If it's not a password-based auth, the flow goes to the next step but if it is, it reveals the password field which may already be filled in.

[luckylion]

Aren't you leaking that there's an account with that email that has a non-password auth method if you treat them differently?

[extra88]

How would you avoid that? How would someone exploit that information? The whole point of the other auth means are that they're more secure.

[8organicbits]

If someone enters a username that doesn't exist in the system then you randomly prompt for password or alternate method, so it looks like an account may exist.

Username enumeration isn't usually considered a vulnerability, but it does make other attacks, like credential stuffing, easier. I.E. you can focus attack resources on usernames that have active accounts.

It's very low on my list of concerns though, usually there's much worse problems when I pentest.

[lelandbatey]

It's done that way as an overreaction to B2B customers which may want totally isolated per-tenant systems.

Take Okta login for example. Okta wants to offer big hyper-secure customers an option of "if you want, we can run our system in your cloud/data-center/whatever". To support that kind of system, you go to to the https://login.okta.com/ page and enter your email, JUST your email. Okta uses that to look up which customer tenant you belong to, then sends you to customer.okta.com where you enter your password. This way, the password only goes through infra owned by big-customer.

Okta then just builds everything with his indirection so they can move customers to it.