🔐 Authentication and Authorization

Beginner

Foundation concept — required reading for every system.
Authentication (AuthN) answers "Who are you?" and Authorization (AuthZ) answers "What can you do?". They are two separate concerns that must be implemented together — and getting either one wrong compromises the entire system.

1. The Core Difference — AuthN vs AuthZ

These two terms are often confused but represent distinct responsibilities.

Aspect	Authentication (AuthN)	Authorization (AuthZ)
Question	Who are you?	What are you allowed to do?
Verifies	Identity (user, service, device)	Permissions (roles, scopes, policies)
Happens	First (before anything else)	After successful auth
Common methods	Passwords, tokens, biometrics, OAuth, SAML	RBAC, ABAC, ACLs, scopes, resource ownership
Failure returns	`401 Unauthorized`	`403 Forbidden`
Example	Login with email + password returns JWT	Admin role can `DELETE /users/:id`

TIP

The status codes matter — 401 means "I don't know who you are" and 403 means "I know who you are but you can't do that." Returning the wrong one leaks information.

2. Where They Sit in the System

Authentication and authorization are typically enforced at the edge (API Gateway / Load Balancer) and re-checked at the service level.

Why enforce at both layers?

Layer	What it checks	Why
Edge / Gateway	Token signature, expiry, basic role	Reject invalid traffic before it hits your services
Service	Resource ownership, fine-grained permissions	Defense in depth — never trust the gateway blindly
Database	Row-level security (optional)	Last line of defense for highly sensitive data

WARNING

Never trust only the gateway. Any service that has access to internal data should re-verify the caller's identity and permissions. A compromised internal service should still be unable to read another tenant's data.

3. Authentication Strategies

Decision Matrix

Strategy	Best for	Pros	Cons
Session + Cookie	Server-rendered web apps	Simple, revocable	Stateful, CSRF risk
JWT (stateless)	SPAs, mobile, microservices	Scalable, no shared state	Hard to revoke, larger tokens
OAuth 2.0 / OIDC	Third-party login, federated identity	No password storage	Complex setup
API Key	Server-to-server, machine identity	Simple, easy to rotate	No user context, leak risk
SAML	Enterprise SSO	Mature, enterprise-grade	XML-heavy, complex
mTLS	Service-to-service in zero-trust networks	Strongest crypto identity	PKI overhead

4. Authorization Models

4.1 RBAC — Role-Based Access Control

Roles are assigned to users; permissions are assigned to roles. Simple, easy to reason about.

javascript

// RBAC middleware — Node.js
function authorize(...allowedRoles) {
  return (req, res, next) => {
    if (!req.user) {
      return res.status(401).json({ error: "Authentication required" });
    }
    if (!allowedRoles.includes(req.user.role)) {
      return res.status(403).json({ error: "Insufficient role" });
    }
    next();
  };
}

// Usage
app.delete("/users/:id", authenticate, authorize("admin"), deleteUser);
app.post("/posts", authenticate, authorize("admin", "editor"), createPost);
app.get(
  "/posts",
  authenticate,
  authorize("admin", "editor", "viewer"),
  listPosts
);

4.2 ABAC — Attribute-Based Access Control

Policies are evaluated against attributes of the user, resource, and environment. More flexible, more complex.

javascript

// ABAC example — policy-as-code
const policies = {
  canEditPost: (user, post, context) => {
    return (
      user.id === post.authorId || // author can edit own
      user.role === "admin" || // admin can edit any
      (user.role === "editor" && context.timeSincePublish < 60 * 60) // editors within 1h
    );
  },
};

function checkPolicy(policyName, user, resource, context = {}) {
  const policy = policies[policyName];
  if (!policy) throw new Error(`Unknown policy: ${policyName}`);
  return policy(user, resource, context);
}

4.3 ACL and Resource Ownership

For per-resource checks (e.g., "can this user delete this specific post"), the service must own the authorization decision.

Choosing the Right Model

Model	When to use
RBAC	Small/medium apps, clear role hierarchy, most common
ABAC	Complex rules (time, location, ownership), enterprise systems
ACL	Per-resource permissions, multi-tenant apps
PBAC	Regulated industries (HIPAA, finance) requiring audit trails

5. Token-Based Authentication with JWT

JWT (JSON Web Token) is the de-facto standard for stateless authentication in modern web and mobile apps.

5.1 Anatomy of a JWT

A JWT has three base64-encoded parts separated by dots:

text

┌──────────────────────────────────────────────────────────────┐
│  HEADER.PAYLOAD.SIGNATURE                                    │
│  eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoxMjN9.abc123sig             │
└──────────────────────────────────────────────────────────────┘

