WebAuthn Passkeys in Enterprise SSO — Protocol Mechanics, IdP Integration, and Real Adoption Challenges

Passkeys have crossed from early-adopter territory into mainstream enterprise IAM. The FIDO Alliance reports over one billion FIDO2 authentications per month — a 400% growth since 2023 — and every major identity provider (Okta, Microsoft Entra ID, Ping Identity, Google Workspace) now ships passkey support. The hard part is no longer whether to adopt them. It is understanding exactly where WebAuthn terminates and where your existing federation layer begins, and how to close the gap between the two.

Passkeys in Enterprise SSO Diagram — Diagram — Passkeys in Enterprise SSO

How Passkeys Sit Inside an Enterprise SSO Architecture

WebAuthn is a client-to-relying-party authentication protocol. It is not a federation protocol. It produces a signed assertion that proves possession of a private key bound to an origin — it does not produce SAML assertions or OIDC ID tokens. The correct enterprise deployment pattern is therefore a composition: a passkey authenticates the user to the Identity Provider (IdP), and the IdP issues OIDC tokens or SAML assertions to downstream applications via SSO in the normal way.

This means the overwhelming majority of enterprise applications do not need to implement WebAuthn at all. They continue consuming federation tokens from the IdP. Only the IdP's authentication surface changes. The FIDO Alliance's own technical guidance is explicit: FIDO is complementary to, not a replacement for, SAML and OIDC.

The architectural boundary matters when examining acr and amr claims. When an application acting as an OIDC relying party needs assurance that the user authenticated with a phishing-resistant factor, it should inspect the amr claim for values like hwk (hardware key) or user (user verification), or the acr claim for the configured assurance level. If the IdP does not populate these claims precisely, the downstream application cannot programmatically distinguish a passkey authentication from a password-plus-TOTP one. This is a concrete, often-missed integration gap. It is also directly covered in ASVS 5.0 V6 and V7, which requires applications relying on an external IdP to verify the returned authentication context claims.

The Registration and Authentication Ceremonies

At the protocol level, WebAuthn defines two ceremonies. Understanding both is necessary before writing a line of IdP integration code.

Registration begins with the server generating a PublicKeyCredentialCreationOptions object that includes a random challenge (minimum 16 bytes from a CSPRNG), the RP ID (tied to the origin), and a user handle. The browser hands this to navigator.credentials.create(), which invokes the platform authenticator. The authenticator generates an EC P-256 or RS256 key pair, stores the private key in the secure enclave, and returns an attestationObject containing the authenticator data and, optionally, a signed attestation statement.

In TypeScript (client side):

const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge, // Uint8Array, 16+ bytes from CSPRNG
    rp: { id: "auth.corp.example", name: "Corp SSO" },
    user: { id: userHandle, name: email, displayName: displayName },
    pubKeyCredParams: [
      { type: "public-key", alg: -7 },  // ES256
      { type: "public-key", alg: -257 }, // RS256
    ],
    authenticatorSelection: {
      residentKey: "required",
      userVerification: "required",
    },
    attestation: "direct", // or "none" for synced passkeys
  },
}) as PublicKeyCredential;

The server must then verify the attestation: parse the clientDataJSON to confirm the origin matches and the challenge was consumed, decode the authData to extract the AAGUID, credential ID, and public key, and validate the attestation signature against the FIDO Metadata Service (MDS3) if attestation was requested.

In Go (server side, using go-webauthn/webauthn):

webAuthn, _ := webauthn.New(&webauthn.Config{
    RPID:          "auth.corp.example",
    RPDisplayName: "Corp SSO",
    RPOrigins:     []string{"https://auth.corp.example"},
})

// Begin registration
creationOptions, sessionData, err := webAuthn.BeginRegistration(user,
    webauthn.WithResidentKeyRequirement(protocol.ResidentKeyRequirementRequired),
    webauthn.WithUserVerification(protocol.VerificationRequired),
)
// Store sessionData; send creationOptions to browser as JSON.

// Finish registration
credential, err := webAuthn.FinishRegistration(user, *sessionData, request)
// Persist credential.ID and credential.PublicKey; discard sessionData.

Authentication follows the same shape: server issues a challenge via BeginAuthentication, browser calls navigator.credentials.get(), the authenticator signs the challenge with the private key, and the server verifies the signature and increments the stored signCount to detect cloned credentials.

Synced vs. Device-Bound — The Attestation Trade-off

Enterprise teams quickly discover that the passkey credential type decision is not purely a security choice — it is a governance and usability trade-off with direct policy implications in every major IdP.

