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

Problems with pluggable passkey provider support #294

Open
irew opened this issue Nov 13, 2023 · 0 comments
Open

Problems with pluggable passkey provider support #294

irew opened this issue Nov 13, 2023 · 0 comments

Comments

@irew
Copy link
Contributor

irew commented Nov 13, 2023

Summary

RPs may not be aware of the challenges with supporting 3rd party passkey providers based on issues at the platform level.

It's important that RPs are aware of this, as their deployments will cause problems for their users who will raise those issues with the RP or the 3rd party provider, when in fact the issue may lie partly with the platform provider.

Details

iOS & macOS

Main issue

Currently native applications on iOS/macOS that support passkeys will fail to work with 3rd party pluggable providers due to a bug in iOS/macOS, this bug is fixed in iOS 17.2 (and most likely macOS 14.2) which is yet to be released.

RPs will not receive the clientDataJSON from the OS, it will be empty/nil, until the user has updated to iOS 17.2/macOS 14.2 (yet to be released).

While this applies to iOS and macOS, it is assumed most RPs will be concerned with the issue on iOS.

Additional issues

Below are additional issues with Apple support for pluggable providers, the bugs are listed here verbatim from the Apple bug reporting tool. It is not known if/when these issues will be resolved.

WebAuthn property "excludeCredentials" is not catered for in the passkey provider APIs (FB12855407)

It would be helpful to receive the "excludeCredentials" array from the RP so that the 3rd party passkey provider knows this is a potential duplicate key registration. Having duplicate keys created within a passkey provider is problematic as the user may end up deleting one from the authenticator and another via the RP settings screen, if 2 keys are registered with the same authenticator. If the OS knows that the authenticator already has a credential, it does not need to provide the entire list of "excludeCredentials", it can filter to include only credential IDs that it knows are owned by the provider.

The credProps extension is not supported on iOS (FB12817012)

If the RP requests the credProps extension to know if a resident key was created by the authenticator, iOS does not provide the credProps information, macOS does. You can test this with the following test website: https://inabajunmr.github.io/webauthn-viewer/ Create a passkey on macOS and notice the getClientExtensionResults section where the credProps extension information is provided. Do the same on iOS and notice it is missing. Expected behaviour is that credProps/rk extension is provided when the RP requests the extension.

Android

Native apps must use the Credential Manager API and not the legacy FIDO2 API, in order for 3rd party providers to work, there is a guide for this:

https://developer.android.com/training/sign-in/fido2-migration

Early adopters of passkeys will most likely be using the legacy Android FIDO2 API.

Proposed Content Type

Best Practice

Proposed Content Title

Considerations for pluggable passkey provider support

Related Articles

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

No branches or pull requests

1 participant