Authentication Architecture: Sessions, Tokens and Trade-offs

Authentication decisions are hard to reverse once clients depend on them, and the properties that matter — revocation, storage, refresh — are decided early and quietly. This guide covers the trade-offs, drawing on FISTA Solutions' web and mobile work.

What are the main approaches?

Fewer than the vocabulary suggests, distinguished mostly by where state lives.

Approach	Characteristics
Server-side sessions	Immediate revocation, shared store needed
Stateless tokens	Scales across services, revocation harder
Tokens with revocation list	Middle ground, reintroduces state
Cookie-stored tokens	Not reachable by JavaScript
Local-storage tokens	Convenient, readable by injected script
Delegated identity	Provider handles credentials

When are sessions the right answer?

For web applications with a single backend, which is most of them.

Revocation is immediate — delete the record — and the credential is a cookie the browser handles, never visible to JavaScript. Both properties are difficult to replicate with stateless tokens.

The objection is usually scaling, and a shared session store handles considerably more traffic than most applications produce. Reach for tokens because you have several services verifying identity, not because sessions sound old-fashioned.

What do tokens buy and cost?

They buy verification without a shared store, which matters when several services must check identity independently.

They cost revocation. A token valid for an hour remains valid for an hour after you want it not to be, unless you add a revocation check — which reintroduces the shared state the tokens were meant to avoid.

Short lifetimes with refresh is the usual compromise, and it moves the complexity into refresh handling rather than removing it.

Where should credentials be stored?

In an HTTP-only, secure, same-site cookie wherever the client is a browser.

Local storage is readable by any script running on the page, which means a single cross-site scripting bug becomes account compromise rather than a defacement. That is a substantial difference in consequence for a small difference in convenience.

Mobile applications have different options — platform keychains — and the principle is the same: keep the credential where application code does not routinely handle it.

What makes refresh handling difficult?

Concurrency. Several requests hitting an expired token at once each attempt a refresh, and with rotating refresh tokens only the first succeeds.

Without coordination — a single-flight refresh with the others waiting — users experience random logouts that are difficult to reproduce. This is the most common authentication bug in single-page applications.

Handle it in one place in the client, not in each request path. Scattered refresh logic produces exactly the race it was meant to avoid.

How should revocation be designed?

Decide what needs to happen when a user logs out, changes password, or is disabled, and how quickly.

Immediate revocation requires server-side state. Acceptable delay allows short-lived tokens without it. Both are legitimate; what is not is discovering after an incident that a disabled account remained valid for the token lifetime.

Write the requirement down before choosing the architecture, because it is the property the architecture is chosen for.

Where does authorisation fit?

After authentication, in the service that owns the resource.

A valid credential establishes identity. What that identity may do depends on the resource and its rules, which the authentication layer does not know. Systems that treat a valid token as permission have conflated the two.

Keep claims in tokens minimal and current. Permissions embedded in a long-lived token are stale permissions, and stale permissions are how access persists after it should have ended. See API gateway guide.

What are the common mistakes?

Tokens in local storage. Scattered refresh logic. Permissions embedded in long-lived tokens. No revocation requirement decided up front. And treating a valid credential as authorisation.

How do you test it?

Test refresh under concurrency, test revocation timing, test behaviour when a token expires mid-operation, and test that logout actually invalidates.

The concurrency test is the one most often skipped and the one that catches the random-logout class of bug before users report it.

What does it cost to operate?

Modest for either approach. A managed identity provider trades a subscription for a great deal of implementation and maintenance, and it is usually the right choice below substantial scale.

The cost that matters is the migration later, which is why the decision deserves attention now.

What should you measure?

Failed authentication rate, unexpected logout rate, refresh failure rate, and time from account disablement to effective revocation.

What about machine and agent access?

Give every non-human caller its own identity with scoped permissions rather than sharing a human's credentials.

Agents acting under a person's account make audit impossible and their reach unlimited. A service identity with least-privilege scopes makes actions attributable and bounded, which matters more as agents take more actions. See what is least privilege for AI agents.

When is this the wrong approach?

Building authentication yourself is usually the wrong choice. A managed provider handles flows, storage, rotation, and the attacks you have not thought about, and the cases where building it is justified are narrower than teams assume.

What should you do first?

Write down how quickly a disabled account must lose access. That single requirement determines most of the architecture.

How FISTA Solutions helps

FISTA Solutions builds and operates production systems through web and mobile, AI enablement, and staff augmentation: credentials kept out of JavaScript's reach, refresh handled in one place so concurrency does not log users out, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To scope this work, message FISTA on WhatsApp, or read single sign-on implementation.