Overview
WebAuthn, FIDO2, OIDC, SAML, and SCIM often appear in the same sign-in architecture, but they solve different problems at different layers. Treating them as interchangeable creates gaps: an application can have SSO without phishing-resistant authentication, SCIM deactivation without immediate session termination, or a passkey at the identity provider while the downstream application knows nothing about WebAuthn.
A mature workforce identity architecture composes the layers. WebAuthn and FIDO2 govern how an account authenticates. OIDC or SAML carries an authentication result and identity claims to an application. SCIM creates and updates identity resources. The application still enforces authorization and manages its own sessions.
The one-line version of each standard
| Standard | Layer | What it does | What it does not do |
|---|---|---|---|
| WebAuthn | Relying party and client-platform API | Requests and verifies public-key credential registration and authentication ceremonies scoped to a relying party | Does not define federation, provisioning, application authorization, or general session management |
| FIDO2 | Standards family | Combines WebAuthn with CTAP between a client platform and external authenticator to support phishing-resistant public-key authentication | Is not a federation or provisioning protocol and is not itself a user-interface element |
| OpenID Connect | Federated authentication | Adds an identity layer to OAuth 2.0 so a client can verify an authentication event and receive claims in an ID Token | Does not prescribe how the OpenID Provider authenticated the user or how the application provisions the account |
| SAML 2.0 | Federation and web SSO | Uses XML assertions and protocol messages to communicate authentication, attributes, and related security statements between trusted parties | Does not itself perform the user's upstream authentication or provision the application account |
| SCIM 2.0 | Identity lifecycle | Uses HTTP resources and schemas to create, retrieve, update, and deactivate users, groups, and related identity data | Does not authenticate an end user, define application authorization, or guarantee termination of an active session |
How the layers work in a deployment
- 1. Provision the account. A SCIM client creates or updates the user's account and group assignments in the target application, if the application supports the required SCIM operations and attributes.
- 2. Start application access. The user opens the application, which determines that authentication should be delegated to a trusted identity provider.
- 3. Initiate federation. The application sends an OIDC authorization request or SAML authentication request, according to the protocol and profile it supports.
- 4. Authenticate at the identity provider. The identity provider may use WebAuthn/FIDO2 to verify a fresh, relying-party-bound assertion from a passkey or security key. A device-bound passkey keeps its private key in one authenticator; a synced passkey may replicate protected key material through its provider.
- 5. Validate the federation response. The application validates the OIDC ID Token or SAML response, including issuer, audience, signature, time constraints, request correlation, and other protocol-specific requirements.
- 6. Create the application session. The application maps the federated subject and claims to a local account, applies authorization, and issues its own session. Session lifetime, revocation, and logout remain application concerns.
- 7. Handle lifecycle changes. SCIM can disable or update the application account, but the deployment must separately verify entitlement removal and termination of active sessions.
Where each standard fits
- Authentication ceremony: WebAuthn and FIDO2. The authenticator signs a fresh challenge for the relying party. WebAuthn carries the RP ID and origin context that the server validates, while CTAP allows a client platform to communicate with an external authenticator. During authentication, the private key is not sent to the relying party.
- Application federation: OIDC or SAML. These standards let an application rely on an authentication event performed by an identity provider. OIDC is common in modern web and native applications; SAML remains widely used for enterprise web SSO. Compatibility is the first filter, followed by the exact profile, security controls, and implementation quality.
- Lifecycle automation: SCIM. SCIM standardizes HTTP operations and schemas for resources such as users and groups. It can reduce manual onboarding and deprovisioning, but mappings, downstream enforcement, retries, partial failures, and session termination still require operational validation.
Common mistakes before rollout
- Treating SSO as proof of strong authentication. OIDC or SAML can federate an authentication event produced by a weak or strong upstream method. Require and verify the assurance appropriate to the application.
- Using OAuth 2.0 alone as identity proof. OAuth is an authorization framework. OpenID Connect adds authentication semantics, an ID Token, and standardized identity claims.
- Assuming FIDO2 support is binary at the application layer. An application may support WebAuthn directly, rely on an upstream identity provider that supports it, or lack a compatible path. Test the actual end-to-end flow per application.
- Assuming a synced passkey never leaves one device. Device-bound credentials remain in one authenticator. Synced passkeys intentionally replicate protected key material through a credential provider while retaining phishing resistance.
- Skipping SCIM because the team is small. Manual lifecycle work can create deprovisioning delays and orphaned access regardless of headcount. Evaluate failure handling and evidence, not only successful provisioning.
- Assuming SCIM deactivation ends every session. Disabling a user record does not guarantee immediate revocation of existing cookies or tokens. Confirm the target application's session behavior and available revocation controls.
- Treating SAML versus OIDC as only a branding choice. Start with compatibility, then assess flow and profile support, redirect and audience validation, signing and encryption, key rotation, claims, logout, and session behavior. Neither protocol name guarantees a secure deployment.
What to evaluate
- Authentication strength. Which upstream methods are allowed, how phishing resistance is enforced, and how the application receives or requests authentication context or assurance.
- Federation coverage. Which applications support OIDC, SAML, both, or neither, and which exact flows, bindings, profiles, signing algorithms, and logout mechanisms are implemented.
- Identity correlation. How stable subject identifiers, NameIDs, email addresses, and account-linking rules prevent duplicate or misbound accounts.
- Claims and attributes. Which identity and group data is released, minimized, transformed, signed, encrypted, and used for application authorization.
- Provisioning behavior. Which SCIM resources and operations are supported, how groups and entitlements map, how retries and partial failures work, and how quickly deactivation reaches the application.
- Session controls. How applications establish, renew, revoke, and terminate sessions after federation—and whether deprovisioning or identity-provider risk events affect existing sessions.
- Audit evidence. Whether registration, authentication, federation, provisioning, authorization, deactivation, and session-revocation events can be correlated during an investigation.
How this maps to Gideon Identity
Gideon Identity uses WebAuthn and FIDO2 for phishing-resistant workforce authentication, supports OIDC and SAML federation for compatible applications, and uses SCIM where supported to automate application lifecycle changes. The exact deployment depends on each application's protocol capabilities, mappings, and session controls; support for one layer should not be treated as proof that every other layer is covered.
Related reading
- Start with the Passkeys for Workforce Identity: Buyer's Guide for deployment models, recovery, and evaluation criteria.
- Compare credential, device, and session controls in Device-Bound Authentication vs Conventional MFA.
- Review registration and lifecycle evidence in Trusted Authenticator Lineage.
- Understand platform key protection in How Secure Enclave and TPM Change Workforce Access.
- Explore Gideon Identity for product capabilities and evaluation paths.
Primary references
- The FIDO Alliance describes FIDO2 as WebAuthn plus CTAP and distinguishes synced from device-bound passkeys in its passkey guidance.
- The OpenID Foundation defines OIDC authentication and ID Tokens in OpenID Connect Core 1.0.
- OASIS defines SAML assertions, protocols, profiles, and authentication context in the SAML 2.0 Technical Overview.
- The IETF defines SCIM's HTTP operations and resource-management model in RFC 7644.
How to use this resource
Use this field guide to assign each requirement to the correct layer, inventory application capabilities, and define measurable acceptance criteria for authentication, federation, provisioning, authorization, and session lifecycle before rollout.