Mental model#
A session is a server-recognized continuity of authentication. A token is a credential or assertion carried between parties. Either can be stateful or partly self-contained; the design decision is where authority, revocation, rotation, and context live.
Mechanism and state flow#
- Create a session only after authentication and rotate its identifier across privilege changes.
- Bind server-side state to the principal, authentication time, assurance, expiry, and revocation status.
- Send browser credentials with secure transport and cookie attributes appropriate to the interaction.
- Recheck authorization from current resource policy rather than embedding every permission indefinitely.
- Expire idle and absolute lifetimes, revoke on risk events, and protect recovery and logout paths.
Concrete example#
Choose a server session for an admin console
A random opaque cookie indexes server-side session state. Role changes and forced logout take effect through current session and authorization checks; the browser never receives the role database as trusted state.
Architecture consequence: Accept a session lookup on sensitive requests in exchange for centralized revocation and concise browser credentials.
Scaling and operational trade-offs#
| Option | Choose when | Cost or limit |
|---|---|---|
| Opaque session identifier | Fast revocation and server-controlled context matter. | Requests need a highly available session lookup or cache. |
| Self-contained signed token | Many resource servers need locally verifiable, short-lived assertions. | Revocation and stale claims are harder; keys and validation rules must be coordinated. |
| Long lifetime | Only when product risk and reauthentication cost justify it. | A stolen credential remains useful longer. |
Failure diagnosis#
- Failure
- A privileged session ID is not rotated after login or role elevation.
- Impact
- An attacker who fixed or stole the earlier identifier can inherit the elevated session.
- Detection
- Session tests observe the same identifier before and after the privilege boundary.
- Mitigation
- Rotate the identifier, invalidate the prior state, and retain only explicitly safe continuity data.
- Trade-off
- Rotation complicates concurrent devices and in-flight requests.
Checklist exercise#
Work the scenario before revealing your answer
- Compare session lookup, expiry, revocation, and authorization freshness for two credential models.
- Define idle, absolute, and refresh lifetimes for a low-risk and privileged surface.
- Write logout, password-reset, role-change, and device-loss behavior.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- Where does revocation state live?
- What changes after privilege elevation?
- Which browser storage and cookie protections apply?
- How quickly does a permission change take effect?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
Sources reviewed 2026-09-04. Product-specific controls and threat assumptions still require current verification.