A cybersecurity firm has successfully implemented WebAuthn redirection in its browser-based Remote Desktop Protocol (RDP) client, allowing users to leverage security keys and other FIDO2 authenticators within remote sessions. This development marks the first RDP client outside of Windows to support WebAuthn redirection, preceding Microsoft's own macOS, iOS, and Linux clients, though the open-source FreeRDP project has since added similar functionality.
The firm's RDP client, integrated into its Prisma Browser, aims to provide native client functionality directly within the browser, addressing limitations of traditional thick clients and HTML5-based remote session hops. The initiative to support security keys arose from a user request to redirect WebAuthn challenges from a remote session to a local machine.
The Microsoft [MS-RDPEWA] specification, detailing the WebAuthn Virtual Channel Extension, describes a dynamic virtual channel named Microsoft::Windows::RDP.Webauthn. This channel allows the server to send CBOR-encoded WebAuthn requests, which the client then processes with a local authenticator before sending back a response. Initially, the specification documented four commands: WEB_AUTHN (for MakeCredential or GetAssertion), IUVPAA (to query for a platform authenticator), CANCEL, and API_VERSION. A subsequent revision, [MS-RDPEWA] 3.0 (March 2026), added GetCredentials (9) and GetAuthenticatorList (12), applicable to Windows 11 24H2+ and Server 2025+ via KB5065789.
A significant challenge emerged from the discrepancy in how client data is handled. When a WebAuthn ceremony is initiated within a remote session, the server intercepts it and sends a 32-byte hash of the `clientDataJSON` over the RDP channel. Standard browser APIs like `navigator.credentials.create()`, however, generate their own `clientDataJSON` with a browser-specific origin (e.g., `chrome-extension://...`), leading to a hash mismatch and signature verification failure when the assertion returns to the relying party.
Reconstructing the `clientDataJSON` on the client side was not feasible due to inconsistencies in browser JSON production, variability in native app SDKs, and the fact that older Windows servers only send the 32-byte hash without the original challenge or origin. No existing browser API could accept a pre-computed `clientDataHash` directly. While the W3C WebAuthn working group has begun standardizing a remoteClientDataJSON extension (editor's draft section 10.1.6), it is not yet implemented in shipping browsers.
To overcome this, the firm developed a custom extension API with `makeCredential()` and `getAssertion()` methods that mirror `navigator.credentials` but allow the direct supply of `clientDataHash` to the authenticator. This approach leverages Chromium's FIDO2 stack for authenticator discovery across USB, BLE, NFC, and platform authenticators, including Cloud-assisted Bluetooth low energy (caBLE)/Hybrid transport for phone-as-authenticator, and integration with Touch ID and Windows Hello.
Unlike native clients that might use `libfido2` to access raw HID devices, a browser-based solution cannot directly access such devices. `WebHID` is limited to USB, excluding platform authenticators or phone-as-authenticator functionality. By wrapping Chromium's FIDO2 stack, the firm avoided the need for a separate native helper outside the browser, which would negate the benefits of an in-browser client.
Despite initial success, the WebAuthn redirection exhibited inconsistent behavior across different Windows server versions. This was traced to the fact that on Windows, browsers, including Chromium, call `WebAuthNAuthenticatorMakeCredential` from `webauthn.dll`, a public API that unconditionally requires the full `clientDataJSON`.
