Dex: Created page with "= 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..."

2026-04-20T05:34:24Z

Created page with "= 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..."

New page

= 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 ==

<pre>
[ Authentication Methods ]
- Password
- OTP
- WebAuthn (FIDO2)

[ Identity Layer ]
- OpenID Connect

[ Authorization Layer ]
- OAuth 2.0

[ Applications / APIs ]
</pre>

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:
<pre>
"amr": ["fido"]
</pre>

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.

OAuth 2.0, OpenID Connect, and WebAuthn - Revision history