Compare Browser Session Storage and Transport

A credential is a value that connects a later request to an authenticated identity. Two common credential formats are an opaque session identifier, such as DEMO_SESSION_ID, and an access token, such as DEMO_ACCESS_TOKEN.

To describe a session design precisely, separate three independent dimensions:

1. credential format — what the credential value represents;
2. storage location — where it is held between uses;
3. transport mechanism — how it is carried with a request.

Do not treat “cookies versus tokens” as a complete comparison. A cookie can carry either kind of credential.

Read each row across. The same credential format can be paired with different storage locations and transport mechanisms. Likewise, a cookie is not proof that the credential format is an opaque identifier.

A credential can travel in two different ways even when it represents the same signed-in identity.

In the cookie path, the API server sends Set-Cookie; the browser accepts it into the Browser cookie store and later adds Cookie to an eligible request. In the bearer path, Page JavaScript has an accessToken value and explicitly builds an Authorization header.

The important question is: who attaches the later request header? The browser attaches Cookie; application code supplies Authorization.

A cookie exchange has two separate moments: issuance and later transport. The Set-Cookie response header asks the browser to store a cookie. On a later eligible request, the browser network layer adds the Cookie request header.

Page JavaScript can start a fetch, but it does not directly supply the Cookie header as an application header. The browser controls that header.

Illustrative exchange: API issues a session credential, then the browser sends it later.

Bearer transport works differently. Before making the request, application code must have a credential value available as accessToken. It explicitly constructs the Authorization header.

Putting a value in localStorage or sessionStorage does not automatically add it to outgoing requests. Code must read a JavaScript-accessible value and supply the header. An in-memory credential also needs code to supply the header.

This fragment uses a dummy value so the application code can construct the request header.

Secure and HttpOnly are separate cookie attributes with separate enforcement points.

• Secure restricts transmission of the cookie to HTTPS in these HTTPS deployment examples.
• HttpOnly prevents Page JavaScript from reading the cookie through cookie APIs.

Neither attribute decides whether JavaScript is executing in the page. If injected JavaScript runs, it can still attempt actions as that page.

An HttpOnly cookie is created by the API server through Set-Cookie. A React variable cannot add an equivalent protection, and document.cookie cannot create an HttpOnly cookie.

The browser processes the response header, but Set-Cookie is not a fetch response header that Page JavaScript can read. The application may receive a normal response body while the browser separately stores the cookie.

Illustrative exchange: the API server issues an HttpOnly cookie after sign-in.

Even though the cookie value is not readable through document.cookie or response.headers.get('Set-Cookie'), code executing in the affected page can request a protected same-origin resource. The browser can attach an eligible cookie; the code can then read data that the page is permitted to access.

A session design is clearer when you separate three choices:

• credential format: what proves the authenticated identity, such as an opaque sessionId or an accessToken.
• storage location: where the browser or page keeps that credential.
• transport mechanism: how it reaches the API on a protected request.

Storage does not determine format or transport. For example, an opaque sessionId can be stored in an HttpOnly cookie and sent by the browser, while an accessToken in localStorage must be read by Page JavaScript before application code supplies a bearer header.

localStorage and sessionStorage are Web Storage APIs, not server sessions. sessionStorage survives a reload during its page session, but it is normally removed when that page session ends.

An in-memory credential reduces how long a JavaScript-readable value remains stored, but a reload normally loses it. Restoring sign-in then needs an additional design decision.

An HttpOnly cookie is not automatically persistent. HttpOnly controls JavaScript cookie access; cookie lifetime attributes and browser behavior govern retention. In every row, the API separately decides whether it accepts the presented credential.

fetch has a credentials mode for browser-managed credentials such as cookies. It is a transport setting—not a credential format or storage location.

By default, fetch uses credentials: 'same-origin'. That allows the browser to attach eligible cookies to a same-origin request. For a cross-origin request, use credentials: 'include' when the request is intended to permit eligible browser-managed cookies.

