Jonathon Klem

Deep State vs Client State: Who’s Really in Control

Jun 03, 2025

Who’s running your app — your server, your client, or a silent third party you forgot you even wired in?

As I’ve been revamping the API layer for ManageMemberships, I’ve started seeing how layered and political “state” really is. You’ve got tokens, hashes, cookies, headers, and sometimes ghosts from past refactors — all arguing over who gets to say what’s true.

This post breaks down some of the mechanisms that silently govern your app’s trust and control. Some are old-school. Some are newer. All of them fight for dominance behind the scenes.

CSRF Tokens

This is probably everyone's first foray into state management. It’s old-school and tied to server-side sessions.

Laravel ships with CSRF protection by default. So do many other frameworks. It works like this: the server generates a random token, embeds it into your form, and checks it again on form submission. If the token is missing or incorrect, the request is rejected.

Why it matters:
Imagine you're logged into your admin panel. Someone tricks you into clicking a link like:

yoursite.com/add_user?name=Bad+Guy&role=admin

Without CSRF protection, that request could create a new admin account. CSRF tokens ensure that the request originated from your actual site, with a valid user session.

JWT (JSON Web Tokens)

I first used JWTs in a Go + Lambda + MongoDB + Auth0 setup (ATFGunDB) where storing server-side sessions wasn't an option.

A JWT is a signed token that contains user data like ID, role, and expiration time. The server can verify the signature without needing to store session info.

Example payload:

{
  "sub": "1234567890",
  "name": "Jon",
  "role": "admin",
  "exp": 1717371717
}

The token is signed using a secret or private key. The client stores it (usually in localStorage or a cookie) and sends it with every request.

Why it matters:
JWTs move state to the client. The server doesn’t maintain sessions, but still gets all the info it needs to authenticate the user. This makes JWTs ideal for stateless APIs and serverless environments.

Yes, JWTs have critics, but when used properly, they’re powerful.

HMAC / Signed URLs

I ran into this on a WordPress project. We had a React frontend that needed to fetch data from the backend, but didn’t want to rely on sessions or auth tokens.

Instead, we generated signed URLs with HMAC hashes:

/api/data?report=engagement&expires=1717371717&sig=abc123

The backend recalculates the signature using a shared secret. If the signature is valid and the expires timestamp hasn’t passed, the request is allowed.

Why it matters:
This approach is great when the frontend doesn’t manage session state. It allows you to securely expose specific data with controlled access and expiration.

NONCEs

A nonce ("number used once") is a one-time-use random string used to prevent replay attacks.

They're commonly used in:

  • OAuth authentication flows
  • Content Security Policy (CSP) headers
  • Encryption schemes

Some systems store nonces temporarily server-side, others build them into signatures in a way that doesn't require tracking.

Why it matters:
Nonces protect actions that should never be repeated. They ensure that even if a request is intercepted, it can’t just be replayed later.

Final Thoughts

If you think of "state" as just a session or a Vuex store, you’re missing the broader picture.

  • JWTs push identity and state to the client.
  • CSRF tokens protect form submissions and session integrity.
  • HMACs validate requests without storing anything.
  • Nonces stop replay attacks and enforce one-time use.

All of these tools help you manage trust, timing, and identity in a stateless world. Understanding how and when to use them will save you from subtle bugs and nasty exploits.

In the end, your app is only as trustworthy as the guards at the gates. Whether it’s a CSRF token or a signed URL, each piece is a vote in a digital power struggle.

The deep state isn’t a conspiracy — it’s your middleware.

Go Back