Chapter 8 — Authentication, Authorization, Sessions, and API Boundaries

Metadata

Opening Quote

MSQE principle: A valid identity is evidence of authentication. It is not evidence that a requested action is authorized.

Opening Story

The following is an illustrative scenario. Atlas Support lets an operator locate an order for customer assistance. The operator is authenticated and can view selected order details. A later API change uses the same session to call a refund endpoint. The endpoint returns success in one synthetic case, even though the support role is not permitted to initiate a refund. A cached account view also continues to display an action after the operator's role changes.

The problem is not “login failed.” It is an access-control boundary problem: actor, resource, action, state, route, and cache behaviour need evidence. This chapter develops that evidence without teaching credential bypass or token-forgery procedures.

Why This Chapter Matters

Identity and access controls are common sources of material quality risk because application behaviour often crosses browser, API, session, cache, service, and dependency boundaries. A login test may be correct and still leave object-, function-, or property-level authorization unverified.

This chapter applies Part IV interface thinking to identity and access evidence. It does not teach identity-provider configuration, cryptographic implementation, or provider-specific SDKs.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish authentication, authorization, session state, and machine identity;
• model least privilege, default-deny, resource ownership, and action/state boundaries;
• create a safe authorization matrix for synthetic actors and resources;
• assess session, token, cache, and API evidence limits; and
• produce an Identity and Access-Control Evidence Matrix.

Authentication Is Not Authorization

Authentication establishes an identity claim for a stated boundary. Authorization decides whether that identity may perform an action on a resource in a context and state. A valid session can therefore support a successful authentication result while a request is correctly denied. Conversely, a valid session plus a successful request may reveal an authorization defect if the actor, action, or ownership rule is violated.

Least privilege means granting only the access needed for the stated role and task. Default deny means an action is denied unless an explicit policy permits it. These are design and verification principles, not guarantees that a single route is correct. The evidence boundary must identify actor, resource, action, state, request path, expected outcome, and limitation.

An Authorization Evidence Matrix

The following matrix uses synthetic Atlas actors and data. It is an evidence-planning artifact, not a policy specification for a real organization.

The matrix deliberately includes allow and deny outcomes. A suite that only demonstrates successful paths cannot establish least privilege. It also separates object ownership from function access: an actor might be permitted to call a refund route in one role but not for every order or transition.

Sessions, Tokens, and State Boundaries

A session represents an authenticated context whose lifecycle may include creation, expiry, revocation, renewal, or invalidation. A token is a credential artifact used at a boundary; its presence does not define the application's authorization decision. Avoid treating a session check as a substitute for resource-level authorization.

For evidence purposes, state the session or token boundary without documenting ways to defeat it. Examples include a synthetic expired-session request expected to be denied, a role-change case expected to remove an action, or a session-revocation case expected to prevent a further sensitive operation. NIST SP 800-63-4 provides identity guidance; it is not a universal application authorization model.¹

Cache behaviour deserves the same discipline. A performance optimization may cache an account or order view, but authorization-sensitive data must not be reused across actors or remain actionable after a relevant role or state change. The question is not whether caching is good or bad; it is what the cache key, scope, invalidation, and evidence boundary permit.

Worked Reasoning: Support Refund Matrix

The following is an illustrative, synthetic verification. A support operator is authenticated, views an order, then attempts the refund action through the stated UI/API boundary. The expected result is denial with no refund state transition. A customer owner may view the same order but cannot view another customer's order. A service account processes a valid queue event but cannot call the support UI route.

API and Machine-Identity Boundaries

APIs make boundaries explicit through methods, resources, fields, and status outcomes, but a status code alone may not show that the correct resource-level check occurred. Verify the behaviour and resulting state for the defined actor. For machine actors, include service identity, allowed event or resource, provenance, scope, and retry/state semantics. A queue consumer that receives a valid event should not become a general-purpose authority for unrelated actions.

Designing Coverage Across Roles, Resources, Actions, and States

An access-control matrix becomes more useful when it exposes the dimensions that application tests often collapse. The same resource can have different rules for different actions. The same action can differ by resource ownership or lifecycle state. A refund request for an order that is pending payment may need a different rule from one for a fulfilled order. A support role may view masked information but not export it. A service account may update a fulfilment state only after a valid event is processed.

Use the following dimensions deliberately:

This is not an instruction to generate every mathematical combination. Prioritize the combinations with material asset, trust, and change relevance. Record why a row is selected and which combinations remain outside the evidence.

State Changes Matter

An authorization decision is more than a response code. If a denied refund request returns an error but changes refund state, creates a queue event, or exposes a side effect, the boundary is not behaving as claimed. Conversely, an allowed request should be checked for the intended limited effect, not merely a success status. For Atlas, a valid support view may return a masked order record; a denied refund action should preserve the existing order state and avoid creating an authoritative refund event.

Session and Role-Change Evidence

