Session, Cookie & Token — Learning Bundle
This learning bundle separates three related tools. A session keeps continuity that the server knows. A cookie is browser-managed state sent by set rules. A token carries claims or authority. The bundle is not one standard identity term.
Another example
An opaque session ID sits in a Secure, HttpOnly, SameSite cookie. It points to state on the server.
Main parts
- 01Identity or input
- 02Policy or transformation
- 03Stored result and audit evidence
Use it when
Choose each tool by its lifetime, travel path, and how someone can cancel it. Also check what the client can see. These choices must fit the threat model.
Do not use it when
Without a threat model, do not store long-lived bearer tokens where browser scripts can read them.
Name used in code
Set-Cookie / session store / JWT Before you ship
Check that every member concept has its own name and link. Show all members in the same situation. Give a visible rule for when each one applies and which groups are valid. Never present the bundle as one canonical pattern or as parts that can be swapped freely.
Outcome: Use Session, Cookie & Token — Learning Bundle to compare its member concepts. Keep their boundaries clear, then decide which members apply and which can work together. User context: An opaque session ID sits in a Secure, HttpOnly, SameSite cookie. It points to state on the server. Learning bundle to unpack: Session, Cookie & Token — Learning Bundle. Canonical members: Web Session, HTTP Cookie, Access Token Why this comparison helps: Choose each tool by its lifetime, travel path, and how someone can cancel it. Also check what the client can see. These choices must fit the threat model. Do not treat the bundle as one pattern when: Without a threat model, do not store long-lived bearer tokens where browser scripts can read them. Comparison requirements: Name every member concept on its own. Explain its job and limits. Show every member in the same real situation. Give a visible sign for when to use, combine, or leave out each member. Decision quality: Keep platform and evidence limits clear. Show which members can work together. Point out false matches, unsafe swaps, and cases that need another concept. Acceptance criteria: A reader can explain each member in one sentence and tell them apart in the example. They can defend the chosen member or valid group and open every canonical guide. Evidence and limits (evidence boundary): This is not a normative standard. Its name, limits, and expected behavior can change from one source to another. Unknowns to confirm: Target platform, decision setting, limits, and evidence needed to use, combine, or leave out members.
Check this request
Review the current use of Session, Cookie & Token — Learning Bundle. Definition: This learning bundle separates three related tools. A session keeps continuity that the server knows. A cookie is browser-managed state sent by set rules. A token carries claims or authority. The bundle is not one standard identity term. Release checks: Check that every member concept has its own name and link. Show all members in the same situation. Give a visible rule for when each one applies and which groups are valid. Never present the bundle as one canonical pattern or as parts that can be swapped freely. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.