Not sure if any of below might be useful, but this is what AI provided.
***************
You’ve hit on a tricky one — getting a hardware token like a YubiKey (or any FIDO2/U2F device) to work reliably with a SAML‑based Remote Access VPN setup often involves a number of subtle gaps in client side behaviour, IdP/SP configuration and VPN client/embedded browser support. I’ll walk through what I know (and what to check) so you can debug your environment more effectively — and I’d be happy to dig into your exact stack (VPN vendor, OS, IdP) if you want.
✅ What should work & how people are doing it
Here are several reference case‑studies and approaches that show that YubiKey + SAML + VPN can work — and what the functional path looks like.
-
For example, Yubico has a detailed guide for integrating YubiKey with a Cisco ASA VPN via SAML with OAuth/FIDO2:
-
Approach 1: YubiKey FIDO2 + Azure AD as IdP, Cisco ASA as SP. The client (e.g., AnyConnect) mustlaunch the system default browser (not embedded) because embedded browser may not support the FIDO2 handshake. (Yubico Support)
-
They also document other approaches (TOTP stored on YubiKey, smart‑card/PIV mode) for different vendor support. (Yubico Support)
→ This shows that with the right browser path, YubiKey + SAML + VPN is valid.
-
With Yubico and a generic SSO/SAML vendor: The 2012 press release shows YubiKey integration with SAML/SSO solutions. (Yubico)
→ Suggests the concept is decades old and technically feasible.
-
More specific example: With OpenVPN CloudConnexa + SAML, YubiKey support is explicitly referenced: “If your IdP supports YubiKeys — you will be able to use YubiKey, without any issues.” (OpenVPN Support)
→ Good evidence that typical SAML+VPN stacks support Yubikey if configured right.
⚠️ What many people run into (and likely your issue)
Despite the success stories, there are common obstacles:
-
Embedded browser vs external browser: Many VPN clients use an embedded browser (or WebView) for SAML redirection. These embedded browsers often do not support WebAuthn/FIDO2/U2F flows, or have limitations (e.g., restricted pop‑ups, limited USB/CTAP access). For example:
“Webview for SAML does not allow Duo to use a YubiKey U2F token because popups are blocked.” (Launchpad)
→ If your client uses the embedded view, the YubiKey tap may never register.
-
Client/OS support for FIDO2/U2F: For a YubiKey to work as a FIDO2 security key, the browser must support CTAP and security‑key APIs, the OS must allow USB access, and the VPN flow must redirect to that browser. Some older VPN clients force redirect to a browser that doesn’t support it (e.g., IE11, embedded WebKit). For instance, the SAML support doc for Check Point states:
“Supported web browsers are the VPN client’s embedded browsers and Internet Explorer 11 (the latest version).” (Checkpoint)
→ IE11 + embedded browser = likely no full WebAuthn.
-
IdP configuration to allow YubiKey as second‑factor in SAML flow: Even if the YubiKey is enrolled in your IdP, the SAML flow might only present certain MFA options (push, SMS, TOTP) depending on policy. If the YubiKey isn’t enrolled or allowed in the policy presented for that VPN application, you may not get the “Use security key” prompt.
-
VPN flow chaining the SAML login: Some VPN clients perform a primary password login, then pop‑up a SAML window. That window might not be in focus or accept keyboard/USB input (YubiKey participation). A Reddit thread noted the YubiKey OTP insertion lost focus when the window changed. (Reddit)
-
Multiple “factors” in the same login option: Some VPNs or SPs might impose “Single factor + YubiKey” or only permit YubiKey under certain conditions. The Check Point doc states under limitations:
“SAML authentication cannot be configured with more authentication factors in the same login option.” (Checkpoint)
→ That means you might need to setup the IdP to require the YubiKey as the factor (or part of the IdP side) rather than expecting the VPN client to handle it.
-
USB recognition / focus / peripheral redirection: In some cases (especially with virtualization, remote sessions, non‑USB keys) the device may not be seen. Troubleshooting can show the YubiKey is recognized by OS but not by the browser or window causing the SAML flow.
🧪 Checklist / what to verify in your setup
Given your scenario (“YubiKey won’t work with the SAML authentication window that pops up after the initial auth for remote access VPN”), here’s a checklist to walk through:
-
VPN client config
-
Does your VPN client launch the system default browser (e.g., Chrome, Edge) for the SAML step, or does it embed a browser/webview?
-
If embedded, can you switch it to external browser mode? Many vendors support this as a setting (for FIDO2 support).
-
Ensure that in your connection profile/browser redirect settings you can handle WebAuthn / security key flows.
-
Browser & OS support
-
On the client machine where you test, confirm that the default browser supports FIDO2 / WebAuthn (recent Chrome, Edge, Firefox should).
-
Insert YubiKey and use it in some other site that uses “security key” to confirm it is working in that browser.
-
If using a remote environment/VM/USB redirection, ensure the YubiKey is properly passed through.
-
IdP / SAML application flow
-
In your IdP (Azure AD, Okta, PingID, etc.), verify YubiKey is enrolled for the user and allowed for the VPN application.
-
Confirm the VPN application’s policy allows “security key / FIDO2” as an MFA option.
-
If the SAML login window appears but doesn’t show “Use a security key”, that’s a sign IdP policy is lacking or the browser flow is broken.
-
VPN/SP SAML configuration
-
On the VPN gateway/SP side, check that it supports FIDO2 / security key flows via SAML. Some only support TOTP or OTP.
-
If documentation states “only supports IPsec, not SSL” or “embedded browser only”) note these limitations (see Check Point doc). (Checkpoint)
-
Ensure the SP initiates SAML correctly and sends the right redirect parameters.
-
Focus / UI issues
-
When the YubiKey window appears, make sure the input field is active (cursor blinking) and the YubiKey is tapped correctly.
-
Check for pop‑up blockers, browser extensions, or WebView focus issues.
-
Try using a browser manually (outside VPN client) to access the IdP login and use YubiKey — if that works, the problem is likely the VPN client’s embedded browser flow.
-
Logs and errors
-
Check VPN client logs for SAML / authentication errors.
-
On the IdP side check authentication logs: do you see an attempted “security key” challenge, or is it skipping to another MFA method?
-
On the client OS side, check for browser console errors if you can open the login flow inside a full browser and inspect.
🤔 Some likely diagnosis in your scenario
Based on the symptoms (“YubiKey won’t work with the SAML window after initial auth”), some probable causes:
-
The SAML login window is using an embedded browser/webview which does not support FIDO2 / CTAP, so the security key tap is simply ignored.
-
The IdP policy for that VPN application doesn’t allow “security key / YubiKey” as an MFA method (or fallback is defaulting to SMS/app) so you never see a “Tap your key” prompt.
-
The YubiKey enrollment for that specific user or that VPN application isn’t done or allowed (so though the key works in other contexts, not here).
-
Focus or USB redirection issue: the YubiKey is tapped but the window is not active, so the OTP/response doesn’t go into the right field or isn’t captured.
-
VPN/SP limitations: The SP (VPN gateway) may only support certain MFA methods via SAML (e.g., TOTP) and may not support full WebAuthn U2F flows.
If you like, I can check specific compatibility for your vendor (if you tell me: VPN vendor/model, OS (Windows/macOS), IdP (Azure AD, Okta, PingFederate etc)) and we can see exactly whether your version supports YubiKey via SAML and what configuration steps are needed (or missing).
Best,
Andy
