WebAuthN / FIDO2 / Passkey redirection failure on RDM Mac OS

Hello

Thanks for the issue report, although I fear this might actually be a feature request. WebAuthN redirection in embedded RDP on RDM Mac is supported through FreeRDP's WebAuthN stack.

Are you using an external FIDO2 authenticator like a USB/NFC/BLE security key (where the passkey is stored on the key)? Or are you using macOS's built in platform authenticator (i.e. TouchID / Cloud Keychain passkeys)?

I know you wrote about the issue with physical Yubikeys with Windows App, but I'm not sure if that's what you're trying with RDM.

Thanks and kind regards,

Hello

Thanks for the issue report, although I fear this might actually be a feature request. WebAuthN redirection in embedded RDP on RDM Mac is supported through FreeRDP's WebAuthN stack.

Are you using an external FIDO2 authenticator like a USB/NFC/BLE security key (where the passkey is stored on the key)? Or are you using macOS's built in platform authenticator (i.e. TouchID / Cloud Keychain passkeys)?

I know you wrote about the issue with physical Yubikeys with Windows App, but I'm not sure if that's what you're trying with RDM.

Thanks and kind regards,

@Richard Markiewicz

Hi,

Thanks for your reply. I hope you can excuse my lack of knowledge surrounding what functionality is provided by RDM itself rather than underlying dependencies.

I'm using external FIDO2 authenticators, specifically I use a YubiKey 5C, and I also have Microsoft Authenticator Android app configured as a passkey provider. I am not using the macOS built-in TouchID / Cloud Keychain for this purpose. But as far as I can tell, the authentication request never reaches my Mac, and gets stuck within the RDP session.

Additionally, fwiw, I've now upgraded to RDM to version 2026.3.1.2, and the behavior is the same.

I have also of course under the Session Properties > General > RDP > Local resources enabled the setting for redirecting "WebAuthN (Windows Hello or security keys)", as well as the "Smart cards or Windows Hello for Business" options.

Best regards,

Viktor

Thanks for the instructions, Richard!

I reproduced the scenario with logging enabled and it helped me better understand the situation myself.

Your initial reply seems to be correct as in so much that it's really FreeRDP's WebAuthN implementation rather than RDM:s redirection configuration

I traced it to being introduced in this PR: https://github.com/FreeRDP/FreeRDP/pull/12572.

FreeRDP implements the RDP WebAuthn virtual channel ( MS-RDPEWA ) and uses libfido2 to communicate with local FIDO2 authenticators. It does not appear to use Apple’s native AuthenticationServices APIs. In practice, the current implementation detects external authenticators, such as a USB YubiKey, that are present when FreeRDP enumerates devices for the request.

In my original test, no security key was connected. The log showed that the  WebAuthN_Channel  was created successfully, but FreeRDP reported:

IUVPAA: ndevs=0 available=0

This explains why it failed for me: RDM:s redirection was active but FreeRDP found no local authenticator. Unlike the native macOS WebAuthn experience, it did not display a system UI that allowed me to connect a security key after the request had begun or use cross-device authentication through the hybrid/QR-code flow.

When I connect my YubiKey before initiating authentication, RDM correctly prompts me for the key’s PIN and asks me to touch it. However, I encounter a second issue during a usernameless passkey flow.

My YubiKey contains multiple discoverable credentials for the same relying party ID. When I initiate authentication without first entering a username, I am not shown an account or credential chooser, and the authentication eventually fails.

If I first enter my username at login.microsoftonline.com and then select passkey authentication, the flow succeeds. In that username-first flow, Microsoft can include the credential ID associated with the account in the WebAuthn allowCredentials list, so FreeRDP/libfido2 does not need to support selection among multiple discoverable credentials.

So in summary my troubleshooting leads me to this conclusion.

The supported scenario is seemingly:

• An external FIDO2 authenticator is already connected and visible to FreeRDP/libfido2 when the WebAuthn request is processed.

• The relying party uses a username-first flow and supplies the applicable credential ID

Some unsupported scenarios are seemingly:

• Connecting an external authenticator after the WebAuthn request has already been processed.

• Cross-device authentication using WebAuthn hybrid transport, such as scanning a QR code and authenticating with a phone.

• Usernameless authentication when multiple discoverable credentials for the same RP ID are stored on a PIN-protected authenticator, because no credential/account selection UI is presented

Untested: macOS native platform passkeys stored in iCloud Keychain. this may also be non-functional and dependent on Apple's native API:s.

I can still provide logs to you if they are of interest, but I think as far as RDM:s involvement in this goes it's cleared up, and the limitations are mostly in the FreeRDP implementation.

Maybe RDM could catch the error logged regarding lack of available authenticators "[com.freerdp.channels.rdpewa.client] - [rdpewa_fido_is_uvpaa]: IUVPAA: ndevs=0 available=0" and prompt the user that an attempt was made but no authenticators were available, rather than failing silently. Or we're probably talking an entire override of the FreeRDP implementation and doing your own integrating with the platform/OS native API:s for passkey authentication instead.

Best regards,

Viktor

Hi Viktor

Thanks, your assessment is accurate and the logs aren't needed. The supported scenario (currently) is correct.

In terms of:

• Connecting the authenticator after the WebAuthN request has been processed

• Username less authentication with multiple discoverable credentials are stored on the authenticator

These would be fairly straightforward additions on the FreeRDP side. They're not limitations of the underling libraries, they're just not implemented. As I recall, WebAuthN was contributed to FreeRDP by a third party and it was probably "complete" enough for that implementer, who probably didn't need these features. It would be a moderate library, API and UI change, not a big architectural change or a rewrite.

In terms of:

• Cross device authentication

• Platform native passkeys

Again, it's possible but these are a bigger ask. Because for these features, platform specific APIs must be used. In terms of Apple, the platform APIs are well understood but there is a extra challenge in translating between the CTAP-style data / authenticator responses expected by RDPEWA and the higher level request / responses expected by Apple. Not impossible, but a much bigger chunk of work.

Your last point about catching the error for no available authenticators is a good one. It's not possible right now, but probably a long hanging change on the FreeRDP side so I'll investigate that. In parallel I'll see how straightforward the other "easy" jobs are. The platform specific items are a bigger ask but let's tackle the easier items first. I make no guarantee for timelines, but I will open a ticket and give some information back in this thread as it comes up.

If any of these features are very important to you, you may pursue it independently with FreeRDP. Although I doubt the maintainers would work on this directly but they would certainly invite contributions, and there's always scope to sponsor development for such a project.

Please, let me know if you have any questions or something isn't clear

Best regards,