Stop 10 · API IntegrationTopics · 8/16

Authentication

Part of the Frontend Developer Roadmap

In short

Login screens look simple, but behind them your app has to prove who the user is on every single request. Here's what the frontend's part of that job looks like.

The process of verifying who a user is (login) so protected API endpoints and pages can be securely accessed.

The jaadu shows an ID card at a college fest gate and gets a wristband from the guard.

Think of it like this

The college fest wristband

At the gate, security checks your ID card once and gives you a wristband. After that, every stall just looks at the wristband instead of checking your ID again. Logging in gets you that wristband, called a token or session cookie.

Watch it happen

Login with a session cookie

Browser
API
Database

POST /auth/login

1/5The form sends email and password over HTTPS.

The big ideas

What you need to know

Authentication vs authorisation

Authentication asks 'who are you?'. Authorisation asks 'are you allowed to do this?'. Login is the first one.

Cookie or token

The server either sets a session cookie the browser sends automatically, or returns a token your code attaches to requests.

The server decides

Hiding a button on the frontend is not security. The API must check every request on its own.

Handle 401 everywhere

If any request returns 401 Unauthorized, the user's login has ended. Send them back to the login page.

See it in code

Walk through the code

ts
1async function login(email: string, password: string) {2  const res = await fetch("/api/auth/login", {3    method: "POST",4    headers: { "Content-Type": "application/json" },5    credentials: "include", // send and receive cookies6    body: JSON.stringify({ email, password }),7  });8 9  if (res.status === 401) throw new Error("Wrong email or password");10  if (!res.ok) throw new Error("Something went wrong, try again");11  return res.json(); // e.g. { user: { id, name } }12}

1/4A normal JSON POST to the login endpoint.

credentials: "include" lets the browser store and send the session cookie. Show a clear message for wrong details, separate from server errors.

Save yourself the pain

Common mistakes

Oops

Hiding the admin menu on the frontend and calling it protected.

Do this instead

Anyone can call your API directly. The server must check permissions on every request.

Oops

Saving the user's password in localStorage to 'stay logged in'.

Do this instead

Never store passwords on the client. Store only the token or let the server manage a cookie.

Your mission

Log in to a test API

~30 min

Quick check

Your admin page hides the Delete button for normal users. Is the delete action now secure?

Go deeper

  1. 1Build a login form that calls a real or mock auth endpoint.
  2. 2Learn where to store the resulting token safely — memory vs cookie vs localStorage, each with trade-offs.
  3. 3Practice redirecting unauthenticated users away from protected pages.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge