What Is Authentication and How Does It Work in Web Applications?

Authentication is the process of verifying that a user, service, or device is who it claims to be. In a web application, it answers the question "who are you?" before the system decides what that identity is allowed to do. It is distinct from authorization, which answers "what are you allowed to access?" Authentication typically relies on one or more factors (something you know, have, or are), and it usually produces a session or token that the application uses to recognize the user on subsequent requests. This explanation covers the core components, common methods, and security considerations, using SuperTokens as an example of an open-source authentication system.

Authentication vs. Authorization

These two terms are often confused because they usually appear together in a login flow, but they describe different steps.

A system can authenticate a user successfully and still deny every action if that user has no permissions. Conversely, authorization rules are meaningless without a trusted identity behind them.

Authentication Factors

Authentication methods are usually grouped by the type of evidence they require.

• Something you know: passwords, PINs, security questions.
• Something you have: a phone, hardware key, or an authenticator app that generates codes.
• Something you are: fingerprints, facial recognition, or other biometrics.

When a system requires two or more of these categories, it is called multi-factor authentication (MFA). For example, a password (know) plus a one-time code from an authenticator app (have) is two-factor authentication. MFA reduces the impact of a stolen password, because the attacker still lacks the second factor.

How a Typical Web Login Works

A standard authentication flow follows a predictable sequence:

1. Credential submission. The user sends an identifier (such as an email) and a secret (such as a password) to the server.
2. Verification. The server checks the secret against a stored, hashed version. Passwords should never be stored in plain text.
3. Session or token creation. On success, the server issues a session identifier or a token that represents the authenticated user.
4. Subsequent requests. The client sends that session or token with each request so the server can recognize the user without re-checking the password.
5. Expiry and renewal. Sessions and tokens have limited lifetimes. When they expire, the user must re-authenticate or the client must refresh the token.

Session Management and Token-Based Approaches

Once a user is authenticated, the application needs a way to remember them. Two common patterns are server-side sessions and token-based authentication.

Server-Side Sessions

The server stores session data and gives the client only a session ID, usually in a cookie. The server looks up the session on each request. This keeps sensitive data on the server and makes revocation straightforward, but it requires shared session storage when the app runs on multiple servers.

Token-Based Authentication (JWT and Refresh Tokens)

With token-based authentication, the server issues a signed token, often a JSON Web Token (JWT), that contains claims about the user. The client sends the token with each request, and the server verifies the signature instead of looking up a session.

A common refinement is the rotating refresh token pattern:

• A short-lived access token is used for API requests.
• A longer-lived refresh token is used only to obtain new access tokens.
• The refresh token rotates on each use, so a stolen token becomes invalid once the legitimate client refreshes.

This limits the damage from a leaked access token, since it expires quickly.

Security Considerations

Authentication is a high-value target, so a few protections matter in almost every implementation.

• Secure credential storage: hash passwords with a modern algorithm and a per-user salt; never store them reversibly.
• CSRF protection: if authentication relies on cookies, cross-site request forgery (CSRF) can trick a logged-in browser into sending unwanted requests. Anti-CSRF tokens or same-site cookie attributes help prevent this.
• Token handling: keep tokens out of URLs, use HTTPS, and set sensible expiry times.
• MFA: add a second factor for sensitive accounts.
• Rate limiting and lockouts: slow down brute-force attempts against login endpoints.

Example: Open-Source Authentication with SuperTokens

SuperTokens is an open-source user authentication system that illustrates several of these concepts in practice. Its site describes it as "Open Source User Authentication" with the goals to "Build fast. Maintain control. Reduce costs." and notes a setup path using npx create-supertokens-app@latest. It also lists session management, JSON web tokens, anti-CSRF, and rotating refresh tokens among its keywords, which map directly to the mechanisms described above: token-based sessions, CSRF protection, and refresh-token rotation. The project is described as Y Combinator backed and trusted by startups and enterprises, and it offers a pricing page for its commercial options. For teams evaluating authentication, an open-source option like this can be compared against building authentication in-house or using a managed identity provider, weighing control, maintenance effort, and cost.

Key Takeaways

• Authentication verifies identity; authorization controls access. They are separate steps.
• Factors fall into know, have, and are categories; combining them gives MFA.
• Sessions and tokens are the two main ways to remember an authenticated user.
• JWTs, refresh-token rotation, CSRF protection, and secure password storage are core security practices.
• Open-source solutions such as SuperTokens provide a starting point that implements many of these patterns.