Closed Bug 1846159 Opened 7 months ago Closed 3 months ago

Passkey registration appears to succeed, but doesn’t


(Fenix :: WebAuthn, defect)



(Not tracked)



(Reporter: mt, Unassigned)



Courtesy of Dick from, who says:

We have replicated an issue where we get a response that a passkey has been successfully registered with Firefox on Android, but when we try to use the passkey, we get an error that there is no passkey for the domain. We work as expected with Chrome and Safari on mobile. (we only support passkey on mobile devices).

Steps to reproduce

  1. Load with Firefox on Android
  2. click [ ō Continue with Hellō ]
  3. Pick any provider to log in
  4. You should be prompted to register a Hellō passkey -- proceed
  5. Complete passkey enrollment with Android
  6. Complete Hellō flow and get sent back to
  7. open in a new tab
  8. Click [ Log Out ] in top right corner
  9. switch back to
  10. logout of
  11. Click [ ō Continue with Hellō ] -- we start a passkey flow on load as we have a cookie that says we have a passkey on this browser
  12. Android will show an error that no passkey was found for

The severity field is not set for this bug.
:jmahon, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(jmahon)

I haven't been able to reproduce this. We don't currently support the creation of passkeys on android---the feature is gated by the pref security.webauthn.webauthn_enable_android_fido2.residentkey, which is off by default. Step 5 fails for me when the pref is off.

On Nightly, I am able to flip the pref, complete step 5, and finish the login to

Having created a passkey, I am also able to log in with the pref off. And I'm able to log in using earlier versions of Firefox.

See Also: → 1831137

Hey, I'm a developer at Hellō. We've encountered this issue on several Android devices.
I was able to replicate it step by step just now on my:
Samsung S8
Android 9
Firefox 116.3.0 (latest)
Biometric: Fingerprint

Please note that although I was able to create the passkey in Firefox (Step 5), no passkeys tied to the domain appeared in the Android passkey manager.

I'm wondering if this has something to do with the Android version (version 9), as that is where passkey support starts.
Let me know if there is anything I can do to assist in diagnosing and resolving this issue.

Additionally, I have checks in place to determine if the device supports passkeys. If this is the case, creating a passkey is prompted (Step 4):

supportsWebAuthn =
    window?.PublicKeyCredential !== undefined && typeof window.PublicKeyCredential === 'function'
platformAuthenticatorAvailable =
    await window.PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()

Interestingly, both of the above conditions return true on my device (Samsung S8 running Android 9, Firefox 116.3.0)
However, this shouldn't ideally be the case, right?

It may be the Android version---I was testing in 13---it might also be the version of Google Play Services. I just tried on Android 9 with GPS 23.31.16 and I was not prompted to register a passkey.

The conditions you list in comment 4 check that the browser is capable of doing WebAuthn with an authenticator that is built into the device (as opposed to, say, a USB key). That's not quite "Passkey support".

WebAuthn PR #1901 proposes an isPasskeyPlatformAuthenticatorAvailable() function. You'll eventually want to use this, but it's not implemented anywhere yet. The PR mentions that "The current developer guidance to relying parties for whether they can offer passkeys to users is to call isUserVerifyingPlatformAuthenticatorAvailable() and isConditionalMediationAvailable()." It goes on to mention some deficiencies with this approach. But the upshot is that, for now, you should be checking isConditionalMediationAvailable() as well.

FWIW we haven't implemented isConditionalMediationAvailable() yet, so this will definitely prevent Firefox users from being prompted to create a passkey.

Alright, thank you for your time and help. We appreciate it! For now, I'll just add the isConditionalMediationAvailable() check, as you mentioned.

Just noticed a similar thing on GitHub, didn't try toggling the pref.

Severity: -- → S3

Hey John, is this still an issue?

Flags: needinfo?(jschanck)
Closed: 3 months ago
Duplicate of bug: 1831137
Flags: needinfo?(jschanck)
Flags: needinfo?(jmahon)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.