How Login Works

Authentication answers one question: who is this user? Before your app can show a personal dashboard or save someone's data, it has to confirm the visitor is who they claim to be.

When you build by prompting an AI assistant, you don't need to memorize every detail. But you do need a mental model so you can ask precise questions and judge whether the generated code is safe.

Two words get mixed up constantly. Authentication confirms identity. Authorization decides what that identity is allowed to do.

A logged-in user is authenticated. Whether they can delete another person's post is authorization. Keeping the two separate in your prompts leads to cleaner code and fewer security holes.

A typical login works like this: the user submits an email and password, the server checks the credentials, and if they match it issues a proof of identity. The browser stores that proof and sends it with every future request.

That proof is usually a session cookie or a token. Understanding this loop helps you debug "why am I logged out?" problems later.

Your app should never store raw passwords. Instead it stores a hash: a one-way scrambled version produced by an algorithm like bcrypt or argon2.

When a user logs in, the server hashes the submitted password and compares it to the stored hash. If your database leaks, attackers only get hashes, not the actual passwords.

There are two common ways to remember a logged-in user. Session-based auth stores a session ID in a cookie and keeps the matching record on the server. Token-based auth (like JWT) hands the client a signed token that carries the user's identity.

Sessions are easy to revoke; tokens scale well across services. Many modern stacks use a hybrid, so ask which one your tool defaults to.

However the proof is stored, cookies are how the browser sends it back automatically on each request. The key is making those cookies safe.

Look for three flags: HttpOnly stops JavaScript from reading the cookie, Secure forces HTTPS, and SameSite limits cross-site sending. Missing flags are a common vibe-coding mistake.

Stateful auth means the server remembers each active session in memory or a database. Stateless auth means the server trusts a signed token and stores nothing per-user.

Stateful gives instant logout but needs shared storage. Stateless is simpler to scale but harder to revoke early. Neither is universally "better" — it depends on your app's size and needs.

Logging out should actually destroy the proof of identity, not just hide a button. For sessions, the server deletes the session record. For tokens, the client discards the token and the server may add it to a blocklist.

A common bug: the UI shows "logged out" but the cookie still works. Always test that protected pages truly reject you after logout.

Proof of identity should not last forever. Sessions and tokens expire after a set time so a stolen cookie has a limited window of use.

To keep users from logging in constantly, many systems use a short-lived access token plus a longer refresh token that quietly renews it. Ask your assistant to set sensible expiry times for your use case.

In most apps, auth logic sits in a few predictable places: a login route, a signup route, middleware that checks each request, and a small client helper that knows the current user.

Knowing this map lets you prompt surgically. Instead of "fix my login," you can say "update the middleware that verifies the session cookie."

A few attacks target login systems directly. Credential stuffing reuses leaked passwords, brute force guesses many passwords fast, and session hijacking steals a valid cookie.

You don't have to solve all of these by hand. But mentioning them in prompts — like asking for rate limiting on the login route — nudges your assistant toward safer defaults.

Let's confirm the core idea before moving on.

You now have a working model of login: authentication proves who a user is, passwords are hashed not stored, and a session or token becomes the proof carried in cookies on each request.

You also saw the lifecycle — login, expiry, refresh, logout — and where auth code lives. With this map, your prompts to an AI assistant can be specific and safe.