Conditional UI and challenges #225
MasterKale
started this conversation in
Troubleshooting
Replies: 1 comment
-
Here's how I handle passwordless accounts for my app:
So I don't go usernameless, as it has the challenges mentioned above and my application always requires a username. For other apps, where a username (or email) is not required, it might make sense to go passwordless + usernameless for the best UX. However this would lock out all users with devices, that don't support Passkeys from your app. When your browser does not support WebAuthn, it just displays the traditional registration / login form: However when WebAuthn support is detected, you have additional options: |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
@P4sca1 asked the following in the merged browser autofill (a.k.a. conditional UI) PR:
For a bit more context, here's the example of how I proposed using the new capability of
startAuthentication()
:Before conditional UI, challenges were associated with a username, and so successful signing of a challenge by an authenticator associated to a username meant that user was signing in. However, conditional UI represents the "usernameless" WebAuthn flow that to date hasn't received a lot of attention for all of the hubbub around "going passwordless". You can't always know the username ahead of time, so how do you handle creating a challenge to include in the response from
/generate-authentication-options
?One answer is to create the new challenge and then temporarily store it in the server before sending it along. When the authenticator's response comes back to the server then you can check that the challenge is one you generated via some kind of session identifier, or perhaps having the front end simply return the challenge itself. So long as the challenge exists in your temporary store, then delete the challenge from the store (so it can't be reused) and perform verification on the response. If the response is legitimate, the credential ID can be used to cross reference the user that's logging in, and you can then mark them as "logged in".
(Alternatively you can reference
userHandle
for the user's ID, but since it's not signed you'd want to verify that the user handle belongs to a user that is associated with the credential ID.)There's been some timely discussion around this over on the WebAuthn spec repo that I think will interest you: w3c/webauthn#1764
Beta Was this translation helpful? Give feedback.
All reactions