javascript

// Header
{
  "alg": "HS256",   // signing algorithm
  "typ": "JWT"
}

// Payload (claims — public, not encrypted!)
{
  "sub": "user_123",        // subject (user id)
  "email": "[email protected]",
  "role": "admin",
  "iat": 1700000000,        // issued at
  "exp": 1700000900,        // expires in 15min
  "iss": "api.example.com", // issuer
  "aud": "web-app"          // audience
}

WARNING

The JWT payload is signed, not encrypted. Anyone with the token can decode it. Never put passwords, secrets, or PII in the payload. Use JWE if you need encryption.

5.2 Complete JWT Implementation

javascript

// utils/jwt.js
const jwt = require("jsonwebtoken");
const crypto = require("crypto");

const ACCESS_SECRET = process.env.JWT_ACCESS_SECRET; // 256-bit random
const REFRESH_SECRET = process.env.JWT_REFRESH_SECRET; // different 256-bit

// Generate access token (short-lived, 15 min)
function generateAccessToken(user) {
  return jwt.sign(
    { sub: user.id, role: user.role, email: user.email },
    ACCESS_SECRET,
    {
      expiresIn: "15m",
      issuer: "api.example.com",
      audience: "web-app",
      algorithm: "HS256",
    }
  );
}

// Generate refresh token (long-lived, 7 days)
function generateRefreshToken(userId) {
  return jwt.sign({ sub: userId, type: "refresh" }, REFRESH_SECRET, {
    expiresIn: "7d",
    issuer: "api.example.com",
  });
}

// Verify token — always catch and inspect errors
function verifyAccessToken(token) {
  return jwt.verify(token, ACCESS_SECRET, {
    issuer: "api.example.com",
    audience: "web-app",
    algorithms: ["HS256"], // explicit — prevent alg confusion attacks
  });
}

javascript

// middleware/auth.js
const { verifyAccessToken } = require("../utils/jwt");

async function authenticate(req, res, next) {
  try {
    const header = req.headers.authorization;
    if (!header?.startsWith("Bearer ")) {
      return res.status(401).json({ error: "Missing token" });
    }

    const token = header.slice(7);
    const decoded = verifyAccessToken(token);

    // Optional: re-check user still exists / is active
    // const user = await db.users.findById(decoded.sub);
    // if (!user || user.banned) return res.status(401).json({ error: "Invalid" });

    req.user = { id: decoded.sub, role: decoded.role, email: decoded.email };
    next();
  } catch (err) {
    if (err.name === "TokenExpiredError") {
      return res
        .status(401)
        .json({ error: "Token expired", code: "TOKEN_EXPIRED" });
    }
    return res.status(401).json({ error: "Invalid token" });
  }
}

5.3 Refresh Token Flow

javascript

// Refresh token endpoint
app.post("/auth/refresh", async (req, res) => {
  const refreshToken = req.cookies.refreshToken;
  if (!refreshToken) return res.status(401).json({ error: "No refresh token" });

  try {
    const decoded = jwt.verify(refreshToken, REFRESH_SECRET);
    const stored = await db.refreshTokens.findOne({
      token: hash(refreshToken),
      userId: decoded.sub,
      revoked: false,
      expiresAt: { $gt: new Date() },
    });

    if (!stored)
      return res.status(401).json({ error: "Invalid refresh token" });

    // Rotate: issue new refresh token, revoke old one
    const newRefresh = generateRefreshToken(decoded.sub);
    await db.refreshTokens.update(
      { id: stored.id },
      { revoked: true, replacedBy: hash(newRefresh) }
    );
    await db.refreshTokens.insert({
      userId: decoded.sub,
      token: hash(newRefresh),
      expiresAt: new Date(Date.now() + 7 * 24 * 60 * 60 * 1000),
    });

    const accessToken = generateAccessToken({
      id: decoded.sub,
      role: stored.role,
    });
    res.cookie("refreshToken", newRefresh, {
      httpOnly: true,
      secure: true, // HTTPS only
      sameSite: "strict",
      maxAge: 7 * 24 * 60 * 60 * 1000,
    });
    res.json({ accessToken });
  } catch {
    res.status(401).json({ error: "Invalid refresh token" });
  }
});

5.4 Where to Store the Token

Storage	XSS safe?	CSRF safe?	Best for
`localStorage`	❌	✅	None — avoid for tokens
`sessionStorage`	❌	✅	None — avoid for tokens
httpOnly cookie	✅	⚠️ need CSRF token	Recommended for web apps
Memory (JS var)	✅	✅	SPAs with refresh-token flow

6. Session-Based Authentication

