Authentication Architecture
Date: 2026-08-17
Where identity lives in a system, and which components are allowed to establish it. The architectural question isn’t how passwords are checked — it’s whether there’s one place that answers “who is this”, or eleven places that each half-answer it.
Authentication is establishing who a user is; authentication architecture is where in a system that is done, which components trust the result, and how the result is carried between them.
Centralised or per-application
PER-APPLICATION CENTRALISED (an identity provider)
storefront → its own users table storefront ┐
admin → its own users table admin ├──→ IdP ──→ one user record
support tool → its own users table support ┘
warehouse → shared login, sadly warehouse ┘
4 password policies one policy, one MFA enrolment
4 places to revoke on leaving revoke once
4 audit logs, no join one audit trail
4 implementations to get wrong one, and single sign-on comes free
An identity provider (IdP) is the service that owns credentials and issues tokens; everything else trusts it and never sees a password. Single sign-on (SSO) is the consequence — one authentication serving many applications.
The decision is rarely revisited and expensive to reverse, because migrating credentials between systems means either forcing every user to reset or carrying the old hashes forward with the old algorithm.
Two populations, two systems
The most consequential structural decision, and the one that causes trouble when skipped:
| Customers | Staff | |
|---|---|---|
| Volume | Millions | Hundreds |
| Signup | Self-serve | Provisioned, then deprovisioned |
| MFA | Optional, encouraged | Mandatory |
| Session length | Long — weeks | Short — hours |
| Recovery | Self-serve email reset | IT, with identity verification |
| Source of truth | Your database or a CIAM product | The corporate directory — Entra ID, Okta, Google Workspace |
| On leaving | Account persists | Must be revoked the same day |
Keep them separate. One system serving both ends up with either staff accounts under a customer password policy, or customers subjected to corporate MFA. The dangerous version is an internal tool authenticating against the customer database with a role flag — one privilege-escalation bug away from a customer promoting themselves to admin.
Where the session lives
Once identity is established, every subsequent request has to be attributed. Three shapes, and the choice constrains logout more than anything else:
SERVER SESSION cookie holds an opaque ID → session store lookup per request
✓ revoke instantly (delete the row)
✗ a lookup on every request; the store is a dependency
STATELESS TOKEN cookie or header holds a signed JWT with claims inside
✓ no lookup — any service can verify with the public key
✗ cannot be revoked before expiry. this is the whole tradeoff
HYBRID short access token (5–15 min) + long refresh token
✓ revocation delayed by minutes, not weeks. the usual answer
JSON Web Token (JWT) is the signed-claims format; the signature proves the token wasn’t altered, not that it’s still valid. Details of the format, cookie flags and storage are in Sessions and Tokens; what’s architectural is that stateless tokens trade revocation for scale, and revocation is what you need during an incident.
Federation and delegation
- OpenID Connect (OIDC) for “log in with Google/Microsoft” — an identity layer on top of OAuth 2.0, and the right choice for consumer and workforce SSO alike
- SAML for enterprise SSO, because that’s what enterprise buyers’ directories speak. Older, XML-based, and required rather than chosen
- OAuth 2.0 for authorisation, not authentication. An access token proves the bearer may call an API. It does not prove who they are, and treating it as a login is a genuine vulnerability class — OAuth and OpenID Connect
- B2B tenants each want their own IdP. “Log in with our company’s Okta” is a standard enterprise requirement, which means per-tenant IdP configuration, discovery by email domain, and just-in-time provisioning — Multi-Tenancy
Practical structure
- One service issues tokens; everything else verifies them. Verification needs only a public key, so it scales without a call back to the IdP
- Never accept a token you didn’t intend to receive. Verify signature, issuer, audience and expiry — every time, in a shared library, never per service by hand
- Services must not trust identity claims from each other. Propagate the original token or exchange it; a header saying
X-User-Idon an internal network is a header anyone reaching that network can set - Support two signing keys so rotation doesn’t log everyone out — the same shape as any credential rotation — Secrets Management
- Log every authentication event — success, failure, MFA challenge, password change, token issuance. This is the first evidence anyone asks for after an incident, and it must not contain the credentials themselves — Observability
- Rate-limit login, reset and MFA endpoints separately and generously enough not to lock out a shared office — Rate Limiting
Commerce-specific
- Guest checkout must stay first-class. Forcing account creation is one of the most reliably damaging conversion decisions available — Checkout Design
- Guest-to-account merging. The order placed as a guest must attach to the account created afterwards, keyed on email. Otherwise order history is wrong and so is every lifetime value calculation — Identity Stitching, Customer Lifetime Value
- The anonymous identifier is not identity. A cookie identifies a browser; conflating the two produces both an analytics error and a security one — Anonymous and Identified Users
Where it interacts
- Authentication vs Authorisation — the distinction this note assumes; establishing who someone is doesn’t decide what they may do
- Authorisation Models — the next question, and the one where breaches actually happen
- Sessions and Tokens — the mechanics of cookies, JWTs and storage
- Common Vulnerabilities — credential stuffing, session fixation and account enumeration are the attacks this architecture is defending against