The mode also affects whether the browser respects a Set-Cookie response. It never reads an access token from JavaScript storage or creates an Authorization header for you.

For a same-origin protected read, the default mode is already suitable for browser-managed cookies. Writing it explicitly can make the request policy easier to review.

Illustrative same-origin fetch from https://app.example.test.

For the cross-origin API, select include when the design permits the browser to send eligible cookies. This still does not promise that a cookie exists, qualifies for the request, or that the response will be readable by page JavaScript.

Illustrative cross-origin fetch from https://app.example.test.

A bearer header is application-supplied transport. Your code must already have an accessToken value and explicitly place it in Authorization.

credentials: 'omit' excludes browser-managed credentials such as cookies. It does not remove an Authorization header that the application explicitly supplies. Likewise, changing the mode does not retrieve a value from localStorage, sessionStorage, or an in-memory credential.

Illustrative exchange: the constructed request header is Authorization: Bearer DEMO_ACCESS_TOKEN.

A cross-origin cookie request has two separate browser decisions. First, credentials: 'include' permits eligible browser-managed credentials to travel with the request. Second, the API response must explicitly grant https://app.example.test permission to read it.

For Atlas Workspace, a response to https://api.example.test/api/me is readable by page JavaScript only when it names the requesting origin and sends Access-Control-Allow-Credentials: true. Access-Control-Allow-Origin: * cannot grant readable response access when the request uses credentials: 'include'.

Atlas Workspace explicitly permits browser-managed credentials for this cross-origin request.

This is an illustrative exchange in which an eligible atlas_session cookie is attached and the response is readable by the page.

CORS permission is not cookie attachment. The response headers can allow page JavaScript to read a response, but they do not create a cookie or force an existing cookie to be eligible for the request. Conversely, an eligible cookie does not make a cross-origin response readable without the required CORS permission.

A bearer-header request uses a different transport mechanism: application code supplies Authorization. It can use credentials: 'omit'; that setting excludes browser-managed credentials but does not remove an Authorization header that the application explicitly supplies.

The bearer credential is available to application code, so the application constructs the header itself.

Authorization requires preflight permission. A browser may reuse a previously cached successful preflight, but the API must permit the header for the request to proceed under that permission.

A logout flow has effects at different boundaries. Clearing React state, redirecting away from a private route, or clearing a JavaScript-held credential changes what the current page can do. That is local cleanup.

Local cleanup does not alter another copy of a credential and does not change the API server’s decision about whether that credential is valid. A client-side expiry timer is also interface behavior: it can sign this page out, but it is not the boundary that makes the API reject a request.

Browser credential removal changes browser retention. Server enforcement occurs when the API processes a protected request such as /api/me and rejects an expired or invalidated credential.

Page JavaScript cannot directly delete an HttpOnly cookie through cookie APIs. For application-directed logout, Atlas Workspace normally calls /api/logout; a successful API response can direct the browser to remove the cookie with an expiring Set-Cookie header.

The deletion must match the cookie identity and scope used when it was set, including its name and Path, plus Domain when applicable. An HttpOnly cookie can also disappear because its cookie lifetime expires, the browser evicts data, or the user clears site data. None of those browser events alone proves that the API has invalidated the credential.

Illustrative exchange: the API performs its defined invalidation behavior and directs the browser to remove the matching cookie.

Atlas Workspace clears its React state after sending /api/logout, but the request fails before the application receives a response. Which conclusion is justified?

Atlas Workspace needs private project data, sign-in continuity after reload, a cooperating cross-origin API, and server-confirmed logout. A defensible baseline is an opaque session identifier as the credential format, kept in a retained HttpOnly cookie as the storage location, and sent through the browser-managed Cookie header as the transport mechanism.

This reduces direct credential copying by injected JavaScript compared with a JavaScript-readable persistent credential. It does not make XSS harmless: injected code can still act as the signed-in page, issue eligible requests, and read responses that the compromised page is allowed to read. The API server remains responsible for credential validity and authorization.