search

w3c / webauthn

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

Cross-window `Virtual Authenticator Database` #2117

Open sshmaxime opened 3 months ago

sshmaxime commented 3 months ago

Description

As of now, addVirtualAuthenticator seems to be window restricted (correct me if I'm wrong / inaccurate). Therefore, I need to transfer my credentials from window to window (and more precisely from virtualAuthenticator to virtualAuthenticator). Is this the expected behavior ? If so why is that ?

Related Links

https://www.w3.org/TR/webauthn-2/#sctn-automation-virtual-authenticators

timcappalli commented 3 months ago

@sshmaxime I don't think there's anything in the linked section that specifies this behavior. Is this question more about a specific implementation in a user agent(s)?

sshmaxime commented 2 months ago

@timcappalli Well, all I know is that when creating a virtual authenticator (VA) on Chrome, those VA are window restricted and the so call database is therefore specific to each window. Do you think this is more something on Chrome's side ?

pascoej commented 2 months ago

I think WebKit doesn't attach the virtual authenticator database to the window, but rather the web view associated with the automation session.

I don't see anything at a glance that defines this behavior.

sshmaxime commented 2 months ago

Hey @pascoej, I'm currently running my test on a Chrome instance and didn't had the time yet to check how it works within a WebKit browser but since you mentioned it, it seems that it works the same way in Chrome or WebKit. It's a bit odd imho and makes it hard to develop with it. So this issue would be more browser related if I understood correctly, right ?

nsatragno commented 3 weeks ago

Hello! The standard does not say that the database is per-window, but Chrome implemented it that way to better support the way devtools works. Is there a specific use case that you have in mind that is not served well by the current implementation? If so, please file a bug at https://crbug.com, setting the component to Blink>WebAuthentication.

I will say, we should better specify what the virtual authenticator database is tied to (a webdriver session would be my guess for the correct target).

sshmaxime commented 3 weeks ago

Hey @nsatragno! Here’s the flow I was expecting for my tests using WebDriver.IO:

  1. Setup: Create Virtual Authenticator.
  2. Signup Flow: The user initiates the signup process, which opens a popup window where a new credential is created.
  3. Login Flow: Back in the main window, the user attempts to log in, and the app needs to retrieve and use the credential that was created in the popup window.

Problem: The credentials aren't shared between the two windows. So I had to create one VirtualAuthenticator for each window and had to do some magic to create a synchronized credential store between the two windows.

Solution: Either tie the Virtual Authenticator Database to the WebDriver session or why not just matching the normal Authenticator Database behavior ?

nsatragno commented 3 weeks ago

why not just matching the normal Authenticator Database behavior

We wanted to not share the state of devtools across windows, e.g. maybe you're debugging a site on one tab but want to sign in to your cloud IDE using your real credential on another, so the database is keyed to a hierarchy of frames on Chrome. We could keep that behaviour but only for devtools, and have webdriver affect all windows by default. That would be an improvement: presumably you don't care about having access to real authenticators if you're automating your browser.

This, however, is a Chrome bug and not a standard bug. The right avenue to discuss is https://crbug.com. Please file a bug there, assign me, and set the component to Blink>WebAuthentication.