One wristband, a bouncer who never remembers you, and a quiet stamp at the back door.

Login & what a JWT actually is

The user types email + password once. The server checks them, and if they're right it doesn't hand back "yes, you're logged in" — it hands back a token. The most common kind is a JWT (JSON Web Token): a long string the client keeps and shows on every future request.

A JWT has three parts joined by dots: header.payload.signature. The payload holds claims like your user id and an expiry time. The signature is the server's secret seal — anyone can read a JWT, but only the server can forge a valid one. That's why it's tamper-proof but not secret.

// a decoded JWT payload — readable by ANYONE, do not put secrets here
{
  "sub": "user_8412",   // who
  "role": "admin",
  "iat": 1717800000,    // issued at
  "exp": 1717803600     // expires (1 hour later)
}

Two tokens: access vs refresh

Real apps hand back two tokens, not one. They solve opposite problems, so they have opposite lifespans.

Why two? If you used one long-lived token everywhere, a single leak would give an attacker weeks of access. Splitting them means the token that travels constantly is the one that expires fast.

The whole token family

"Token" is a category, not one thing. Beyond access + refresh, there are a few you'll meet — and the first real fork is self-contained vs reference tokens.

The ones you'll actually name

Where to store the token

This is the question interviewers actually care about, because the wrong storage opens you up to attacks. The answer is different on web vs mobile.

Web (React / Next.js)

Rule of thumb: anything JavaScript can read, an XSS payload can read too. httpOnly cookies are the only web storage JS genuinely cannot touch — which is exactly why the refresh token belongs there.

Mobile (React Native)

Attaching the token to every request

A protected endpoint won't trust an empty request. You attach the access token in the Authorization header on every call, using the Bearer scheme. Doing this by hand on each fetch is error-prone, so you centralize it in one interceptor.

// axios — one place, every request gets the token
api.interceptors.request.use((config) => {
  const token = getAccessToken();
  if (token) config.headers.Authorization = `Bearer ${token}`;
  return config;
});

The 401 & the silent refresh

Access tokens expire on purpose. When one does, the next protected call comes back 401 Unauthorized. A naive app logs the user out here — but a good one fixes it invisibly using the refresh token.

You catch the 401 in a response interceptor: call the refresh endpoint, get a new access token, then replay the original request with it. The user sees their data load normally — they never knew a token expired.

// response interceptor — refresh once, then retry the original request
api.interceptors.response.use(
  (res) => res,
  async (error) => {
    const original = error.config;

    if (error.response?.status === 401 && !original._retried) {
      original._retried = true;
      const newToken = await refreshAccessToken();  // uses refresh token
      setAccessToken(newToken);
      original.headers.Authorization = `Bearer ${newToken}`;
      return api(original);   // replay it
    }

    return Promise.reject(error);  // refresh failed → log out
  }
);

Single Sign-On (SSO) & "Log in with Google"

SSO means one login gets you into many apps. Instead of your app checking the password itself, it delegates to a trusted identity provider (IdP) — Google, Microsoft, Okta, Auth0, your company's login. The user proves who they are there, and the IdP vouches for them back to your app.

The three names you'll hear

The modern flow is OIDC Authorization Code + PKCE (PKCE is the variant safe for SPAs and mobile, where you can't keep a client secret):

Everything working together

This is the whole cycle on one page. Follow the numbered arrows: log in once, attach the wristband on every call, and when it stops glowing, swap it at the back door and retry. Memorize this shape and you can rebuild every answer from it.

Read it as a sentence: log in once → store the tokens → attach the access token to every call → on a 401, use the refresh token to get a new access token → retry the original request (and only log out if the refresh itself fails). That single sentence is the entire model.

The classic "where do you store the JWT?" question

This is the auth question that separates tutorial-followers from people who've shipped. The trap answer is "localStorage." The strong answer names the threat and splits web from mobile.

// WEB (React / Next.js)
access token   → in memory (React state / closure)
refresh token  → httpOnly + Secure + SameSite cookie

// MOBILE (React Native)
both tokens    → Keychain (iOS) / Keystore (Android)
              via expo-secure-store or react-native-keychain

// NEVER
localStorage (web)  ·  AsyncStorage (mobile)  ← readable by attackers

Walk the interviewer through the why:

localStorage is readable by any JavaScript on the page → one XSS bug leaks the token.
httpOnly cookies can't be read by JS at all → XSS can't steal them (pair with SameSite to handle CSRF).
In-memory dies on tab close and never hits disk → smallest attack window for the access token.
Keychain / Keystore is OS-level encrypted and app-sandboxed → the mobile equivalent of "safe by default."