Authentication Flow on the Web

Authentication Flow
on the Web

Innovisal Security & Architecture 9 min read

At some point, most web developers reach the same stage. Login works. Signup works. Users can sign in. But something still feels wrong.

Session end without warning. Refreshing the page logs the user out. Tokens either last forever or expire too quickly. Security feels confusing and hard to reason about.

That's usually when it becomes clear that authentication is more than a form and an API call. It's a complete flow. Understanding it is one of the most important things you can learn.

What Authentication Really Means

Authentication answers a single question: "Who are you?"

It does not answer what you are allowed to do, what data you can access, or what role you have. Those come later and fall under authorization. On the web, authentication is about proving identity across many requests, not just one. This is necessary because HTTP does not remember anything. Each request is treated as new. So the real problem authentication solves is:

How does the server know this is the same user every time?

The Big Picture Flow

Almost every authentication system follows the same basic pattern. The user sends credentials. The server checks them. If they are valid, the server creates proof that the user is authenticated. The client stores that proof and sends it with every future request.

CLIENT SERVER 👤 🖥️ Email + Password ① Send credentials Hash & compare ② Verify identity Sign token / session ③ Return proof Store in cookie ④ Store proof ⑤ Every request + proof Verify & allow/deny

High-level authentication sequence — client ↔ server

The Six Steps, Explained

1

Send Credentials

User enters email + password. Passwords are never compared as plain text — the server hashes the input and compares against the stored hash.

2

Server Verifies Identity

If credentials match, the server trusts the user for this single request. Every subsequent request still needs proof.

3

Create Proof of Identity

The server creates a session record (stored server-side, ID sent via cookie) or a signed JWT (stateless, sent to client). Many modern systems combine both with a refresh token.

4

Store the Proof

Tokens can live in memory, localStorage, or cookies. Safest: HttpOnly cookies — inaccessible to JavaScript, auto-sent with requests.

5

Send Proof with Every Request

Cookies are sent automatically. JWTs go in an Authorization: Bearer <token> header. The server does not remember — it only trusts what arrives.

6

Verify on Every Request

Check the session or token, confirm it hasn't expired, identify the user, then allow or deny. Authentication is not a one-time event.

Token Expiry & Refresh

This is where many beginner setups fall apart. When a user logs in, the server gives them a token — a temporary proof of identity. But tokens aren't meant to last forever.

If a token gets stolen and never expires, an attacker could use it indefinitely. By making tokens expire quickly, the system limits potential damage. The downside: users get logged out repeatedly, making the app feel broken.

The solution: two tokens that work together.

Access Token
  • Short-lived (minutes)
  • Sent with every API call
  • Reduces risk if stolen
  • Stored in memory or cookie
Refresh Token
  • Long-lived (days or weeks)
  • Used only to get a new access token
  • Stored securely (HttpOnly cookie)
  • Invalidated on logout
Client Access token expired Server New access token issued Refresh token sent instead Access expired → send refresh → receive new access token (silently)

Token refresh flow — happens silently in the background

When implemented correctly, this entire process happens silently. Users stay logged in for long periods without noticing. When implemented poorly, users experience random logouts, failed requests, or constant authentication prompts.

Logout Is Also Authentication

Logging out is not just clearing client-side data. A proper logout must invalidate the session or refresh token server-side, remove all client-side data, and prevent reuse. If a token still works after logout, the flow is incomplete.

Common Mistakes

  • Storing sensitive tokens in unsafe places (e.g. localStorage for JWTs)
  • Never expiring access tokens
  • Mixing authentication with authorization logic
  • Trusting client-side checks instead of server-side verification
  • Ignoring refresh token failures silently
  • Forgetting CSRF protection on cookie-based flows

Authentication Is Infrastructure

Login forms are simple. Authentication flows are infrastructure. They affect security, user experience, scaling, and trust. Once you understand the full flow, problems become easier to diagnose. Logs make more sense. Edge cases feel manageable.

Authentication isn't complicated because it's clever. It's complicated because it has to work across requests, tabs, devices, and networks — all while defending against attacks and keeping the user experience smooth.

Once you understand the flow, you stop copying examples and start making informed decisions. That is the shift from beginner to intermediate.