w3c / webauthn

Web Authentication: An API for accessing Public Key Credentials
https://w3c.github.io/webauthn/
Other
1.16k stars 166 forks source link

Provide a way for Web Extensions to hook into browser's Passkey autofill UI #1976

Open arianvp opened 11 months ago

arianvp commented 11 months ago

Description

Password Managers are rolling out Passkey support and they're doing this by monkey-patching navigator.credentials.get . This is leading to a lot of confusion with users as suddenly native Passkey autofill (conditional mediation) breaks and instead a non-native pop-up opens when the website loads.

image

This breaks all the nice usability features of Passkeys.

I have a lot of complaints of colleagues (As we're both using 1Password and Passkeys) that they can not log in anymore and I need to explain them to instead of expecting the nice Autofill flow from Safari they need to click the little "Security Key" icon in the 1Password popup. The problem is that I don't think 1Password can do any better within the constraints of the current API. And we need to provide them with the tools to build a nicer integration.

1Password's implementation currently does the following:

  1. Intercept the call with mediation: conditional
  2. Show 1password UI
  3. if you dismiss it, rewrites the navigator.credentials.get() call to be non-conditional. Triggering a modal flow. Note: I think they have no option here as it's not possible to trigger the conditional mediation flow from a web extension? (Not sure about this).

Solution

Stop gap solution:

If an extension intercepts a navigator.credentials.get({mediation:"conditional"l}) call it should be able to call navigator.credentials.get({mediation:"conditional"l}) again after dismissing the extension-specific logic; such that the browser autofill gets triggered.

Ideal solution:

Web Extensions should not be forced to monkey-patch navigator.credentials.get and break native autofill behaviour. Instead they should be provided with hooks to augment the autofill UI and add their own entries in the list.

Other options

Disable Password Manager.

Related Links

Notes

Perhaps this discussion should be made in the Web-Extensions group. But given people here are domain experts about how the browser integration for webauthn are built I think discussion here is useful. We could then make a proposal for an API to the WebExtensions WG

arianvp commented 11 months ago

I think in practise this means give a mechanism for Web Extensions to extend the internal PublicKeyCredential.[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) method. such that silentlyDiscoveredCredentials can be extended some way?

arianvp commented 11 months ago

If 1Password or other password managers are reading this:

iOS 17 and MacOS 14 now have support for integrating your password manager extension into the native Passkey auto-complete UI

https://developer.apple.com/documentation/authenticationservices/ascredentialproviderviewcontroller

irew commented 10 months ago

This only works if you ship a native app. Also, while iOS 17 is likely to be adopted by many users in a short amount of time, we have seen that it can take a lot longer for macOS updates/upgrades to get taken up by users. There will most likely be a solution to this problem in the long run, but in the short/medium term browser extensions from password managers is the best way to provide passkey support to a broad segment of users. There will be specific use cases where this introduces friction, but I consider those edge cases, at least among our users.

arianvp commented 10 months ago

Agree that having a Web Extension api for this would be more ideal given the high bar of writing a native application integration. Thanks for the context from the PW-manager side of things. Appreciated :)