Identity and Authentication Architecture

Chapter 10 followed a privileged refund across boundaries. Follow it once more, this time asking what each component knows about the actor on the other side.

The support operator signs in through a browser. The console calls a decision service under a workload identity. A worker presents another identity to the payment provider. A reconciliation job may revisit an uncertain result hours later. The deployment pipeline can replace all three workloads, and an AI assistant may be allowed to draft—but not approve—the refund. Calling this collection “the login flow” hides most of the identities that can move money.

Authentication architecture gives each actor a way to prove who or what it is, at an assurance appropriate to the consequence, for a bounded time. That proof must survive handoff without becoming broader authority, and it must be possible to end it.

Inventory actors by how they prove identity

Start with the context and flow records from Chapter 10. Every human, process, device, and external system that can initiate a flow needs an entry. Grouping them by authentication behavior reveals mistakes that a list of account names will not.

Human users normally authenticate through a platform or federated identity provider. Their proof may include a password, passkey, hardware-backed key, or another authenticator, but the important design question is what assurance the relying system receives. Administrators are still humans, yet their production identity should be named, separately assigned, more strongly authenticated, and distinguishable from their ordinary account.

Workloads should prove the runtime they belong to rather than share a secret copied into configuration. A managed cloud, cluster, or platform identity can bind the credential to a service, environment, and deployment. A legacy service account is different: it is an account-shaped container for a credential. Treat it as migration debt when a workload identity is available; otherwise give it an owner, one purpose, narrow reach, rotation, monitoring, and an end date.

Devices may contribute a certificate, enrollment record, or hardware-backed key. Device trust supplements the human’s proof; it does not turn a device into its user. CI/CD jobs need identities bound to the repository, workflow, ref, environment, and artifact they are allowed to release. A general production deploy key in a CI variable erases those distinctions.

Third-party integrations need an identity owned by the integration, not a developer’s personal token. Record the partner, reachable data and actions, credential custodian, rotation method, and emergency revocation path. AI agents and tools need the same discipline. A tool broker should identify the calling agent and the accountable human or workflow, then issue only the credential needed for the approved action. A prompt must not inherit a broad user or service token merely because it arrived inside an authenticated session.

For the refund system, that inventory names at least the customer, support operator, privileged administrator, operator device, console workload, decision service, payment worker, reconciliation job, deployment workflow, payment provider integration, and any tool-calling assistant. “Internal” is not an identity type.

Raise assurance at the consequential moment

The operator’s morning sign-in and the decision to release money do not need to be the same authentication event. The first establishes a session. The second should require evidence recent and strong enough for the amount, account state, and operator role. This is step-up authentication: ask for stronger or fresher proof when the action becomes sensitive, rather than forcing every low-risk page view through the highest ceremony.

A phishing-resistant authenticator binds its output to the legitimate verifier, so a fake sign-in page cannot simply relay a reusable code. Manually entered one-time codes can add useful resistance to password theft, but they do not provide that verifier binding. Prefer phishing-resistant methods for administrators and production control, and require multifactor authentication for privileged roles. Set the exact requirement from exposure and impact, not from whether a vendor labels a method “passwordless.”

The refund sign-in can be reviewed as a short sequence:

1. The operator enters the console through the approved identity provider. The console validates issuer, audience, signature, nonce, and the transaction it initiated before creating a local session.
2. The session records the authentication time, method, assurance, subject, and device or risk context needed for later decisions. It does not turn identity-provider groups into unlimited application authority.
3. When the operator requests a consequential refund, the console checks whether the proof is recent and strong enough. If not, it sends the operator through step-up and binds the successful result to the pending transaction.
4. The application passes a stable human subject and relevant assurance context to the service that will make the authorization decision. Chapter 12 decides whether that actor may refund this account and amount.

Recovery belongs in the same threat model. If a help-desk call or email link can replace a phishing-resistant authenticator with weaker proof, the recovery path defines the account’s real assurance. Protect authenticator replacement and account recovery according to the account’s impact; use delay, independent notification, support verification, and post-recovery restriction where the risk warrants them.

Treat sessions as credentials with a clock

After sign-in, the session—not the authenticator—usually crosses each browser request. Give it an overall lifetime and an inactivity lifetime. Require reauthentication for authenticator changes, credential creation, sensitive exports, payment changes, and privileged elevation. Risk signals may shorten a session or trigger step-up, but opaque risk scoring should not silently become the only control on a dangerous action.

For browser sessions, protect transport and use cookies that are Secure, HttpOnly, appropriately constrained by SameSite, and narrowly scoped by domain and path. Do not put access tokens in URLs. Rotate refresh tokens where the client and provider support safe reuse detection; bind them to the client or device context where appropriate. Access tokens should be short-lived and restricted to their intended recipient. Long-lived tokens require an explicit exception with an owner, storage location, monitoring, rotation date, and expiry review.

Logout must end both the local session and the server-side path that can mint another one. Revocation needs more precision than a “disable user” button: the design should be able to end one session, all sessions for an account, a lost device’s trust, an integration credential, an administrator’s elevation, a pipeline run, or a workload identity. Log issue, refresh, step-up, denial, logout, and revocation events with identifiers that support investigation without recording the credential itself.

