iFrame/cross-origin Passkey/WebAuthN authentication does not work for discoverable credentials on Firefox (macOS)

[lxgr]

Steps To Reproduce

This seems to happen for any cross-origin WebAuthN authentication flow (as described e.g. here: https://medium.com/@corbado_tech/webauthn-iframes-integration-for-cross-origin-authentication-d483117cf437) leveraging discoverable credentials where the discoverable credential belongs to the domain of an iFrame.

When the credential ID is provided, everything seems to work normally.

Where I've personally reproduced is using a Link passkey used in the checkout flow at e.g. OpenAI, but I suspect it's a general problem in that Bitwarden only considers passkeys of the currently displayed top-level origin to be eligible for authentication, not those of iFrames embedded with the appropriate permission policy, as described in the linked blog post.

1. Register a passkey on link.com
2. Go to OpenAI and attempt to purchase a ChatGPT Plus subscription.
3. Log out of Link (by clicking the three dot menu, then "Log out of Link")
4. Click "Continue with Link"

Expected Result

Bitwarden prompts usage of a passkey registered to the iframe's domain (assuming that domain's "Permissions-Policy" header also allows it).

Actual Result

The system WebAuthN UI pops up instead and lets me use passkeys stored there, but the one in Bitwarden is ignored.

When the iFrame provides a credential ID, things do seem to work correctly.

Screenshots or Videos

No response

Additional Context

No response

Operating System

macOS

Operating System Version

No response

Web Browser

Firefox

Browser Version

No response

Build Version

2024.8.1

Issue Tracking Info

• I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[JABirchall]

Do you get
Error: Could not establish connection. Receiving end does not exist. trigger-autofill-script-injection.js:5:20
logged in console?

[lxgr]

@JABirchall
I sure do! Seems like this is a known thing then?

[JABirchall]

Yea, seems all autofills are broken.
Related:
#10814
#10815

This is the first report of 2fa being effected, but good for collecting the scale of effect. You should change your title to "Two-Factor auth autofill is not working" Or something along those lines, as thats the actually issue, nothing to do with if its an iframe or not.

[lxgr]

Oh, you're right, it doesn't even work for first-party WebAuthN anymore either 🤦‍♂️ Sorry, I should have checked that first!

Once that's fixed, I can check again to see if this particular use case also works (again).

[lxgr]

Ok, for whatever reason it's now semi-working, without me having changed anything on my system (same extension version, same Firefox version).

Now when I click "continue with Link", the macOS native WebAuthN UI still pops up once. But when I dismiss it, and then click "log in with a passkey", the Bitwarden UI does show up and lets me proceed!

What I suspect could be happening is that the iFrame first queries for discoverable credentials and finds none (falling through to the system UI), but then provides a credential ID (at the point I can click "log in with a passkey", my email address is displayed, so the iFrame probably also has the credential ID available by then), which Bitwarden then does recognize.

Maybe this is intended behavior for security reasons, but it's at least a discrepancy with the system implementation: When I add an iCloud passkey to Link, the sign-in does work at the first step (presumably the one using the discoverable credential).

tl;dr: I believe discoverable credentials do not work in iFrames at the moment, unlike for the Firefox native implementation (leveraging macOS's backend); non-discoverable ones do. I'll change the title to reflect this.

[cbbit]

Hi there,

Thank you for your report! It has been escalated for further investigation. If you have more information that can help us, please add it below.

Thanks!