I completely support the two-page mechanism, for several reasons.
I very much dislike the model where, after entering an email address, the page contents change to redirect you to a different login. For one thing, that’s a separate call out to the server, which takes longer than you expect on slow or lossy networks.
Also, I wonder how that UI change appears to someone using a screen reader. I think that, given a choice between this method and a two pages, the two pages is friendlier to the visually-impaired. But I would love corrections on that!
Having an API to match username to login method also means you have more code to maintain, and you have a potential source of information leakage to protect. With separate pages, you can use more-generic technologies, which react upon seeing a weird access pattern (like CloudFlare’s DDoS protection interstitial).
I dislike the optional password method for two reasons. First, infrequent users may not remember that they use SSO. They enter a password. If the site takes them to SSO, then it just reinforces the wrong notion that a password _is_ required.
It can also make things confusing if a person uses a site twice, once for work (which uses SSO) and once for home (which uses a password). In this situation, having a username and optional password on one page may interact weirdly with a password manager.
Those were just the first things I thought of. I expect there are more, but then I’d start rambling!
The part I dislike about the two page logins is they often don’t repeat the login name on the second page.
For Google’s logins for instance, there are times when my password manager doesn’t get what user I am supposed to log as, and I might also not remember what I chose on the first page (just showing me the account’s name doesn’t help when I use several accounts with all my real name)
And the opposite issue with realizing on the second page that I am not on the right user or want to change. Depending on the context (e.g. a browser pane popped up by an app) going back is cryptic or just not well supported.
In that sense it’s less confusing in some way, more in others. I don’t see it as a very good alternative or something that should win the world.
The solution seems pretty pbvious, and it's in use on pretty much every smartphone app. Just have more login buttons that can lead you to the right page.
"login in with email/password", "login in with $SSO".
I very much dislike the model where, after entering an email address, the page contents change to redirect you to a different login. For one thing, that’s a separate call out to the server, which takes longer than you expect on slow or lossy networks.
Also, I wonder how that UI change appears to someone using a screen reader. I think that, given a choice between this method and a two pages, the two pages is friendlier to the visually-impaired. But I would love corrections on that!
Having an API to match username to login method also means you have more code to maintain, and you have a potential source of information leakage to protect. With separate pages, you can use more-generic technologies, which react upon seeing a weird access pattern (like CloudFlare’s DDoS protection interstitial).
I dislike the optional password method for two reasons. First, infrequent users may not remember that they use SSO. They enter a password. If the site takes them to SSO, then it just reinforces the wrong notion that a password _is_ required.
It can also make things confusing if a person uses a site twice, once for work (which uses SSO) and once for home (which uses a password). In this situation, having a username and optional password on one page may interact weirdly with a password manager.
Those were just the first things I thought of. I expect there are more, but then I’d start rambling!