The classic approach: server stores session state, client gets an opaque session ID via cookie.

When to choose sessions over JWT

Server-rendered web apps (e.g., Django, Rails, Express + EJS)
You need immediate revocation (logout, ban, password change)
Simpler to debug (no token decoding)
Compliance requires audit trail of active sessions

Redis Session Implementation

javascript

const session = require("express-session");
const RedisStore = require("connect-redis").default;
const { createClient } = require("redis");

const redisClient = createClient({ url: process.env.REDIS_URL });
await redisClient.connect();

app.use(
  session({
    store: new RedisStore({ client: redisClient }),
    secret: process.env.SESSION_SECRET,
    resave: false,
    saveUninitialized: false,
    cookie: {
      httpOnly: true,
      secure: process.env.NODE_ENV === "production",
      sameSite: "strict",
      maxAge: 1000 * 60 * 60 * 24, // 24 hours
    },
  })
);

7. OAuth 2.0 and OpenID Connect

OAuth 2.0 is an authorization framework for delegated access. OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0.

7.1 OAuth 2.0 Roles

7.2 OAuth 2.0 Grant Flows

Grant	Use Case	When to Pick
Authorization Code + PKCE	Web apps, mobile apps, SPAs	Default for all modern apps
Client Credentials	Server-to-server, no user	Microservices, cron jobs, background workers
Device Code	Smart TVs, IoT, CLI tools	Devices without a browser
Refresh Token	Get new access token silently	Always paired with short-lived access tokens

7.3 Authorization Code Flow with PKCE

7.4 OAuth vs OIDC — What's the Difference?

Aspect	OAuth 2.0	OpenID Connect
Purpose	Authorization (scopes)	Authentication (identity)
Token	Access token	ID token (JWT with user info)
Endpoint	`/authorize`, `/token`	`/userinfo` (adds identity)
Use when	"Let me act on behalf of the user"	"Let me know who the user is"

TIP

Almost always use OIDC when you want "Sign in with Google/GitHub." Use plain OAuth 2.0 only when you need delegated access without identity (e.g., a third-party app posting to your user's Twitter).

8. Password Storage and Hashing

8.1 The Wrong Ways (and Why)

javascript

// ❌ NEVER do any of these
const plain = "mypassword123";
const md5 = crypto.createHash("md5").update(plain).digest("hex");
const sha1 = crypto.createHash("sha1").update(plain).digest("hex");
const sha256 = crypto.createHash("sha256").update(plain).digest("hex");
const encrypted = encryptAES(plain, key); // reversible — no!

8.2 The Right Way — bcrypt / Argon2id

javascript

const bcrypt = require("bcrypt");

// Hashing on signup (cost factor 12 — ~250ms per hash)
async function hashPassword(plaintext) {
  const salt = await bcrypt.genSalt(12);
  return bcrypt.hash(plaintext, salt);
}

// Verification on login
async function verifyPassword(plaintext, hash) {
  return bcrypt.compare(plaintext, hash);
}

// Alternative: Argon2id (winner of PHC, OWASP recommended)
const argon2 = require("argon2");

async function hashPasswordArgon2(plaintext) {
  return argon2.hash(plaintext, {
    type: argon2.argon2id,
    memoryCost: 65536, // 64 MB
    timeCost: 3,
    parallelism: 4,
  });
}

8.3 Password Policy — Show, Don't Just Tell

text

┌──────────────────────────────────────────────────────────────┐
│  Password Requirements                                       │
│  ─────────────────────────────────────────────────────────   │
│  ✓ At least 12 characters                                   │
│  ✓ Must contain uppercase, lowercase, number, symbol         │
│  ✓ Cannot contain your email or username                     │
│  ✓ Cannot be one of the top 10,000 common passwords          │
│  ✓ Cannot be reused (last 5 passwords)                       │
└──────────────────────────────────────────────────────────────┘

Algorithm	Recommended?	Why
Argon2id	✅ Best	Memory-hard, PHC winner, GPU-resistant
bcrypt	✅ Good	Battle-tested, widely available
scrypt	✅ Good	Memory-hard, but less widely supported
PBKDF2	⚠️ Acceptable	Only when Argon2/bcrypt not available; high iterations
MD5 / SHA-1 / SHA-256	❌ NEVER	Trivially fast, GPU-cracked

9. Multi-Factor Authentication (MFA)

Defense in depth: require two or more of something you know, have, or are.

MFA Flow — TOTP (Time-Based One-Time Password)

javascript

// TOTP — using otplib
const { authenticator } = require("otplib");

authenticator.options = { window: 1, step: 30 }; // 30s steps, ±1 window tolerance

// On MFA enrollment
function generateSecret(userEmail) {
  const secret = authenticator.generateSecret();
  const otpauth = authenticator.keyuri(userEmail, "YourApp", secret);
  return { secret, otpauth }; // User scans otpauth as QR code
}

// On MFA verification
function verifyToken(token, secret) {
  return authenticator.verify({ token, secret });
}

MFA Methods Compared

Method	Security	UX	Cost
Hardware key (FIDO2/WebAuthn)	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	$$ (keys)
TOTP (Authenticator app)	⭐⭐⭐⭐	⭐⭐⭐⭐	Free
SMS code	⭐⭐	⭐⭐⭐	$ (per SMS)
Email code	⭐	⭐⭐	Free
Push notification	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	$$ (provider)

WARNING

SMS is vulnerable to SIM-swap attacks — only use it as a last resort. Prefer TOTP or hardware keys for high-value accounts.

10. Common Vulnerabilities and Defenses

10.1 Attack Surface Map

10.2 Defense Patterns

javascript

// 1. Rate limiting on auth endpoints
const rateLimit = require("express-rate-limit");
const authLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 5, // 5 attempts per 15 min per IP
  message: { error: "Too many attempts. Try again later." },
  standardHeaders: true,
  legacyHeaders: false,
});
app.post("/login", authLimiter, loginHandler);
app.post("/register", authLimiter, registerHandler);

