I don't understand this. It's not an "implementation detail", it's a business requirement. That is, the business requirement is that some email addresses have different authentication requirements (i.e. with password or without). There are certainly different ways to handle this, as the article goes over in detail, but they all have different usability tradeoffs, and frankly I think the multi-step is less confusing than some of the other options.
It frustrates me when people, especially engineers, gloss over trade-offs that had to be made because their particular use case isn't as well supported without considering how all users are affected.
In this case the issue is not just the trade-offs but also messing up an existing paradigm.
I’m of the opinion that going against the status quo needs extra justification, and in this case the arguments are arguably weak (there are implementations that don’t break the well know user flow, and no alternative has an overwhelming advantage over the others)
Basically we’re stuck with sites that broke the original frame of reference without bringing a much better alternative.
Sure it’s a business requirement, but executed poorly. Can’t we be upset about it ?
Sure, you can be upset about it, but then at least let's make the argument about "What is the best way to solve this business problem?", instead of pretending this business problem doesn't exist.
For example, you argue that this "breaks an existing paradigm", but I'd argue that auth with just username and password is so fundamentally broken that a new paradigm is needed in any case, and things that push us more towards passwordless/token/key based auth is a step forward.
Choose your authentication method before entering the login details then. What are they going to do if they need to add support for electronic id cards? Add a 3rd page into the login step?
So instead of letting the system, which can easily determine which auth system to use based on the email, you're putting the responsibility on the user to remember what they used when they have potentially tens/hundreds of web accounts? Yet somehow putting the password on the next page is worse??
If they're going to use a password manager then the password manager will tell them. Your system can't determine if the user signed up with Google or is using an electronic id card either.
If you're using an electronic id card then you don't have the same username and password values that your website uses. You likely won't even use the same fields. Authenticating through that usually just involves a separate button.
Auth systems don't key off of usernames... When we added FIDO support there's still a backing user store that records user x has FIDO y, with a recording of the public key. That's how the pairing works. You can see it today on login.live.com
In Auth we call this a NASCAR, where there are so many buttons on the page that the user no longer knows which one they used to login last time. This leads to retention problems as users accidentally sign up for your app multiple times, ending up with their data scattered in multiple spots.
If usability is your goal, and I'm an SSO user who literally doesn't have a password, a form with a password required on the first step is going to be pretty unusable.
No user will understand that. They will call their IT admin and ask for the password. Or won't type the password and think you should find it somewhere else. Or think it's I secure because anyone can sign into their account without a password.
Make a background call to check whether a password is used for the given email, and hide the password field if so. There will be a delay, but if they’re confused that gives plenty of time to do this.
Regardless of if you use a password manager, or enter the credentials manually, it's adding another step in the flow of an already irritating system.