WebAuthn, OpenID Connect, and OAuth
WebAuthn, OpenID Connect, and OAuth solve different problems in the UbID access layer:
- WebAuthn and FIDO2 provide strong public-key authentication and passkeys.
- OpenID Connect establishes an interoperable authenticated session and communicates identity claims about that session.
- OAuth grants a client bounded authorization to call a protected API.
None of these protocols is a verifiable credential format, DID method, or credential-verification policy.
WebAuthn and passkeys
WebAuthn allows a relying party to register and use public-key credentials created by an authenticator. The private key remains under authenticator control, while the relying party stores public verification material.
Authentication is scoped to the relying party and mediated by the browser or platform. This reduces exposure to password phishing and server-side password compromise.
A passkey deployment must still govern:
- enrollment and account binding;
- authenticator and device lifecycle;
- user presence or user verification requirements;
- synchronization policy where applicable;
- lost-device and recovery handling;
- re-enrollment and credential removal;
- step-up requirements for sensitive operations;
- fallback paths and their evidence.
WebAuthn proves control of an enrolled authenticator. It does not prove that the user's civil identity was correctly established or that a credential presented later should be accepted.
OpenID Connect sessions
OpenID Connect adds an identity layer to OAuth. An OpenID Provider authenticates the user and returns an ID Token and related claims to a client.
In UbID, OIDC can support enterprise federation and application sessions while credential trust remains a separate domain. A successful OIDC login does not automatically prove possession of a particular verifiable credential or authorize every identity operation.
Session design should address issuer validation, audience, nonce, state, redirect validation, token lifetime, logout, reauthentication, and assurance context.
OAuth authorization
OAuth allows a client to obtain an access token for a protected resource under a defined authorization grant. The token should be limited by audience, scope, resource, lifetime, client, and policy.
UbID follows current OAuth security principles, including authorization-code flows, PKCE for public clients, exact redirect matching, protection against code and token replay, bounded token privileges, secure client authentication where appropriate, and rejection of deprecated patterns.
An access token is not a user password, credential, or universal proof of identity. Resource servers must validate it for the intended API and operation.
Complementary use in UbID
A typical interaction may use all three layers:
- WebAuthn authenticates the user to the wallet or portal.
- OpenID Connect establishes an application session.
- OAuth authorizes a client to call a credential or trust API.
- A separate credential protocol issues or presents verifiable evidence.
- A verifier applies credential and transaction policy.
Keeping these layers separate makes responsibilities and evidence easier to review.
Security and privacy considerations
- Do not use authentication claims as a substitute for authorization policy.
- Do not give broad API scopes merely because the user authenticated strongly.
- Do not expose tokens to browser history, logs, referrers, or unrelated origins.
- Do not infer a person's identity from authenticator attestation alone.
- Do not make fallback easier to abuse than ordinary authentication.
- Do not correlate users across relying parties through avoidable identifiers.
- Require fresh authorization or step-up for high-impact operations.
UbID position
Passkeys and server-side authentication policy are part of the implemented UbID baseline. OIDC and OAuth provide reference contracts for federation, session, and API authorization. Exact flows, assurance requirements, identity providers, scopes, and fallback policies are deployment-specific.
Public documentation boundary
The public portal does not publish registered origins, redirect URIs, client secrets, token audiences, private scopes, session configuration, authenticator allow-lists, fallback sequences, or production federation metadata.