Cookies or Bearer Tokens? The Day my Auth Design Decision Broke.

Srinivas Mekala — Sat, 11 Jul 2026 16:20:13 +0000

It's been 3 months since I was actively building StashD -- a link-organizing app. NextJs on the frontend, Flask + MongoDB on the backend. Auth was one of the first things I had to get right, so I did what felt like the "correct" thing at the time: httpOnly cookies. Secure, invisible to JavaScript, browser handles everything for me. I shipped it, moved on, felt good about the decision.

Today, I thought, why don't I build a mobile app so my users can access their saved links from their phones on demand.

The Moment It Fell Apart

I sat down to think through how the mobile app would authenticate, researched a lil bit, and it hit me in the face: there's no browser cookie jar on a native app🤦🏻‍♂️. My entire auth flow assumed a browser sitting between the user and my API — one that would store a cookie and automatically reattach it on every request without me writing a line of code for it. That assumption had been invisible to me the whole time I was building for web only, because it was just... always true. Every request from the browser already carried the cookie. I never had to think about the mechanism, so I never noticed I'd built a dependency on it.

A mobile app doesn't get that for free. There's no automatic anything. If I wanted the Android app to authenticate against the same Flask API, I'd need to manually attach a token to every request myself. Which meant my whole "cookie is the auth mechanism" design was actually "cookie is a auth mechanism, coupled to exactly one client — the browser."

That was the first real lesson:

An auth design that only works because of an environment-specific behavior isn't a design, it's an accident that happens to work in one place.

It's Time to Rewind the Reel

I had to stop and actually understand why I picked cookies in the first place, instead of just knowing that I had. Here's what I worked out.

A cookie and a bearer token carry the same thing — a JWT. The difference is entirely about who attaches it to a request:

Cookie: the browser attaches it automatically, for every request matching the cookie's domain. I don't have to write the attachment logic.
Bearer token: my code does it, manually, via an Authorization: Bearer <token> header. Nothing happens unless I write that line.

That's it. That's the whole difference. But that one difference cascades into everything else.

Did I pick Cookies blindly? No!: _httpOnly _cookies can't be read by page JavaScript. If someone ever manages to inject a malicious script into my site (XSS), that script cannot steal the token — it's invisible to document.cookie. If I had instead put my JWT in localStorage, any XSS bug becomes a full account takeover, and the stolen token is portable — usable from the attacker's own machine, forever, until it expires.

That's a real, good reason to prefer cookies. I took it as "best practice" without connecting it to the actual mobile-shaped hole in the design.

But cookies aren't free. Because the browser attaches them automatically, a malicious site can trick a victim's browser into firing a request at my API with the cookie riding along — that's CSRF. Next.js comes to the rescue here: it defaults cookies to SameSite=Lax, which blocks that for state-changing requests.

Bearer tokens flip both properties. Immune to CSRF by construction — there's no ambient credential for a third-party site to hijack, since nothing is attached automatically. But if the token sits in localStorage or a JS variable, XSS can read it directly, and now it's stolen, not just abused-in-session.

Neither one is "more secure" in the abstract. They're secure against different things, and the win depends entirely on the shape of your client.

My Second Lesson: What do I change to support both mobile and web requests?

My first plan was: keep cookies for web, add a second code path in Flask that also accepts a bearer header for mobile. Check cookie first, fall back to header. Felt like the minimal change.

It would have worked. But sitting with it a bit longer, I realized I was about to bake "what kind of client is calling me" into my backend's auth logic, permanently, for every route, forever. Two paths to test, two paths to audit for security holes, and the set only grows if I ever add a third client.

The better shape, once I saw it: the backend shouldn't know or care what kind of client is calling it. Make the API bearer-only, full stop. It returns a token in the response body on login, and validates one thing — the Authorization header — on every protected route. No branching.

Then the cookie isn't a backend concern at all anymore. It becomes something the web app does to itself — my Next.js server receives that bearer token same as any other client would, and wraps it in its own httpOnly cookie before it ever reaches the browser. When the web server needs to call the API on the user's behalf, it just reads its own cookie back out and forwards it as a bearer header. The Flask API never even knows a cookie existed anywhere in the chain.

The mobile app does the same thing, minus the cookie step — takes the token from the response body, drops it straight into secure device storage (Keystore-backed on Android), attaches it as a bearer header on every call. No intermediary needed, because a native app doesn't have the XSS threat model a browser has in the first place.

Two clients, two completely different ideas of "how do I protect this token" — and the backend doesn't have to know either one exists. That's the part I actually feel good about: not "I added mobile support," but "I found the layer where the client-specific decision actually belongs, and moved it there."

PS: Try out my WebApp : StashD.
Hope you like it and wait for the mobile version too.🫡✌🏻

DEV Community: Srinivas Mekala

Cookies or Bearer Tokens? The Day my Auth Design Decision Broke.

The Moment It Fell Apart

It's Time to Rewind the Reel

My Second Lesson: What do I change to support both mobile and web requests?