Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Forum Discussion
Solved
Lack of "Credential Provider Extension" implementation
Reading the following post by Ricky Mondello (Apple's passkey evangelist and Passwords app developer), I'm wondering why 1Password doesn't use the built-in system APIs for authenticating passkeys, rather than hijacking the web browser API and injecting JavaScript into every page:
By listening to lots and lots of feedback, I’ve learned that if someone’s main experience with passkeys is with a password manager that doesn’t natively integrate into the OS it’s running on — instead, one that hijacks web browser API — they’re far, far more likely to think they’re not a great user experience.
Some browser extensions that replace the built-in OS experiences have done so much harm to how technologists view the technology.
I’m not saying that third-party, independent, cross-platform apps are bad. They’re fantastic! What I’m saying is that they should integrate into the native bindings to be a data source for all web browsers and apps on a platform. Nobody wants a credential that only works in web browsers and not other native apps.
It also has the side effect that passkeys don't work in native apps, which is becoming more problematic as many more apps require a (web-based) login to function.
The “Credential Provider Extension” mechanism is present on iOS, iPadOS, macOS, and visionOS, and popular password managers make use of it to perform passkey auth in browsers and apps on behalf of the user. It’s a lot more popular on iOS than on macOS, sadly. On iOS, 1Password, Bitwarden, Dashlane, Chrome, and LastPass all integrate with it to save and authenticate with passkeys.
This was discussed some months back on the old forum, but it appears that thread didn't make the transition to the new forum.
Can anyone from 1Password provide a well-reasoned justification for not using the system APIs provided and giving a worse user-experience as a result?
Hey snozdop! 👋
You’re absolutely right that the Credential Provider Extension offers some advantages on Apple platforms, especially when it comes to passkeys in native apps. It’s something the team has been exploring, and we’re excited about the possibilities there.
Right now, most of our passkey work has focused on making things seamless in the browser, since that’s where the majority of usage happens today. That includes using the WebAuthn API directly so folks can create and sign in with passkeys without needing the desktop app, which we recently rolled out across all major browsers.
We’re continuing to explore ways to go deeper at the system level across all platforms. For example, we just released native passkey support on Windows 11, and we’re actively looking into what native integration could look like on macOS as well. Nothing to share right now, but it’s definitely on our radar.
1 Reply
- 1P_Blake
Community Manager
Hey snozdop! 👋
You’re absolutely right that the Credential Provider Extension offers some advantages on Apple platforms, especially when it comes to passkeys in native apps. It’s something the team has been exploring, and we’re excited about the possibilities there.
Right now, most of our passkey work has focused on making things seamless in the browser, since that’s where the majority of usage happens today. That includes using the WebAuthn API directly so folks can create and sign in with passkeys without needing the desktop app, which we recently rolled out across all major browsers.
We’re continuing to explore ways to go deeper at the system level across all platforms. For example, we just released native passkey support on Windows 11, and we’re actively looking into what native integration could look like on macOS as well. Nothing to share right now, but it’s definitely on our radar.
