OAuth 2.0, OpenID Connect, and WebAuthn
OAuth 2.0, OpenID Connect, and WebAuthn
How Modern Authentication and Authorization Actually Fit Together
Summary: OAuth 2.0, OpenID Connect (OIDC), and WebAuthn are often discussed together, but they solve fundamentally different problems. Confusion arises when they are treated as competing technologies rather than complementary layers. This article explains how OAuth 2.0 handles authorization, how OIDC adds identity and authentication semantics, and where FIDO2 / WebAuthn fits cleanly as a modern, phishing-resistant authentication method within that stack.
Context
Modern systems rarely authenticate users directly. Instead, authentication, identity, and authorization are intentionally split across components:
- Applications no longer want to handle passwords
- APIs need scoped access without user credentials
- Authentication strength needs to vary by context and risk
- Passwordless and phishing-resistant mechanisms are now practical
OAuth 2.0, OIDC, and WebAuthn exist because no single mechanism solves all of these concerns cleanly.
OAuth 2.0: Delegated Authorization
OAuth 2.0 is not an authentication protocol. It is a framework for delegating access to resources.
In simple terms:
- “This application may do these specific things on my behalf.”
Core OAuth Concepts
- Resource Owner – the user
- Client – the application requesting access
- Authorization Server – issues tokens
- Resource Server – the API being accessed
OAuth introduces access tokens that are time-limited, scope-bound, and revocable.
OpenID Connect: Adding Identity
OpenID Connect (OIDC) is a thin identity layer built on OAuth 2.0.
OAuth answers:
- “What is this client allowed to access?”
OIDC answers:
- “Who authenticated, how, and when?”
What OIDC Adds
- ID Tokens (JWTs)
- Standard identity claims (sub, iss, aud, exp)
- Authentication semantics
- Profile and assurance signalling
OIDC standardises login without redefining OAuth itself.
Authentication Remains Abstract
Neither OAuth nor OIDC defines how authentication occurs.
They do not mandate:
- Passwords
- OTPs
- Biometrics
- Hardware keys
They only require that authentication has succeeded before tokens are issued.
WebAuthn: Authentication, Not Identity
WebAuthn is a cryptographic authentication mechanism providing:
- Public-key authentication
- Origin binding
- Phishing resistance
- No shared secrets
It does not provide identity federation, tokens, or scopes.
WebAuthn replaces passwords and weak MFA factors within the authentication step.
Layered Architecture
[ Authentication Methods ]
- Password
- OTP
- WebAuthn (FIDO2)
[ Identity Layer ]
- OpenID Connect
[ Authorization Layer ]
- OAuth 2.0
[ Applications / APIs ]
This separation allows authentication methods to evolve without breaking applications or APIs.
WebAuthn Inside OAuth / OIDC
In modern systems, WebAuthn appears as just another authentication method.
Typical flow:
- User initiates login
- WebAuthn challenge is performed
- Assertion is verified
- OIDC ID Token is issued
- OAuth access tokens are minted
Applications remain unaware of the underlying authentication method.
Signalling Authentication Strength
OIDC supports claims that describe authentication context:
- amr – Authentication Methods Reference
- acr – Authentication Context Class Reference
Example:
"amr": ["fido"]
This enables step-up authentication and policy-driven enforcement.
Why This Matters
When authentication, identity, and authorization are properly separated:
- Passwordless login becomes trivial
- Strong MFA can be enforced selectively
- APIs remain decoupled from identity mechanics
- Security improves without rewriting applications
Conclusion
OAuth 2.0, OpenID Connect, and WebAuthn are not competing technologies.
They are deliberately orthogonal layers that, when combined correctly, produce systems that are safer, simpler, and easier to evolve.
