JWT in Cookies vs Bearer Tokens for React Native and Web

Key facts, with sources

• In the JetBrains Python Developers Survey 2024, which collected responses from more than 30,000 Python developers, FastAPI usage jumped from 29% to 38%, overtaking Django (35%) and Flask (34%) as the most-used Python web framework. (JetBrains Python Developers Survey 2024)
• The 2025 Stack Overflow Developer Survey shows FastAPI at 14.8% of respondents doing extensive work with it, edging out Flask at 14.4% and Django at 12.6%. (Stack Overflow Developer Survey 2025)
• FastAPI's official documentation cites independent TechEmpower benchmarks showing FastAPI applications running under Uvicorn as one of the fastest Python frameworks available, ranked only below Starlette and Uvicorn themselves. (FastAPI official documentation)
• FastAPI surpassed Flask in GitHub stars in December 2025, reaching roughly 88,000 stars compared to Flask's 68,400. (DZone)
• Industry analysis of FastAPI's 2025 growth reports about 40% year-over-year growth in job mentions and production adoption at companies including Uber, Netflix, and Microsoft. (byteiota)

The core trade-off: XSS vs CSRF

A bearer token stored in JavaScript-reachable storage (or even in memory) can be exfiltrated if your web app has an XSS hole — the script reads the token and sends it away. An httpOnly cookie is invisible to JavaScript, so XSS cannot read it — but because the browser attaches it automatically to every request to your domain, it is vulnerable to CSRF unless you add protection (SameSite, a CSRF token). So the choice is really: which attack are you defending against, and does your client even have a browser.

React Native: bearer tokens win by default

A native React Native app is not a browser. It has no automatic cookie jar, no same-origin policy, and no XSS surface in the web sense. Storing a token in Expo SecureStore (Keychain/Keystore) and sending it as an Authorization header is both simpler and appropriate. Trying to force httpOnly cookies into a native app means fighting the platform for a protection (XSS-immunity) you do not need.

import * as SecureStore from "expo-secure-store";

api.interceptors.request.use(async (config) => {
  const token = await SecureStore.getItemAsync("accessToken");
  if (token) config.headers.Authorization = `Bearer ${token}`;
  return config;
});

Web: httpOnly cookies are usually safer

For a browser client, an httpOnly, Secure, SameSite cookie keeps the token out of reach of any injected script — the single biggest token-theft vector on the web. The trade is that you now defend CSRF, mostly handled by SameSite=Lax or Strict plus a CSRF token on state-changing requests. FastAPI can set the cookie on login and read it on protected routes.

@router.post("/auth/login-web")
def login_web(body: LoginIn, response: Response, db: Session = Depends(get_db)):
    user = authenticate(db, body.email, body.password)
    if not user:
        raise HTTPException(401, "invalid credentials")
    response.set_cookie(
        "access_token", mint_access_token(user.id),
        httponly=True, secure=True, samesite="lax", max_age=900,
    )
    return {"message": "signed in"}

Serving both from one FastAPI backend

When the same API backs a mobile app and a web app, do not pick one transport and compromise the other. Accept the token from either place: read the Authorization header if present, otherwise fall back to the cookie. The token itself, its signing, expiry, and refresh logic are identical — only the transport differs per client. This keeps the mobile app on bearer tokens and the web app on httpOnly cookies without duplicating any auth logic.

from fastapi import Request, HTTPException

def get_token(request: Request) -> str:
    auth = request.headers.get("Authorization")
    if auth and auth.startswith("Bearer "):
        return auth.split(" ", 1)[1]         # mobile: bearer token
    cookie = request.cookies.get("access_token")
    if cookie:
        return cookie                        # web: httpOnly cookie
    raise HTTPException(401, "not authenticated")

When to hire senior help

Bring in senior help when your API needs to handle real concurrency, when you are designing service boundaries and auth for the first time, or when an existing FastAPI codebase mixes sync and async code and latency is degrading. An experienced engineer can usually diagnose event-loop blocking and connection-pool misconfiguration in days, which is far cheaper than re-architecting after launch. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Python — FastAPI Development projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Calling blocking libraries (classic SQLAlchemy sessions, requests, heavy file I/O) inside async def endpoints, which stalls the event loop and erases FastAPI's concurrency advantage
• ✕Deploying a single Uvicorn process with no process manager or worker scaling, leaving most CPU cores idle under production load
• ✕Treating the auto-generated OpenAPI docs as a versioning strategy, then breaking mobile and partner clients when response schemas change
• ✕Running large payloads through deeply nested Pydantic models on every request and response, adding serialization latency that shows up only at scale

Frequently asked questions

Sources

• JetBrains Python Developers Survey 2024
• Stack Overflow Developer Survey 2025
• FastAPI official documentation
• DZone
• byteiota