Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Questions to modify the demo projet to passkeys for cross platform scenarios #384

Open
anotherrohit opened this issue Nov 5, 2024 · 2 comments

Comments

@anotherrohit
Copy link

I would like to modify the demo project to be used for cross-platform scenarios using passkeys,i.e objective being use passkeys from any device using the demo project in this repo., but need some help with the following questions

Where can I set PublicKeyCredentialHints per the webAuth level 3 spec in the demo project? Per understanding, all webauthn examples prior to relying on authenticatorAttachment (client-device, security-key, or hybrid) need to switch to credential hints in case of passkey on account of the prior world where cross-device synced credentials did not exist. With credential hints, you can tune the cross-platform registration flow to trigger hybrid registration so users do not get confused with cross-platform authenticators like Yubikeys.

Also, in PublicKeyCredentialCreationOptions, we can set authenticatorAttachment to "cross-platform" to enable the use of cross-platform authenticators (formerly called roaming authenticators), which are authenticators that can be moved around and used across multiple devices, but I could not find that in the current class under cores wenauthn/data folder

Finally, the values are set in the PublicKeyCredentialRequestOptions.allowCredentials list. This list needs to be double-checked by a backend (i.e., an LDAP directory in my case) with advanced passkey and device management capabilities to ensure that only passkeys created on a smartphone are set in the [allowCredentials] list. Can you please provide me with any pointers to add this equivalent check to persist in the current demo example?

@emlun
Copy link
Member

emlun commented Nov 6, 2024

Hi!

  • PublicKeyCredentialHints is not yet supported in a release, but it was added in Add support for PublicKeyCredentialHint #378 and will be included in the next release. In the meantime, you could add the hints parameter on the client side before passing the parameter object into navigator.credentials.create() or .get().

  • authenticatorAttachment can be set during registration using the StartRegistrationOptions.authenticatorSelection.authenticatorAttachment attribute. No authenticatorAttachment parameter exists for assertions.

  • As for the last point, I don't think there is a fully reliable way to check for "only passkeys created on a smartphone". PublicKeyCredential.authenticatorAttachment could be either platform or cross-platform depending on whether the smartphone was used as its own platform authenticator or as a roaming authenticator via the hybrid transport. It's possible you could detect smartphones by checking for the presence of "hybrid" in AuthenticatorAttestationResponse.getTransports(), but I'm not sure how reliable that is either. Most smartphones (currently) don't return attestation either, and some don't return an AAGUID, so those aren't reliable options either.

    Anyway, if you have some way to do this filtering then you can simply modify the AssertionRequest returned from RelyingParty.startAssertion() using its toBuilder() method to overwrite the allowCredentials attribute. Do this before saving the AssertionRequest to server state so that you can use the modified object in the input to RelyingParty.finishAssertion().

    However, I don't think that's wise to do. If a user has managed to register a credential that's not on a smartphone, then it's very confusing and frustrating for that user if they then can't use it to authenticate. I'd say the better option is to set hints: ["client-device", "hybrid"] during registration to steer users toward those as the primary options, but not block non-smartphone passkeys for users who actively choose that.

    Finally: note that for "username-less" and "autofill" login, allowCredentials has to be empty anyway, so you won't be able to do this kind of filtering at all in those use cases.

Does that help?

@anotherrohit
Copy link
Author

Thank you, these are extremely helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants