Third-Party Passkey Provider Compatibility

I suspect this is an issue with Google’s passkey implementation, but it might not be, and if there is a solution I suspect this post will be useful for all other third-party passkey providers encountering the same issue.

I have implemented Passkeys in our password manger using the new APIs introduced in iOS17. Passkey attestation and assertion works as expected with every service we’ve tested that supports Passkeys (I.e Webauthn.io, GitHub, etc). However the only service that doesn‘t work is Google.

I can create a passkey for Google using iCloud Keychain just fine, but for some reason, although my app successfully creates the passkey, Google is rejecting it.

I suspect this is a security measure on Google’s side, but it will be a UX nightmare for users of third-party passkey managers on iOS 17, as they won’t be able to create or sign in with a passkey for Google (which will probably be the number 1 use-case for using passkeys).

When using iCloud Keychain to create a passkey, unlike other services, I noticed that Google actually recognises that I’ve used iCloud Keychain to create the Passkey, and labels the Passkey with “iCloud Keychain”.

  • Is Apple sending some additional identifying info in their attestation statement that I’m not sending?

  • If not, how is Google able to identify the passkey provider (in this case “iCloud Keychain”) by name?

  • Could it be that Google has somehow whitelisted iCloud Keychain for Passkey creation, while disallowing third-party providers?

Assuming it is the latter, unfortunately there is no way to reach out to Google about this. I suspect Apple would need to advocate on the behalf of third-party providers running on apple platforms, that they be allowed to provide passkeys for Google sign in.

Its a shame to hit this type of road block so close to the iOS 17 release candidate.

Up vote post of codecomet Down vote post of codecomet
1k views
Posted by
codecomet
Reply
Add a Comment

Accepted Reply

For posterity, @Incogn1to had already run into this issue and rightly pointed out here that the WebAuthn spec requires that the attestationObject‘s dictionary keys be sorted in a specific order. It turns out that Google seem to be the only RP that’s validating this.

I missed that requirement, but I can confirm that using an ordered dictionary has resolved the issue.

Thanks again @Incogn1to and @garrett-davidson!

Posted by
codecomet
Up vote reply of codecomet Down vote reply of codecomet
Post marked as solved
Add a Comment

Replies

Passkeys created in iCloud Keychain don't do anything special for any external services. Also it is currently (intentionally) not possible to create strong allow lists of specific passkey providers, as passkey providers today don't provide any kind of strong identification, not even attestation. (Most passkey providers provide a weak identification, but iCloud Keychain currently does not. Sites can likely weakly identify iCloud Keychain as being the only passkey provider that does not attempt to identify itself.)

If your custom passkey provider is being rejected by certain services, the most likely cause is that your passkey response contains some kind of unexpected information or format. Of the services you mentioned testing, Google is likely doing the strictest validation of the response, so my initial inclination is that there's a subtle issue in your response that the other services aren't checking for.

Unfortunately, debugging something like that is going to be quite difficult 😞. The best advice I can give is to byte-by-byte over the response and compare it with expected values from the spec.

Posted by
garrett-davidson
Up vote reply of garrett-davidson Down vote reply of garrett-davidson
Add a Comment

Thanks for your reply. That's super helpful to know.

I'll check over our implementation and report back here (in case it will help other devs).

I hope it's just an issue with our response as opposed to Google doing some strict or custom validation based on weakly identifying iCloud Keychain + Passkey Provider platform (i.e iOS).

Would be interesting to hear if any other third-party passkey provider devs are successfully creating passkeys for Google accounts, or if they've run into a similar issue as mine?

Posted by
codecomet
Up vote reply of codecomet Down vote reply of codecomet
Add a Comment

For posterity, @Incogn1to had already run into this issue and rightly pointed out here that the WebAuthn spec requires that the attestationObject‘s dictionary keys be sorted in a specific order. It turns out that Google seem to be the only RP that’s validating this.

I missed that requirement, but I can confirm that using an ordered dictionary has resolved the issue.

Thanks again @Incogn1to and @garrett-davidson!

Posted by
codecomet
Up vote reply of codecomet Down vote reply of codecomet
Post marked as solved
Add a Comment

Hey @codecomet

I'm currently running in to the same problem you have listed. I have a passkey provider application that is working everywhere except for google. I can confirm on webauthn.me/debugger that my Attestation object is an ordered CBOR dictionary in the order stated in the answer above (I have also tried other orderings, just in case).

I'm curious if you have found any other possible reasons for why google passkey creation would fail?

All I get is a message saying "Something went wrong. We weren't able to save your changes."

I've tried on safari and chrome. If I try from inside an application on my phone it says "A passkey can't be created on this device".. Even though my device is up to date and I can create passkeys everywhere else.

Thanks for any help on this.

Posted by
DavidPettey
Up vote reply of DavidPettey Down vote reply of DavidPettey
Add a Comment