Session lifecycle creates a time dimension. A role may change, a session may expire, a token may be revoked, or a cache may retain an earlier view. The manuscript does not prescribe implementation mechanisms; it requires a testable evidence question. For example: After a synthetic support role is removed, can the prior session or cached view still initiate the stated refund action? A result should name the session/cache boundary, window, route, expected denial, resulting state, and limitation.

This is especially important for performance/security integration. A cache restriction can reduce stale authorization risk but change latency, throughput, or dependency work. A stronger identity check can improve an authentication boundary but add user friction or dependency capacity demand. Chapter 11 treats these as explicit trade-offs rather than assuming controls have no performance consequence.

Evidence Matrix Maintenance

An evidence matrix should be versioned like any other decision artifact. Refresh it when a role, action, state, route, cache key/scope, session behavior, API version, service identity, or policy changes. A passing row can become stale. State this openly instead of representing an old result as continuing coverage.

The matrix also helps organize regression control. A verified authorization issue becomes a named row with the synthetic actor, resource, action, state, expected outcome, evidence source, owner, and revision trigger. This is more useful than relying on a vague statement that “access control was tested.”

Worked Matrix Review: Order Support and Fulfilment

The following is an illustrative review sequence for three related Atlas boundaries. It demonstrates how an evidence matrix can reveal a missing dimension without trying to provide an exhaustive authorization test plan.

Customer Order Access

The claim is that a customer may view their own order but not another customer's order. A valid check needs two synthetic orders with distinct ownership, one synthetic authenticated customer, stated API route, response/data observation, and resulting audit or event evidence where available. The expected denial must not return the other customer's order fields. A result that simply receives a denial status without checking disclosure is incomplete.

The two rows are paired. A suite with only the own-order case shows that a permitted journey works; it does not show that ownership is enforced.

Support Role and Financial State

The support actor may need an allowed view while being denied a financial action. The test should also consider state. For example, a support operator may view a paid order to answer a customer question but must not initiate a refund through the stated support route. If a refund policy later permits a specialized finance role, that is a new actor/action/state row—not a reason to treat all support identities as equivalent.

The matrix should preserve the actor's expected minimum data view, route, state, denied action, resulting order state, and any queue/event side effect. This guards against a narrow implementation that denies the UI action while an API route, cached action, or asynchronous event remains inconsistent.

Service Identity and Event Provenance

Machine identities introduce a different boundary. The evidence claim is not “the service account can call the API.” It is that the stated service identity can process a valid, provenance-bound fulfilment event and perform only the permitted transition. The record should specify event source/category, order state before/after, retry/unknown-state handling, and the action that must remain denied.

The example remains defensive because it examines expected boundary behavior with synthetic identities and data. It does not instruct readers how to acquire or misuse credentials.

Selecting Matrix Coverage

An evidence matrix can grow rapidly. Select rows based on consequence, change, and boundary diversity. Start with high-consequence actions, ownership boundaries, newly changed routes, identity/session transitions, cache-sensitive views, and machine actions. Then record the rows left outside the current scope.

This prioritization supports disciplined review without pretending that the chapter has produced a complete access-control certification.

Identity Evidence and Decision Consequence

When a matrix row fails, write a bounded conclusion. For example: In build b151, the synthetic support role successfully initiated a refund through route R for a paid order; this contradicts the stated action boundary for that route and state. Other routes remain unassessed. The evidence may justify remediation before release, a narrowed feature scope, or escalation to the relevant owner. It does not establish total exposure without additional evidence.

When a row passes, the conclusion is equally bounded: The tested route denied the synthetic role and preserved state under the stated configuration. The record should identify whether a cache, role change, API version, or service path could make the result stale.

Authorization Evidence Review Checklist

Before interpreting an access-control result, check actor identity, session state, resource ownership, action, lifecycle state, route, expected data/state effect, cache/service boundary, synthetic evidence provenance, limitation, owner, and revision trigger. This prevents a status code or login result from carrying a broader claim than the method supports.

Boundary Consistency Across Interfaces

The same authorization claim can be reached through more than one interface: browser interaction, public API, internal service endpoint, cached view, queue consumer, or support workflow. A system may correctly deny an action in one interface while another interface uses an inconsistent ownership or state check. The purpose of coverage is not to enumerate every implementation detail; it is to identify materially different paths that could make a previously passing result incomplete.

When two interfaces should enforce the same decision, write the expectation explicitly. When they intentionally differ, explain why. Otherwise a difference can be mistaken for either a defect or a feature after the fact.

Session Lifecycle Evidence

Sessions and tokens have lifecycle conditions that affect authorization evidence. A test can use synthetic states such as valid, expired, revoked, changed-role, or missing context. The reader need not know how a provider implements those states to assess application behavior at the boundary.

The evidence should state the synthetic fixture and configuration version. A passing expired-session check does not prove every session implementation property; it establishes one behavior for one boundary. This distinction allows the Quality Engineer to identify a meaningful regression when a session, cache, or authorization-policy change occurs.

Least Privilege as an Evidence Claim

Least privilege is often stated as a principle without an observable claim. Make it specific: For the stated support role, only the minimum order fields required for customer assistance are visible, and refund initiation is denied. The claim has both a positive and a negative boundary. An overly broad response may disclose unnecessary information; an overly strict response may prevent an intended support action. Both require evidence.