Then walk failure. If the assurance or policy dependency is unavailable, a new privileged refund should not fall back to an old low-assurance session. If revocation propagation is delayed, the maximum token lifetime becomes part of the residual risk. If a token appears in a CI log, trace, crash dump, or support bundle, the response is redaction and secret scanning plus immediate revocation—not rotation at the next scheduled interval.

Know what federation protocols are doing

SAML and OpenID Connect can carry an authentication assertion from an identity provider to a relying party. OAuth 2.0 delegates access to a protected resource. They often appear in the same product, but an OAuth access token is not evidence that a human completed a particular authentication ceremony, and a valid identity assertion is not permission to issue a refund.

For SAML, validate the expected issuer and audience, signature and certificate chain, assertion time bounds, response correlation, attribute mapping, and certificate rollover behavior. For OpenID Connect, validate issuer, audience, signature, nonce, authorization response, token lifetime, and client type. In both, decide how logout, group changes, account disablement, signing-key rotation, and identity-provider failure reach the local session.

For redirect-based OAuth flows, use the authorization code flow with PKCE. The client creates a one-time verifier and sends its derived challenge with the authorization request; a stolen authorization code cannot be redeemed without the verifier. Register redirect URIs exactly, reject open redirect chains, bind the response to the initiating transaction, validate the authorization server, and issue tokens for the intended resource or audience. Public clients cannot keep a client secret merely because one was embedded in the application. Client credentials prove the client, not the human using it.

A federation review is incomplete until someone has tested the hostile configuration: a look-alike issuer, wrong audience, stale signing key, wildcard redirect, altered state or nonce, missing PKCE verifier, overbroad scope, unexpected group mapping, and logout that leaves the local refresh path alive.

Exchange workload proof instead of passing secrets

The console backend should not pass its own broad credential to the decision service, and the payment worker should not inherit the operator’s browser token. Each hop needs a credential the receiver can verify and constrain.

A managed workload exchange has a useful shape:

1. The runtime supplies a platform-verifiable proof bound to the deployed workload and environment.
2. A token service validates that proof and issues a short-lived token for the named destination.
3. The destination validates issuer, signature, audience, expiry, and the workload subject before consulting authorization policy.
4. The next service repeats the process for its own identity; it does not forward a universal bearer token across the system.

This separates identity from delegation. The decision service can authenticate the console workload while also receiving the operator subject and assurance context needed for policy. The payment worker can authenticate as itself and present the exact approved refund decision. Possession of a queue message remains transport, not proof of the producer’s identity or permission.

Apply the same pattern to deployment. The pipeline exchanges a protected workflow proof for an ephemeral token restricted to the target environment and, where supported, the intended artifact. A forked pull request, another repository, or an earlier job should not be able to replay it. For a partner that cannot support short-lived federation, isolate its static credential, prevent it from entering logs, monitor its use, and practice revocation.

Give administration its own path

Ordinary support work, privileged administration, and emergency recovery should not collapse into one account. Use named administrator identities, separate role assignment, phishing-resistant authentication, just-in-time elevation, bounded duration, and approval tied to a case, incident, or change. Record the elevation and the resulting commands or actions. Support impersonation is an administrative capability: show it visibly, mask fields where possible, bind it to a customer case or consent rule, and preserve attribution.

Break-glass access is deliberately independent of a failed normal path, but it must not be anonymous or permanent. Inventory emergency accounts, protect their authenticators separately, alert on every attempt, limit what they can reach, test that they work, and require a post-use review. A shared administrator password destroys attribution; a sealed shared break-glass credential may sometimes be unavoidable, but it needs dual control and immediate rotation after use.

Account lifecycle completes this architecture. Provision from an authoritative source with an owner, role, tenant, and expiry for temporary access. On a role change, remove obsolete access before adding new privilege unless a documented transition requires overlap. Review dormant accounts and unused workload identities. Deprovisioning must revoke sessions, refresh tokens, API tokens, device trust, integration credentials, administrator elevation, and related recovery methods—not merely hide the account from a directory listing.

Review the architecture by trying to end trust

An authentication design is easiest to challenge through revocation. Pick each actor and ask what happens now if the person leaves, the device is lost, the workload is compromised, the partner key leaks, the pipeline is abused, or an agent begins making unintended tool calls.

For each actor, record:

• the authoritative source and stable subject;
• the authenticator or workload proof and the assurance it provides;
• token or session type, audience, lifetime, refresh behavior, and binding;
• the human or workload context handed to authorization;
• ordinary and emergency revocation, including propagation delay;
• issue, failure, step-up, privileged-use, and revocation evidence;
• any exception, its owner, compensating control, expiry, and reapproval rule.

Run four focused reviews against that record. The session review checks overall and inactivity limits, recent-authentication rules, refresh rotation, cookie scope, logout, and each revocation target. The federation review checks issuer and audience pinning, signatures and rollover, response correlation, exact redirects, PKCE, claim mapping, and local-session termination. The administrator review checks named accounts, separate elevation, approval, duration, action evidence, break-glass testing, and post-use review. The lifecycle review starts with a real departure or compromise event and measures how long every surviving credential remains useful.

The chapter’s design is complete when the refund can be traced from human proof through local session and workload exchange, and when any link in that chain can be ended without waiting for convenience. The next chapter can then answer the separate question: given these authenticated actors, which actions should each one be allowed to take?