Modern Authentication Architecture
Modern Authentication Architecture
Summary: Modern authentication systems often appear complex because multiple concerns are blurred together: authentication, authorization, session continuity, revocation, and user experience. This article separates those responsibilities, explains the role of OAuth, OpenID Connect (OIDC), SAML, WebAuthn, and non-HTTP mechanisms, and describes practical approaches to sessions and revocation suitable for a reusable authentication core such as AuthEngine.
Context
Authentication is not a web invention. Long before HTTP, systems authenticated users, devices, and services using directories, tickets, and possession of cryptographic material.
What has changed is scale, client diversity, token lifetime, threat models, and the need for horizontal scalability. Most confusion arises when these concerns are treated as one problem instead of several smaller ones.
Core Responsibility Boundaries
Authentication
Authentication answers the question: Who are you?
An authentication mechanism evaluates credentials, proves identity, and produces an authentication event. Examples include passwords with MFA, WebAuthn, SAML assertions, Kerberos tickets, LDAP binds, and mTLS client certificates.
Authentication produces proof, not continuity.
Authorization
Authorization answers the question: What are you allowed to do?
Authorization evaluates policy, applies scopes or entitlements, and makes permit or deny decisions. These decisions are typically expressed as signed artefacts.
Session / Continuity
Sessions answer the question: Are you still trusted over time?
Sessions belong to applications or platforms. They are not defined by OAuth, OIDC, or SAML.
Revocation
Revocation defines when trust stops before natural expiry.
Tokens Are Assertions, Not Sessions
OAuth and OIDC tokens are frequently misused as sessions.
Tokens are signed, time-limited assertions. They prove something was true at time T, not that it is still true now.
OAuth, OIDC, and SAML
OAuth 2.0
OAuth is an authorization framework. It issues access and refresh tokens and does not define login.
OpenID Connect (OIDC)
OIDC is an authentication layer on top of OAuth and introduces the ID Token for client-side authentication.
SAML
SAML is an authentication assertion protocol, still widely used in enterprise environments. SAML assertions are conceptually equivalent to OIDC ID Tokens.
Token Types and Audiences
Access Tokens
- Audience: APIs
- Purpose: Authorization
- Contents: Scopes and permissions
ID Tokens
- Audience: Applications
- Purpose: Authentication proof
- Not suitable for APIs
Refresh Tokens
- Audience: Authorization server
- Purpose: Obtain new access tokens
Stateless and Stateful Continuity
Stateless Continuity
Stateless continuity relies on short-lived tokens, offering horizontal scalability and simple validation, but logout becomes eventual.
Stateful Continuity
Stateful continuity introduces minimal shared state such as Redis or databases to allow immediate revocation and strong logout semantics.
Revocation: Why There Are No Token CRLs
PKI revokes artefacts such as certificates. OAuth systems revoke authority continuity. Tokens are short-lived and disposable by design, making CRL-style revocation impractical.
Effective Revocation Patterns
Refresh Token Families
Each login creates a refresh token family. Revoking the family ends the session.
Epoch / Generation Numbers
Tokens include a generation number which can be invalidated by incrementing the authoritative version.
last_invalid_before
A single timestamp invalidates all tokens issued before a given moment.
Authentication Mechanisms Beyond HTTP
Authentication can occur via non-HTTP mechanisms such as LDAP, Kerberos, RADIUS, TACACS+, mTLS, PAM, and GSSAPI. AuthEngine consumes authentication events, not protocols.
WebAuthn
WebAuthn provides phishing-resistant authentication but does not provide authorization, sessions, or tokens. Tokens are still issued after successful authentication.
JavaScript and Authentication
AuthEngine does not depend on JavaScript. JavaScript enables smooth client-side experiences but is not required for security or correctness.
The Role of AuthEngine
AuthEngine authenticates requests, authorizes actions, issues and validates tokens, enforces revocation, and returns accurate response codes. UX decisions remain at the application layer.
Key Insight
Stability lives in rules, not artefacts.
Token shapes change frequently. Systems remain stable by adjusting acceptance rules rather than chasing individual artefacts.
Related Topics
- OAuth 2.0 Access Tokens
- OpenID Connect ID Tokens
- Session Management Patterns
- Token Revocation Strategies
- WebAuthn
- Mutual TLS
References
- RFC 6749 – OAuth 2.0
- OpenID Connect Core 1.0
- RFC 4120 – Kerberos
- W3C Web Authentication