This is not a request to create a provider-specific role system. It is a way to make the quality of an existing authorization boundary testable and decision-ready.

Authorization Changes and Evidence Decay

Authorization evidence can decay without any change to the named endpoint. A new role, a delegated administrative action, a background worker, a configuration flag, a changed default, or a cache-policy adjustment can alter which decision is actually enforced. Treat the matrix as a living model of policy-relevant combinations, not a one-time set of assertions. For every material policy change, identify the affected role, resource, action, state, interface, and enforcement point; then decide which matrix rows must be revisited.

Evidence should show both allowed and denied outcomes, but neither outcome alone proves the policy is consistently enforced. An allowed action must correspond to the intended resource and state, not merely return a successful technical response. A denied action must be denied at the relevant boundary without disclosing unnecessary detail or causing an unintended state change. When the action is asynchronous, the review must follow the request through to the worker or downstream service that performs it.

This is also a performance concern. A policy decision that is correct but unexpectedly expensive can create pressure to introduce unsafe caching or bypasses. Record its normal and degraded dependency behaviour, cache scope, invalidation condition, and observability. The goal is not to optimise away a control; it is to design and verify a control whose enforcement remains explicit as the system evolves.

When an evidence gap remains, state it in the matrix. For example, an administrative state transition may be covered for a browser route but not yet for a machine interface. Naming the gap, owner, and boundary is stronger than marking the entire policy “verified” on the basis of a nearby test.

Session-state evidence should make expiration, renewal, sign-out, and privilege change visible without recording credential material. The expected result after a state transition matters as much as the initial sign-in result. A review that checks only the happy-path session may miss an inconsistent enforcement boundary after a policy or role changes.

For interfaces that expose the same capability, compare the policy outcome rather than assuming shared implementation implies shared enforcement. A browser route, API, worker, and support interface may reach different decision points; a concise cross-interface matrix makes that difference reviewable.

Where policy is intentionally different, state the reason and owner. An unexplained difference is an evidence gap, not a design conclusion.

This simple distinction prevents a future implementation shortcut from being mistaken for an approved access rule.

Engineering Perspective

Keep identity evidence matrices versioned with role rules, resource states, routes, and cache assumptions. When a new API method, role, session rule, cache policy, or service actor is introduced, treat the existing evidence as potentially incomplete rather than assuming it covers the change.

Industry Perspective

OWASP ASVS provides a widely used verification framework that can inform coverage questions around authentication and access control; it is an open verification standard, not a legal requirement or proof of system security.² RFC 9700 provides OAuth security best-current-practice guidance where OAuth semantics are relevant; it does not replace application authorization decisions.³

Common Misconceptions and Pitfalls

“The user is logged in, so the request should be allowed.”

Authentication and authorization answer different questions. Access depends on role, ownership, action, state, and boundary.

“A 403 response proves the whole access model.”

It supports a narrow observation. Confirm the actor, resource, action, state, resulting data/state, and routes that remain outside the check.

“Caching and authorization are unrelated.”

Cache scope and invalidation can affect who sees data or actions after identity and state change.

QA → QE Transition

The transition is from checking login success and one role path to designing an evidence matrix across actors, resources, actions, states, cache conditions, and denial behaviour.

Summary

Authentication establishes an identity context; authorization determines what that context may do. Evidence must cover actor, resource, action, state, boundary, outcome, and limitation. Matrices make access-control assumptions inspectable and reusable.

Key Takeaways

• Successful authentication does not establish authorized action.
• Allow and deny cases are both required evidence for least privilege.
• Sessions, tokens, APIs, caches, and service identities have distinct boundaries.
• Version the matrix when roles, routes, state transitions, or cache policy change.

Review Questions

1. What fields make an authorization check decision-ready?
2. Why is resource ownership different from route access?
3. How can a cache create an authorization-sensitive boundary?
4. What should be recorded for a machine-identity verification?

Interview Questions

1. How would you test that an authenticated user cannot access another customer's data?
2. What is the difference between authentication and authorization?
3. How do you validate an API access-control control without a bypass procedure?

Practical Exercise

Create an Identity and Access-Control Evidence Matrix for Atlas browse, order, support, refund, and fulfilment journeys. Include synthetic actors, allowed and denied actions, resource ownership, state, evidence, limitation, owner, and revision trigger.

Further Reading

• NIST SP 800-63-4 Digital Identity Guidelines
• OWASP Application Security Verification Standard
• RFC 9700: OAuth 2.0 Security Best Current Practice

References

Chapter Checklist

• I can distinguish authentication, authorization, and session evidence.
• I can create an access-control matrix with allow and deny cases.
• I can state cache and API boundaries relevant to authorization.
• I can record limitations and residual risk without teaching a bypass.

Chapter Navigation

Previous: Chapter 7 — Security Quality: Assets, Trust Boundaries, and Threat Models · Next: Chapter 9 — Input, Output, Dependencies, Secrets, and Configuration Trust