What Is a Login and How Does It Work in Web Applications?

A login is the step where a web application verifies that a user is who they claim to be, then starts a session so the user doesn't have to re-enter credentials on every request. It matters most when you're designing or reviewing an auth flow: the login itself is usually simple, but the session mechanism behind it determines how secure, scalable, and hard to maintain your application becomes. This explainer covers the standard flow, the session-vs-token decision, and the security concerns that show up in practice.

Authentication vs. authorization

These two terms get used interchangeably, but they answer different questions:

• Authentication — Who are you? Verifying identity, typically with a password, a one-time code, or a third-party provider (Google, GitHub).
• Authorization — What are you allowed to do? Deciding whether an authenticated user can read a record, edit a setting, or call an admin endpoint.

Login is an authentication event. Authorization happens after it, on every protected request. A system can authenticate a user correctly and still get authorization wrong — for example, letting any logged-in user fetch another user's data because the endpoint only checks "is there a session?" instead of "does this session own this record?"

The typical login flow

Most web login flows follow the same shape, regardless of framework:

1. Credential submission — The client sends an identifier (email, username) and a secret (password) over HTTPS to a login endpoint.
2. Server-side verification — The server looks up the user, hashes the submitted password with the same algorithm and salt used at registration, and compares the result. Passwords should never be stored or compared in plaintext.
3. Session or token issuance — On success, the server creates a session record or signs a token and returns it to the client.
4. Credential storage on the client — The client stores that session identifier, usually in an HTTP-only cookie or in memory.
5. Subsequent requests — The client attaches the credential automatically (cookie) or explicitly (Authorization header), and the server validates it before processing the request.
6. Logout / expiry — The session is invalidated server-side, or the token is discarded and allowed to expire.

The interesting design decisions are in steps 3 and 5, because that's where session cookies and token-based approaches diverge.

Session cookies vs. token-based approaches

Both models answer the same question — "is this request from an authenticated user?" — but they store the answer in different places.

A common middle ground is a short-lived access token plus a longer-lived refresh token. The access token is used for normal requests and expires quickly (minutes), limiting the damage if it leaks. The refresh token is used only to obtain new access tokens and is stored more carefully. Refresh token rotation means each use of a refresh token issues a new one and invalidates the old — so if a stolen refresh token is replayed, the server can detect the reuse and revoke the whole session chain.

SuperTokens, for example, describes its architecture around rotating refresh tokens and anti-CSRF measures, which is the pattern above applied as a product. The general lesson holds whether or not you use a library: short access tokens plus rotating refresh tokens give you most of the statelessness of JWTs without giving up the ability to revoke a session.

Security concerns that actually bite

• CSRF (cross-site request forgery) — If your credential is a cookie sent automatically, another site can trigger authenticated requests on your behalf. Mitigations include SameSite cookie attributes, CSRF tokens, and custom-header requirements.
• XSS (cross-site scripting) — If an attacker runs script in your page, they can read tokens stored in JavaScript-accessible storage. HTTP-only cookies are not readable by script, which is why they're often preferred for session identifiers.
• Token rotation — Without rotation, a leaked refresh token is valid until it expires. With rotation plus reuse detection, a leak becomes detectable.
• Secure credential storage — Passwords must be hashed with a slow, salted algorithm (bcrypt, scrypt, Argon2), never encrypted reversibly or stored raw.
• Session fixation — The session identifier should be regenerated on login so an attacker who set a known session ID beforehand can't hijack the authenticated session.

Where open-source auth tools fit

You can implement all of the above yourself, and for a small app that's sometimes reasonable. The cost shows up later: refresh token rotation, CSRF protection, session revocation, and multi-provider login are each individually tractable but collectively a maintenance burden. Open-source auth projects exist to package those flows so you configure them rather than rebuild them.

When evaluating one, check the same dimensions you'd check in a hand-rolled implementation:

• Does it use HTTP-only cookies, header tokens, or both, and can you choose?
• How does it handle refresh token rotation and reuse detection?
• What CSRF protections are built in?
• Can sessions be revoked immediately, or only on expiry?
• What's the migration path if you outgrow it?

SuperTokens, the source behind this explainer, is one such open-source option — its site emphasizes prebuilt UI, a plugin system for customizing auth, and a stated setup time of about five minutes via npx create-supertokens-app@latest. Treat those as vendor claims to verify against your own requirements rather than as settled facts, and check the current pricing page for licensing and cost details, since those change.

The takeaway for reasoning about any login system: separate the identity check from the session mechanism, pick your session model based on whether you need instant revocation or stateless scaling, and treat CSRF, XSS, and token rotation as first-class requirements rather than afterthoughts.