Authentication & Authorization
Learn the difference between authentication and authorization and how they protect access in modern applications.
Authentication vs Authorization
Authentication verifies identity. Authorization determines permissions. They solve different problems and happen in sequence.
identity verified through credentials
identity verified → permissions checked
- Authentication (AuthN) answers: “Who are you?”
- Authorization (AuthZ) answers: “What are you allowed to do?”
- You can be authenticated but still blocked by authorization.
Details
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 — How Identity Is Verified
Authentication confirms that a claimed identity is backed by valid credentials.
password credential
hashed password
server verification
- Credentials can be passwords, OAuth logins, API keys, or multi-factor proofs.
- The server validates those credentials against stored data or a trusted provider.
- If verification fails, the request is rejected before any resource access.
Details
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.
Session-Based Authentication
Session Store
Session creation: login goes to server, session is saved, then cookie is sent to browser.
- After login, the server creates a session tied to the authenticated user.
- A session ID is stored in the client’s cookie.
- The server keeps session state and looks it up on every request.
Details
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.
Token-Based Authentication
| Step | Action |
|---|---|
| 1 | Login → server issues signed JWT |
| 2 | Client sends token with request |
| 3 | Server verifies token signature |
| 4 | Request processed (no session lookup) |
- After verifying credentials, the server issues a token (such as a JWT).
- The client sends the token with each request, usually in the Authorization header.
- The server validates the token without storing per-user session state.
Details
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.
What Is a JWT?
- A JWT contains three parts: Header, Payload, and Signature.
- The signature ensures the token has not been tampered with.
- A JWT is signed by default, not encrypted.
Details
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.
Authorization — Enforcing Permissions
- Authorization checks permissions after identity is verified.
- RBAC assigns permissions based on roles.
- Authorization is evaluated on every protected request.
Details
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.
Where Auth Happens in the Request Flow
- The request reaches the server and passes through authentication middleware.
- If credentials are invalid, the server returns 401 Unauthorized.
- If identity is valid but permissions are insufficient, the server returns 403 Forbidden.
Details
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.
Security Considerations
- Passwords must be hashed before storage — never stored in plain text.
- Authentication traffic must use HTTPS to prevent interception.
- Tokens should expire and may use refresh tokens for renewal.
Details
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.
Question Section
1 / 5