Should there be a "Sign in with a passkey" button on the bootstrapping authentication guidance?

[sbweeden]

Summary

See: https://passkeys.dev/docs/use-cases/bootstrapping/

The initial sign-in page recommendation today shows only a username entry field and suggests detection and use of the autofill UI.

What if the autofill UI is not available, but the user has a discoverable credential (regardless of whether or not it's the platform authenticator, on their phone, or a hardware security key)?

At one point it was being suggested that the login page also show a "Sign in with a passkey" button to initiate the normal/modal UI for passwordless login to handle this case.

You could even suggest that such a button be displayed only when PublicKeyCredential.isConditionalMediationSupported() returns false.

Details

I want to understand if adding a "Sign In with a passkey" button this is still the recommended advice, or if the content on this site is only being developed with a view to the future when all browser support the non-modal UI?

Proposed Content Type

Best Practice

Proposed Content Title

Adding a "Sign in with a passkey" button

Related Articles

https://passkeys.dev/docs/use-cases/bootstrapping/

[timcappalli]

The passkeys.dev guidance is currently targeted at orgs that are new to everything FIDO2 and want to start with passkeys, so the current guidance has been that if you have a username field today, you should use autofill UI and probbaly not add a button.

We imagine the button will be the primary method in a few years when most users have a passkey.

That being said, there's nothing wrong with having a button (Microsoft's log in page has a username field and a button, for example, but we've had FIDO2 support for a long time). I can add a blurb about that (or feel free to propose some text). I do like the idea of it being tied to the result of PublicKeyCredential.isConditionalMediationSupported()

[janko]

When I was learning WebAuthn protocol for the first time, I understood from reading the "Bootstraping" section of passkeys.dev that the only way to sign in the user with a passkey without them first entering their email is via Autofill UI. I only recently found out that the regular flow also supports allowCredentials: [] by inspecting the passkey implementation that GitHub shipped.

It would be great if a passkey login button alternative was mentioned on passkeys.dev, so that it's clear to newcomers that autofill UI isn't the only way. I became a bit disillusioned with it finding out its seemingly poor browser support, and seeing it stop working Chrome when it used to work before 🤷🏻

Passkeys.dev could recommend showing the passkey login button only when a user was once logged in on that browser and they have passkeys setup. This is how GitHub implements it, by storing this information in session data that persists after logout. I guess that's technically reauthentication then, but it doesn't require remembering the user that was previously logged in.

[timcappalli]

This is how GitHub implements it, by storing this information in session data that persists after logout.

@janko this is only for their preview/beta release.