https://knowledgebase.pirho.net/index.php?action=history&feed=atom&title=Modern_Authentication_Architecture 2026-07-11T12:52:01Z Revision history for this page on the wiki MediaWiki 1.43.0 https://knowledgebase.pirho.net/index.php?title=Modern_Authentication_Architecture&diff=392&oldid=prev 2026-04-19T17:25:24Z

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

Dex