// 2. Account lockout after failed attempts
async function trackFailedLogin(userId) {
  const user = await db.users.findById(userId);
  user.failedAttempts = (user.failedAttempts || 0) + 1;
  if (user.failedAttempts >= 5) {
    user.lockedUntil = new Date(Date.now() + 15 * 60 * 1000); // 15 min
  }
  await user.save();
}

// 3. Never log tokens or passwords
logger.info("Login attempt", { userId, email }); // ✅
logger.info("Login attempt", { password }); // ❌ NEVER
logger.info("Login attempt", { token }); // ❌ NEVER

// 4. JWT algorithm confusion prevention
jwt.verify(token, SECRET, { algorithms: ["HS256"] }); // ✅ explicit

// 5. CSRF protection for cookie-based sessions
const csrf = require("csurf");
app.use(csrf({ cookie: true }));
// Send token in meta tag, send in header on every mutation

10.3 Security Headers

javascript

const helmet = require("helmet");
app.use(
  helmet({
    contentSecurityPolicy: {
      directives: {
        defaultSrc: ["'self'"],
        scriptSrc: ["'self'"],
        objectSrc: ["'none'"],
        frameAncestors: ["'none'"],
      },
    },
    hsts: { maxAge: 31536000, includeSubDomains: true, preload: true },
  })
);

11. Best Practices Checklist

✅ Authentication

[ ] Use HTTPS everywhere — never send credentials over plain HTTP
[ ] Hash passwords with Argon2id or bcrypt (cost ≥ 12)
[ ] Enforce strong password policy + check against known breached passwords
[ ] Implement rate limiting on login/register/reset endpoints
[ ] Lock account after N failed attempts (exponential backoff)
[ ] Use short-lived access tokens (15 min) + long-lived refresh tokens (7 days)
[ ] Store refresh tokens in httpOnly + Secure + SameSite=Strict cookies
[ ] Rotate refresh tokens on every use
[ ] Implement MFA for high-value accounts
[ ] Log all auth events (success, failure, lockout) — never log secrets
[ ] Implement PKCE for all OAuth 2.0 flows
[ ] Explicitly list algorithms in jwt.verify() to prevent alg attacks

✅ Authorization

[ ] Never trust client-side authorization checks
[ ] Re-verify permissions at the service layer, not just the gateway
[ ] Use least privilege — default to deny
[ ] Prefer RBAC for clarity; reach for ABAC only when you need fine-grained rules
[ ] Implement resource ownership checks for per-user data
[ ] Use scopes in OAuth tokens to limit delegated access
[ ] Return 403 (not 404) when the user exists but lacks permission — but only if no info leak is possible
[ ] Audit sensitive operations (who accessed what, when)

✅ Operational

[ ] Store secrets in a secret manager (AWS Secrets Manager, Vault) — never in code
[ ] Rotate JWT signing keys periodically
[ ] Have a token revocation strategy (blacklist or short TTL)
[ ] Monitor for anomalous patterns (login from new geo, impossible travel)
[ ] Run penetration tests and dependency audits regularly
[ ] Document your incident response plan for credential leaks

This page sits at the foundation of the security stack. To go deeper, follow these threads:

