How User Authentication Works in a Website or Web App

Authentication lets a website know who someone is. Your app doesn’t verify the password itself — an authentication service does that and returns a trusted session.

What happens when someone logs in?

1. Someone opens your site and fills in the login form with their email and password.
2. Your app does not compare that password to anything. It passes the attempt to your authentication service.
3. The service checks the credentials against the accounts it stores, and either rejects the attempt or confirms who this person is.
4. On success it hands back a session — a signed token your app keeps in the browser. From then on the session proves identity, and your app never sees the password again.
5. Every protected page checks for a valid session before it renders. No session, no access — and the same check runs on the server, not only in the browser.

The main pieces

Your visitor — A real person in a browser. Until they prove who they are, your app treats them as anonymous — they can reach the public pages and nothing else.

Login form — A form on your site that collects an email and password, or starts a "Continue with Google" redirect. It collects the attempt; it never judges it.

Sign-up form — Creates a new account with the same authentication service the login form talks to. Signing up and logging in are one mechanism, one step apart.

Authentication service — The part that actually verifies credentials and stores accounts. It is the only piece that ever handles a password, and it is almost always something you plug in rather than build.

Session — A signed token the service hands back after a successful login, kept in the browser. Your app trusts the session instead of re-checking a password on every request, and it expires on its own.

User profile — Your own record for that person: display name, avatar, plan, preferences. The authentication service knows who they are; this is where you keep everything else about them.

Protected page — Anything only a signed-in person should reach — a dashboard, an account page, saved work. It looks for a valid session before it renders, and the server checks again before it returns any data.

Your database — Where profiles and the rest of your app's data live. The login form never reaches it directly — it only ever holds data for people the authentication service has already identified.

Do you actually need authentication?

Not every site does. Authentication exists to make a page different for different people. If every visitor should see exactly the same thing, adding accounts adds work and risk for nothing.

The question worth asking is whether anything on your site belongs to one person. Saved work, an order history, a private dashboard, anything you would be uncomfortable showing a stranger — that is when you need accounts.