Authentication Basics

Authentication & Authorization: The Gatekeepers

In system architecture, Authentication and Authorization are the two fundamental pillars of identity management. They dictate who can enter your system and exactly what they are allowed to do once they are inside.

1. Authentication vs. Authorization

While they sound similar, these two processes serve distinct roles in the security chain:

• Authentication (AuthN): The process of verifying who a user is. It involves identifying a user against a database of credentials (like checking a username/password or a biometric signature).

• Authorization (AuthZ): The process of verifying what an authenticated user is permitted to do. It determines if a user has the correct roles or permissions to access specific resources (e.g., can a "Standard User" delete a "System Node"?).

2. Session-Based Authentication

Session-Based Authentication is a traditional stateful approach where the server creates and stores a session record after a successful login.

The Operational Pipeline

1. Login: The client sends credentials (POST /login). The server verifies them.

2. Session Creation: The server creates a unique Session ID (a random, high-entropy string), saves this ID in a centralized store (like Redis or a database), and maps it to the user's metadata.

3. Cookie Handshake: The server sends the Session ID back to the client in an Set-Cookie header. The browser automatically stores this cookie and attaches it to every subsequent request automatically.

4. Validation: For every incoming request, the server fetches the Session ID from the cookie, queries its internal storage to verify that the session is valid, and retrieves the associated user identity.

• Pros: Highly secure; sessions can be instantly invalidated/revoked by the server (e.g., logging out a user remotely).

• Cons: Statefulness limits horizontal scalability. You must ensure all servers share a centralized, high-speed session store (like Redis), as the server needs to "remember" the user.

3. Token-Based Authentication

Token-Based Authentication is a stateless approach where the server issues a cryptographically signed token (like a JWT - JSON Web Token) to the client.

The Operational Pipeline

1. Login: The client sends credentials. The server verifies them.

2. Token Issuance: The server generates a JWT containing user claims (e.g., user_id, role: admin, exp: expiration_time). It signs this token with a Secret Key that only the server knows.

3. Stateless Transmission: The server returns the token to the client. The client stores it (usually in local storage or an HttpOnly cookie) and manually attaches it to the Authorization header of every request (e.g., Authorization: Bearer <token>).

4. Validation: When the request hits the server, it doesn't query a database. It simply performs a mathematical check: Does this token's cryptographic signature match my known secret key? If yes, the server trusts the data inside the token implicitly.

• Pros: Highly scalable. Since the server doesn't need to query a database to verify the user, you can scale your application nodes infinitely without centralized session storage.

• Cons: Harder to revoke. Once a token is issued, it is valid until its expiration time. If you need to force-logout a user before expiration, you have to implement a complex token-blacklist strategy.

Authentication Paradigms Reference Matrix