Authentication & Authorization

Authentication establishes identity. The system verifies that a user is who they claim to be — typically through credentials such as a password, token, or external identity provider.

Authorization happens after identity is confirmed. The system evaluates whether that identity has permission to perform a specific action or access a particular resource.

These concerns must remain separate. Identity verification does not automatically imply access rights. A logged-in user may still lack permission to view certain data or perform administrative actions.

Conceptually: User → Login → Identity Verified → Permission Check → Resource Access.

Authentication happens first. Authorization happens after — often on every request.

Authentication begins when a user or system claims an identity and presents credentials as proof.

Username + Password is the traditional method. The server checks the submitted credentials against stored account data.

OAuth Login delegates authentication to a trusted external provider (such as Google or GitHub), which returns a verified identity to the application.

API Keys are commonly used for server-to-server authentication, identifying applications rather than human users.

Multi-Factor Authentication (MFA) strengthens identity verification by requiring a second proof (such as a one-time code or hardware token).

Conceptual flow: Login → Credentials Submitted → Server Verifies → Identity Confirmed.

No valid identity means the request stops here.

In traditional web applications, authentication is handled using server-side sessions.

When a user logs in successfully, the server generates a session object containing identity information. This session is stored on the server — commonly in memory, a database, or a distributed cache.

The server sends a session ID back to the client, typically stored in a cookie. On subsequent requests, the browser automatically includes that cookie.

The server reads the session ID, retrieves the corresponding session data, and determines the user’s identity.

The key idea is simple: the server stores the session state. The client only stores a reference to it.

In modern APIs and distributed systems, authentication is often stateless.

After a successful login, the server generates a signed token containing identity information. This token is returned to the client.

For every subsequent request, the client includes the token — commonly as a Bearer token in the Authorization header.

Instead of looking up session data in a server-side store, the server verifies the token’s signature and extracts the user identity directly from it.

The key distinction from session-based authentication is that the server does not maintain session state for each user. Identity verification happens by validating the token itself.

This model simplifies horizontal scaling because any server instance can validate the token without shared session storage.

A JWT is a structured string composed of three Base64-encoded sections separated by dots:

Header → metadata about the token and signing algorithm
Payload → claims (such as user ID or role)
Signature → cryptographic proof the token was not altered

When a server issues a JWT, it signs the token using a secret key or private key. When the token is later presented, the server verifies the signature to ensure the payload has not been modified.

Important clarification: JWTs are not encrypted by default. The payload can be decoded by anyone who has the token. The signature only guarantees integrity, not confidentiality.

JWTs are useful because they allow identity information to travel with the request in a verifiable way without requiring server-side session storage.

Once a user’s identity is confirmed, the system must decide what actions they are allowed to perform.

Authorization enforces access control rules. Even if a user is authenticated, they may not have permission to access certain resources or perform certain operations.

One common model is Role-Based Access Control (RBAC), where users are assigned roles such as “admin,” “editor,” or “viewer,” and each role has predefined permissions.

Another model is Attribute-Based Access Control (ABAC), where decisions are made based on attributes such as user properties, resource properties, or request context.

Authentication typically happens once per session or token issuance. Authorization, however, is evaluated for every protected request to ensure access rules are enforced consistently.

When a request arrives at the server, it does not immediately execute application logic. It first passes through an authentication layer, usually implemented as middleware in frameworks like Express, Django, or FastAPI.

This middleware checks for credentials such as a session cookie or authorization token. If the credentials are missing or invalid, the server rejects the request with a 401 Unauthorized response.

If identity is verified successfully, the system then evaluates permissions. When the user lacks access to the requested resource, the server returns 403 Forbidden.

Only after authentication and authorization checks pass does the request reach the handler and execute business logic, ensuring sensitive operations are protected from unauthorized access.

Even a correctly implemented authentication flow can be insecure if core protections are missing.

Passwords must be hashed before being stored in a database. Hashing ensures that even if the database is compromised, raw passwords are not exposed.

All authentication traffic must be transmitted over HTTPS. Without encryption in transit, credentials and tokens can be intercepted by attackers.

Access tokens should have expiration times. Short-lived tokens reduce the damage if a token is stolen. Many systems use refresh tokens to obtain new access tokens without requiring users to log in repeatedly.

Security is not just about verifying identity — it is about protecting the mechanisms that verify identity.