Authentication & Authorization

Authentication (AuthN) vs. Authorization (AuthZ)

These two concepts are fundamental to security but are often confused:

• Authentication (AuthN): The process of verifying who a user or client is. It answers the question: "Are you really who you claim to be?". Think of it like showing your ID card.
• Authorization (AuthZ): The process of determining what an authenticated user or client is allowed to do. It answers the question: "Now that I know who you are, are you permitted to access this resource or perform this action?". Think of it like checking if your ID card grants you access to a specific room.

Authentication always comes before Authorization. You can't determine permissions if you don't know who is making the request.

Common Authentication Mechanisms

1. Basic Authentication

The client sends a username and password, typically Base64 encoded, in the Authorization: Basic HTTP header with every request.

• Pros: Simple to implement, widely supported.
• Cons: Sends credentials with every request (must use HTTPS), no standard way to log out other than clearing browser cache/closing browser, vulnerable if not over HTTPS.

2. Session-Based Authentication (Cookies)

After successful login, the server creates a session, stores session data (like user ID) server-side, and sends a unique session ID back to the client stored in a cookie (e.g., Set-Cookie: sessionid=xyz...). The client automatically sends this cookie with subsequent requests. The server uses the session ID to look up the user's session data.

• Pros: Credentials aren't sent repeatedly, stateful nature makes logout easy (just destroy the server-side session), cookies handled automatically by browsers.
• Cons: Requires server-side storage for sessions (can be harder to scale horizontally), vulnerable to Cross-Site Request Forgery (CSRF) if not protected, less friendly for non-browser clients (like mobile apps).

3. Token-Based Authentication (e.g., JWT)

After successful login, the server generates a signed token (like a JSON Web Token - JWT) containing user information (claims) and sends it to the client. The client stores the token (e.g., in local storage) and sends it in the Authorization: Bearer header with subsequent requests. The server validates the token's signature and expiration, then trusts the claims inside.

• Pros: Stateless (server doesn't need to store session data, scales well), works well with microservices and non-browser clients, can embed user roles/permissions directly in the token (reducing database lookups).
• Cons: Tokens can be larger than session IDs, managing token expiration and revocation can be more complex, requires careful security implementation (e.g., using HTTPS, strong signing keys).

4. API Keys

A unique key (string) is generated for a client application (often for server-to-server or third-party integrations). The client includes the key in requests, often via a custom header (e.g., X-API-Key: abc...) or query parameter.

• Pros: Simple way to identify and track usage for specific applications or services.
• Cons: Primarily for identifying the *application*, not usually the *end-user*. Keys can be compromised if not handled securely. Limited authorization capabilities usually tied directly to the key itself.

Common Authorization Mechanisms

1. Role-Based Access Control (RBAC)

Access permissions are assigned to roles (e.g., "admin", "editor", "viewer"), and users are assigned one or more roles. Authorization involves checking if the user's role has the necessary permission for the requested resource or action.

• How it works: Define roles (Admin, User). Assign roles to users (Alice is Admin). Define permissions (Only Admin can access '/admin'). When Alice requests '/admin', check if her role ('Admin') has permission.
• Pros: Relatively simple to manage for many users and applications, follows the principle of least privilege easily.
• Cons: Can become complex with many roles or fine-grained permissions. Doesn't easily handle context-dependent rules (e.g., "user can edit *their own* profile").

(Other mechanisms like ABAC - Attribute-Based Access Control - exist, offering more fine-grained control based on user attributes, resource properties, and environmental context, but RBAC is common and easier to visualize.)