> 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.
> 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.
So what if we don't know? We can find out at the same time.
We're trying to authenticate a pair: user/pass.
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.
Aren't you leaking that there's an account with that email that has a non-password auth method if you treat them differently?
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.
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.
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.