Topic	Where to go next
HTTPS / TLS	Networking — Level 1
Rate Limiting	Scalability — Level 2
API Gateway	Microservices — Level 6
Distributed session store	Caching — Level 4
Security in interviews	Security Interview — Level 12
Design patterns (Strategy, Decorator)	Design Patterns — Level 1

🧠 One-Page Recap

text

┌─────────────────────────────────────────────────────────────────────┐
│  AUTHENTICATION                │  AUTHORIZATION                     │
│  ─────────────                 │  ─────────────                     │
│  • Who are you?                │  • What can you do?                │
│  • 401 if unknown              │  • 403 if forbidden                │
│  • JWT / Session / OAuth       │  • RBAC / ABAC / ownership         │
│  • Verify before anything else │  • Check at gateway AND service    │
├─────────────────────────────────────────────────────────────────────┤
│  STORAGE    → bcrypt/Argon2    │  CHECKS  → server-side, not client │
│  TRANSPORT  → HTTPS only       │  TOKENS  → short-lived access +    │
│  COOKIES    → httpOnly/Secure  │           refresh rotation         │
│  MFA        → TOTP or WebAuthn │  LEAST    → privilege, default deny│
└─────────────────────────────────────────────────────────────────────┘

INFO

Next step: Continue to Security — Interview Prep to see how these concepts are tested in FAANG interviews, or jump to Microservices — Level 6 to see how authentication is enforced across service boundaries.

🔐 Authentication and Authorization ​

📋 Table of Contents ​

1. The Core Difference — AuthN vs AuthZ ​

2. Where They Sit in the System ​

Why enforce at both layers? ​

3. Authentication Strategies ​

Decision Matrix ​

4. Authorization Models ​

4.1 RBAC — Role-Based Access Control ​

4.2 ABAC — Attribute-Based Access Control ​

4.3 ACL and Resource Ownership ​

Choosing the Right Model ​

5. Token-Based Authentication with JWT ​

5.1 Anatomy of a JWT ​

5.2 Complete JWT Implementation ​

5.3 Refresh Token Flow ​

5.4 Where to Store the Token ​

6. Session-Based Authentication ​

When to choose sessions over JWT ​

Redis Session Implementation ​

7. OAuth 2.0 and OpenID Connect ​

7.1 OAuth 2.0 Roles ​

7.2 OAuth 2.0 Grant Flows ​

7.3 Authorization Code Flow with PKCE ​

7.4 OAuth vs OIDC — What's the Difference? ​

8. Password Storage and Hashing ​

8.1 The Wrong Ways (and Why) ​

8.2 The Right Way — bcrypt / Argon2id ​

8.3 Password Policy — Show, Don't Just Tell ​

9. Multi-Factor Authentication (MFA) ​

MFA Flow — TOTP (Time-Based One-Time Password) ​

MFA Methods Compared ​

10. Common Vulnerabilities and Defenses ​

10.1 Attack Surface Map ​

10.2 Defense Patterns ​

10.3 Security Headers ​

11. Best Practices Checklist ​

✅ Authentication ​

✅ Authorization ​

✅ Operational ​

12. Related Topics ​

🧠 One-Page Recap ​

🔐 Authentication and Authorization

📋 Table of Contents

1. The Core Difference — AuthN vs AuthZ

2. Where They Sit in the System

Why enforce at both layers?

3. Authentication Strategies

Decision Matrix

4. Authorization Models

4.1 RBAC — Role-Based Access Control

4.2 ABAC — Attribute-Based Access Control

4.3 ACL and Resource Ownership

Choosing the Right Model

5. Token-Based Authentication with JWT

5.1 Anatomy of a JWT

5.2 Complete JWT Implementation

5.3 Refresh Token Flow

5.4 Where to Store the Token

6. Session-Based Authentication

When to choose sessions over JWT

Redis Session Implementation

7. OAuth 2.0 and OpenID Connect

7.1 OAuth 2.0 Roles

7.2 OAuth 2.0 Grant Flows

7.3 Authorization Code Flow with PKCE

7.4 OAuth vs OIDC — What's the Difference?

8. Password Storage and Hashing

8.1 The Wrong Ways (and Why)

8.2 The Right Way — bcrypt / Argon2id

8.3 Password Policy — Show, Don't Just Tell

9. Multi-Factor Authentication (MFA)

MFA Flow — TOTP (Time-Based One-Time Password)

MFA Methods Compared

10. Common Vulnerabilities and Defenses

10.1 Attack Surface Map

10.2 Defense Patterns

10.3 Security Headers

11. Best Practices Checklist

✅ Authentication

✅ Authorization

✅ Operational

12. Related Topics

🧠 One-Page Recap