Palo Alto Networks’ Unit 42 team has published a detailed account of how they implemented WebAuthn redirection inside a browser-based RDP client, claiming to be the first RDP client outside of Windows to support the feature. At the time the work was completed, Microsoft’s own macOS, iOS, and Linux clients lacked this capability. FreeRDP has since added support as well.
The Problem: Security Keys Over RDP
The effort began with a straightforward user request: when a remote session user visits a site that prompts for a hardware security key (such as a YubiKey), can that authenticator request be redirected to the user’s local device? Microsoft has a protocol for exactly this scenario, documented as [MS-RDPEWA], the WebAuthn Virtual Channel Extension. The spec describes a dynamic virtual channel named Microsoft::Windows::RDP.Webauthn that carries CBOR-encoded WebAuthn requests between server and client across four defined commands: credential creation or assertion, platform authenticator detection, operation cancellation, and version negotiation.
Why the Browser API Falls Short
The obvious implementation path, calling navigator.credentials.create() from the browser extension, runs into a fundamental cryptographic problem. When a user triggers WebAuthn inside a remote session, the server intercepts the ceremony and computes a clientDataHash as the SHA-256 of a clientDataJSON object containing the remote page’s origin (for example, https://okta.com). It sends only that 32-byte hash over the RDP channel.
The browser’s native WebAuthn API constructs its own clientDataJSON with the extension’s own origin (chrome-extension://...), hashes that, and hands it to the authenticator. The resulting signature covers a different hash than the server expects, causing verification to fail at the relying party. Because SHA-256 is a one-way function, there is no way to reverse or reconcile the mismatch after the fact.
Reconstructing the original clientDataJSON from known ingredients is also not viable: browsers do not produce byte-identical JSON for the same inputs, native SDK implementations add further variability, and older Windows servers transmit only the 32-byte hash with no cleartext origin or challenge.
The team also evaluated several other browser APIs, including chrome.webAuthenticationProxy, remoteDesktopClientOverride, and WebHID, and found each unsuitable for this specific use case.
A Custom API and Reverse Engineering
The solution was to build a custom extension API exposing makeCredential() and getAssertion() methods that accept a pre-computed clientDataHash and pass it directly to the authenticator, bypassing the browser’s own JSON construction step. Implementing this correctly required reverse-engineering Microsoft’s Windows WebAuthn stack, because the spec was incomplete and the Windows implementation routes through internal, undocumented code paths.
The team used IDA Pro for the reverse-engineering work. They note that AI tooling, specifically an IDA Model Context Protocol bridge, significantly accelerated the process from what would previously have taken several days down to a matter of hours. The researchers are careful to note, however, that AI did not do the core analytical work. Knowing the right questions to ask, validating outputs, setting breakpoints, comparing traces, and proving protocol behavior end to end still required human expertise.
Spec Gaps and Forward Progress
The [MS-RDPEWA] specification was incomplete at the time of the work. A March 2026 revision (version 3.0) has since documented two additional commands, GetCredentials (command ID 9) and GetAuthenticatorList (command ID 12), gated to Windows 11 24H2 and Server 2025 via a specific update package.
On the standards side, the W3C WebAuthn working group has begun drafting a remoteClientDataJSON extension that would eventually standardize the pre-computed hash use case in browsers natively. That extension is not yet present in any shipping browser, making the custom API approach the only viable path for now.