Unfortunately I've also seen that a few times. There seem to be two common ways to get it wrong:
One is too-rigid modeling. Some sites explicitly only want to support passkeys as a single-factor authentication method, and then they don't go the extra length of also supporting non-discoverable credentials. (The only thing that would take is to optionally prompt for a user name in their login form, which almost all sites do anyway for legacy login methods.)
I do have empathy for sites wanting to not complicate their backend model too much, i.e. they only want to support two-factor authenticators, but many hardware authenticators these days support a PIN or biometrics! Some sites, I suspect, even outright exclude roaming (i.e. non-platform) authenticators, even though they do support discoverable credentials and user verification, i.e. everything that passkeys can provide too (albeit with limited storage capabilities), which is just sad.
The other is just due to outright bad practices: Some sites gate their WebAuthN implementation behind a user agent flag. Then they inevitably lack behind actual browser support, and in many instances the user agent alone won't even tell the full support story (now that browser might be using the OS-provided credential API, which can then delegate to a third-party password manager).
As often, Amazon wins the award for the worst possible UX here by
- Implementing WebAuthN as an alternative to password entry, rather than as an alternative second factor (which is the sane thing to do), which means I have to still provide my TOTP after providing my (dual-factor!) passkey. (Bonus: I can't use my passkey for password reauthentication, I have to log back out to get back to the screen where I can select one.)
- Excluding Firefox via user-agent sniffing (with a completely incoherent error message of "If you want to add a passkey, use a different cloud service account (example: Apple ID or Google account)" as a reasoning for why I can't proceed on Firefox
- Calling my USB hardware authenticator "iCloud Keychain", because I registered it via Chrome on macOS (?!)
- Requiring a PIN entry on an authenticator that supports it, despite not using any two-factor functionality semantically
One is too-rigid modeling. Some sites explicitly only want to support passkeys as a single-factor authentication method, and then they don't go the extra length of also supporting non-discoverable credentials. (The only thing that would take is to optionally prompt for a user name in their login form, which almost all sites do anyway for legacy login methods.)
I do have empathy for sites wanting to not complicate their backend model too much, i.e. they only want to support two-factor authenticators, but many hardware authenticators these days support a PIN or biometrics! Some sites, I suspect, even outright exclude roaming (i.e. non-platform) authenticators, even though they do support discoverable credentials and user verification, i.e. everything that passkeys can provide too (albeit with limited storage capabilities), which is just sad.
The other is just due to outright bad practices: Some sites gate their WebAuthN implementation behind a user agent flag. Then they inevitably lack behind actual browser support, and in many instances the user agent alone won't even tell the full support story (now that browser might be using the OS-provided credential API, which can then delegate to a third-party password manager).
As often, Amazon wins the award for the worst possible UX here by
- Implementing WebAuthN as an alternative to password entry, rather than as an alternative second factor (which is the sane thing to do), which means I have to still provide my TOTP after providing my (dual-factor!) passkey. (Bonus: I can't use my passkey for password reauthentication, I have to log back out to get back to the screen where I can select one.)
- Excluding Firefox via user-agent sniffing (with a completely incoherent error message of "If you want to add a passkey, use a different cloud service account (example: Apple ID or Google account)" as a reasoning for why I can't proceed on Firefox
- Calling my USB hardware authenticator "iCloud Keychain", because I registered it via Chrome on macOS (?!)
- Requiring a PIN entry on an authenticator that supports it, despite not using any two-factor functionality semantically