Authentication & Authorization 🔒🔑

In any distributed system, the first line of defense is ensuring that users are who they say they are (Authentication) and that they can only do what they are permitted to do (Authorization).

🆚 Authentication vs. Authorization

While often used interchangeably, these two concepts serve very different purposes.

• Authentication (AuthN): The process of verifying the identity of a user or system (e.g., "Who are you?"). Consists of credentials like passwords, biometrics, or tokens.
• Authorization (AuthZ): The process of verifying what an authenticated user has permission to do (e.g., "What can you do?").

[!TIP] Authentication confirms the identity (ID card). Authorization defines the access levels (Does this ID card open the Server Room door?).

🛠️ Common Authentication Methods

Modern systems use a variety of protocols based on the required security level and integration needs.

1. Basic Authentication: Simple username and password sent via HTTP headers (Base64 encoded). Should never be used without HTTPS/TLS.
2. OAuth 2.0: A delegated access protocol that allows third-party services to access user data without exposing the user's credentials.
3. OpenID Connect (OIDC): An identity layer built on top of OAuth 2.0 specifically for authentication (often used for SSO).
4. JWT (JSON Web Tokens): A compact, URL-safe means of representing claims to be transferred between two parties. Commonly used in stateless APIs.

🔄 Session-based vs. Token-based Auth

Choosing between sessions and tokens is a fundamental architectural decision.

1. Session-based (Stateful)

The server stores user session data in memory or a database. The client receives a Session ID via a cookie.

• Pros: Easy to implement, easy to revoke sessions immediately.
• Cons: Difficult to scale (requires sticky sessions or a shared Redis session store).

2. Token-based (Stateless)

The server issues a signed token (like a JWT) to the client. The server does not store the token; it validates the signature on every request.

• Pros: Highly scalable (zero server state), works across multiple domains (CORS friendly).
• Cons: Harder to revoke tokens before they expire (requires a blacklist or short TTL).

📑 Access Control Models

Once a user is authenticated, we must decide how to manage their permissions.

• RBAC (Role-Based Access Control): Permissions are assigned to roles (e.g., Admin, Manager, User). Users are then assigned to those roles.
  • Best for: Simple organizations with clear job functions.
• ABAC (Attribute-Based Access Control): Permissions are granted based on attributes (e.g., "User can edit if Department=HR and Location=UK and Time=WorkingHours").
  • Best for: Complex, fine-grained requirements.
• DAC (Discretionary Access Control): The owner of a resource decides who gets access (common in local filesystems).
• MAC (Mandatory Access Control): Access is decided by a central authority based on security levels (common in military/government systems).

🤝 SSO & Identity Federation

Single Sign-On (SSO)

A process that allows a user to log in once and access multiple independent software systems without being prompted for credentials again.

• Benefit: Massive reduction in password fatigue and higher security (centralized audit/MFA).

Identity Federation

Linking a person's electronic identity across multiple identity management systems. It allows users to use their existing credentials (from Google, Facebook, GitHub) to log into your service.

• Protocols: SAML 2.0 (XML-based, enterprise) and OIDC (JSON-based, modern web).

💡 Best Practices

• Never storage passwords in plain text: Always use a slow hashing algorithm like Argon2 or BCrypt.
• Use HTTPS everywhere: Tokens and session IDs are useless if they can be sniffed over the wire.
• Implement MFA: Even a strong password can be phished.
• Rotate keys: Signing keys for JWTs should be rotated periodically.

Interview Questions - Authentication & Authorization 💡

1. Why is JWT commonly used for stateless authentication in distributed systems?

Answer:

• Self-contained: Contains all claims (identity, roles, expiry) within the token itself, removing the need for server-side session storage.
• Stateless Scalability: Can be validated without querying a central store, ideal for microservices.
• Standardized: Compact, URL-safe, and widely supported across platforms.
• Security: Can be signed (HMAC/RSA) to ensure authenticity and integrity.
• Caveat: Revocation is non-trivial without a blacklist, and they must be stored securely (HttpOnly cookies) to prevent theft.

2. How does OAuth2 differ from OpenID Connect?

Answer:

• OAuth2: An authorization framework for delegating access (e.g., "Allow this app to post on my Twitter"). Provides an Access Token.
• OpenID Connect (OIDC): An authentication layer on top of OAuth2. It introduces the ID Token (JWT) to verify the user's identity and basic profile info.

3. Explain the difference between RBAC and ABAC. Which is more suitable for dynamic environments?

Answer:

• RBAC (Role-Based): Access is tied to roles (Admin, Editor). Simple to manage but rigid.
• ABAC (Attribute-Based): Access is based on fine-grained attributes (User, Resource, Environment—e.g., "HR only, during work hours").
• Suitability: ABAC is far more suitable for highly dynamic or complex environments like multi-tenant cloud platforms.

4. What are the advantages of using Single Sign-On (SSO) in a system?

Answer:

• UX: Log in once, access everything.
• Security: Centralized policy enforcement (MFA, rotation) and reduced "credential fatigue."
• Efficiency: Fewer password-reset tickets and easier compliance auditing.

5. What are some potential security concerns with token-based authentication?

Answer:

• Theft & Replay: Tokens can be stolen via XSS if stored in localStorage.
• Revocation: Hard to invalidate before they expire.
• Forgery: Misconfigured algorithms (e.g., none) can allow token tampering.
• Mitigation: Use HttpOnly cookies, short-lived tokens with refresh tokens, and strict signature validation.

Next up? Deep dive into Security — Security Foundations