Synced passkeys (stored in iCloud Keychain, Google Password Manager, or an enterprise credential manager like 1Password Business) are convenient and resilient to device loss, but they generally cannot provide hardware attestation. Synced passkeys are software-backed: the key material can move between devices under the sync provider's access controls. In Entra ID, enabling attestation enforcement automatically excludes all synced passkeys. Synced passkeys are appropriate for general workforce access at AAL2.

Device-bound passkeys (stored in the device's TPM or Secure Enclave, or on a FIDO2 roaming authenticator like a YubiKey) do provide hardware attestation. The AAGUID in the attestation object maps to a certified authenticator model in FIDO MDS3, allowing the relying party to verify exactly which hardware generated the credential. These are appropriate for privileged accounts and AAL3 scenarios. Administrators should use device-bound credentials exclusively.

The attestation enforcement conflict is a real deployment blocker. Synced passkeys from iCloud Keychain or Google Password Manager do not sign a hardware batch certificate, so they cannot satisfy an attestation check. An Entra ID tenant that enables "Enforce attestation" will reject synced passkeys at registration — a non-obvious failure mode for users trying to register from their iPhone.

Real Adoption Friction Points

Several deployment issues appear consistently across enterprise rollouts:

The Conditional Access bootstrap paradox. Enabling a Conditional Access policy requiring phishing-resistant MFA before users have enrolled a passkey blocks access to the Security Info registration portal itself. The fix is issuing a Temporary Access Pass to users prior to enforcement, allowing them to complete initial enrollment without triggering the policy.

Cross-device authentication and corporate network policies. The CTAP2 cross-device flow (scanning a QR code on a desktop to use a mobile phone as an authenticator) relies on a Bluetooth proximity check and a WebSocket connection to cable.auth.com. Corporate firewalls and Zscaler-style proxies routinely block one or both, causing silent authentication failures. This needs to be explicitly tested and either allowed or documented as unsupported.

B2B guest users. Entra ID does not support guest users registering FIDO2 credentials in a resource tenant. The correct pattern is to configure Cross-Tenant Access Settings to trust phishing-resistant MFA claims from the guest's home tenant, rather than attempting to re-register credentials.

WebViews in native apps. Embedded WebViews in enterprise mobile apps do not have access to platform passkey APIs. The correct approach is ASWebAuthenticationSession on iOS and Android Custom Tabs, which invoke the system browser and its full FIDO2 stack.

SAML RequestedAuthnContext interference. When an SP sends a SAML AuthnRequest that includes a RequestedAuthnContext element specifying password-class authentication, the IdP may refuse to complete the flow with a passkey. The Microsoft documentation is explicit: if you are using SAML federation to a passkey-enabled IdP, do not specify a required authentication context that constrains the method to passwords.

These are not edge cases. They each represent a category of user that will be blocked until the issue is explicitly resolved — and they are the kind of issues that surface after a phased rollout has already started.

What a Clean IdP-Centric Passkey Integration Looks Like

A minimal but correct enterprise passkey flow routes all WebAuthn complexity to the IdP and keeps applications as standard OIDC consumers:

The IdP hosts the WebAuthn relying party (a single RP ID, e.g. login.corp.example).
Users register passkeys against the IdP — once, regardless of how many applications they access.
Applications initiate an OIDC authorization code flow (with PKCE, as covered in PKCE Demystified) to the IdP.
After successful passkey authentication, the IdP issues an ID token with amr: ["hwk", "user"] and sets acr to the configured assurance level.
Applications verify the acr or amr claims before granting access to protected resources. Absence of these claims should default to the lowest assumed assurance, per ASVS guidance.

Legacy SAML applications that cannot be migrated to OIDC continue receiving SAML assertions from the same IdP without any WebAuthn awareness. The phishing resistance is already embedded in the IdP's authentication event; no changes are required to the SP.

If you are building or reviewing an identity stack that needs to incorporate passkeys into an existing SSO environment, Reverse Polarity's Authentication & Identity Code Review covers the full WebAuthn implementation — ceremony verification logic, credential storage, amr/acr claim handling, and federation layer integration — so the move to phishing-resistant authentication does not introduce new protocol-level gaps.

WebAuthn Passkeys in Enterprise SSO — Protocol Mechanics, IdP Integration, and Real Adoption Challenges

How Passkeys Sit Inside an Enterprise SSO Architecture

The Registration and Authentication Ceremonies

Synced vs. Device-Bound — The Attestation Trade-off

Real Adoption Friction Points

What a Clean IdP-Centric Passkey Integration Looks Like

Sources

More Articles

LangChain, LangGraph, and LlamaIndex — Which Tool Do You Need, and When

OWASP Top 10 for LLM Applications — Explained with Examples

The Standard That Actually Defines Secure Web Applications — OWASP ASVS 5.0