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.

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
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
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
Quick check
Your admin page hides the Delete button for normal users. Is the delete action now secure?
Go deeper
- 1Build a login form that calls a real or mock auth endpoint.
- 2Learn where to store the resulting token safely — memory vs cookie vs localStorage, each with trade-offs.
- 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.