Authentication vs Authorization

Backend Fundamentals · Backend Security · 9 min read

1. What problem does this solve?

If authentication or authorization is omitted, the system behaves like an open public API: anyone can read/write any data. In production, that translates to data breaches, regulatory fines, and loss of user trust.

2. Mental model

Analogy

• Authentication = the key that proves you’re the right person to enter a building.
• Authorization = the guard at the door who checks whether you’re allowed to go to a specific room.

You can have the key (you’re authenticated), but the guard may still deny you access to the CEO’s office (you’re not authorized).

Engineering model

• Authentication: Issue a token (JWT, session ID, API key) that proves the user’s identity.
• Authorization: Attach claims or scopes to that token, or perform a policy lookup, to decide if the user can access a particular resource or perform an action.

3. Deep explanation

Internals

Important terminology

• Access token – short‑lived token used to call APIs.
• Refresh token – long‑lived token used to obtain new access tokens.
• Scope – a string that represents a permission.
• Role – a named collection of scopes.
• OPA (Open Policy Agent) – a policy engine that can be queried by services.

Trade‑offs

Failure modes

• Token leakage – stolen JWT can be used until expiration.
• Privilege escalation – missing scope checks or hard‑coded admin routes.
• Broken revocation – revoked tokens still accepted.
• Clock skew – iat/exp mis‑validated due to time differences.

Limitations

• JWT cannot be mutated – you cannot change scopes after issuance without re‑issuing.
• Opaque tokens require a store – adds latency and a single point of failure.
• Policy engines can become bottlenecks if not cached or distributed.

Where it fits

• API Gateway – validates tokens and forwards requests.
• Microservice – performs fine‑grained checks against a policy engine.
• Database – row‑level security (PostgreSQL RLS) can enforce authorization at the data layer.

Interaction with related concepts

• Rate limiting – often tied to the authenticated principal.
• Caching – store user permissions in Redis to avoid repeated DB lookups.
• Observability – log user_id, action, resource, and decision.

4. How it works

1. User logs in → credentials → auth server validates.
2. Auth server issues an access token (JWT) and a refresh token.
3. Client stores the access token (e.g., in memory or HTTP‑Only cookie).
4. Client calls API → attaches token in Authorization: Bearer.
5. API validates token signature, checks expiration, and extracts claims.
6. API (or policy engine) checks if the principal has the required scope/role.
7. Decision: allow or deny.
8. If denied, return 403 Forbidden or 401 Unauthorized.
9. If access token expires, client uses refresh token to obtain a new one.
10. Revocation: if a user is disabled, add the token ID to a revocation list; middleware checks it on each request.

sequenceDiagram
    participant Client
    participant AuthServer
    participant API
    Client->>AuthServer: POST /login {username, password}
    AuthServer-->>Client: 200 OK {access_token, refresh_token}
    Client->>API: GET /orders
    API->>AuthServer: Validate(access_token)
    AuthServer-->>API: 200 OK {claims}
    API->>API: CheckPermission(claims, "read:orders")
    API-->>Client: 200 OK {orders}

5. Practical implementation

Below is a minimal, runnable Express + TypeScript example that demonstrates:

• Password hashing with bcrypt.
• JWT issuance (jsonwebtoken).
• Role‑based authorization middleware.
• Redis‑backed revocation list.

// src/server.ts
import express, { Request, Response, NextFunction } from 'express';
import jwt from 'jsonwebtoken';
import bcrypt from 'bcrypt';
import { createClient } from 'redis';

const app = express();
app.use(express.json());

// ------------------------------------------------------------------
// Configuration – in production use env vars or a secrets manager
// ------------------------------------------------------------------
const JWT_SECRET = process.env.JWT_SECRET ?? 'super-secret';
const REFRESH_SECRET = process.env.REFRESH_SECRET ?? 'refresh-secret';
const JWT_EXPIRES_IN = '15m';
const REFRESH_EXPIRES_IN = '7d';
const REDIS_URL = process.env.REDIS_URL ?? 'redis://localhost:6379';

// ------------------------------------------------------------------
// Redis client – used for token revocation
// ------------------------------------------------------------------
const redis = createClient({ url: REDIS_URL });
redis.on('error', console.error);
await redis.connect();

// ------------------------------------------------------------------
// In‑memory user store (replace with DB in prod)
// ------------------------------------------------------------------
interface User {
  id: number;
  username: string;
  passwordHash: string;
  role: 'admin' | 'user';
}
const users: User[] = [
  {
    id: 1,
    username: 'alice',
    passwordHash: bcrypt.hashSync('password', 10),
    role: 'admin',
  },
  {
    id: 2,
    username: 'bob',
    passwordHash: bcrypt.hashSync('password', 10),
    role: 'user',
  },
];

// ------------------------------------------------------------------
// Helpers
// ------------------------------------------------------------------
function findUser(username: string): User | undefined {
  return users.find((u) => u.username === username);
}

function generateAccessToken(user: User) {
  const payload = { sub: user.id, role: user.role };
  return jwt.sign(payload, JWT_SECRET, { expiresIn: JWT_EXPIRES_IN });
}

function generateRefreshToken(user: User) {
  const payload = { sub: user.id };
  return jwt.sign(payload, REFRESH_SECRET, { expiresIn: REFRESH_EXPIRES_IN });
}

// ------------------------------------------------------------------
// Middleware – authentication
// ------------------------------------------------------------------
async function authMiddleware(req: Request, res: Response, next: NextFunction) {
  const authHeader = req.headers.authorization;
  if (!authHeader?.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'Missing token' });
  }
  const token = authHeader.split(' ')[1];

  // Check revocation list first
  const revoked = await redis.get(`revoked:${token}`);
  if (revoked) {
    return res.status(401).json({ error: 'Token revoked' });
  }

  try {
    const payload = jwt.verify(token, JWT_SECRET) as { sub: number; role: string };
    // Attach to request for downstream handlers
    (req as any).user = payload;
    next();
  } catch (err) {
    return res.status(401).json({ error: 'Invalid token' });
  }
}

// ------------------------------------------------------------------
// Middleware – authorization (role based)
// ------------------------------------------------------------------
function requireRole(role: string) {
  return (req: Request, res: Response, next: NextFunction) => {
    const user = (req as any).user;
    if (!user || user.role !== role) {
      return res.status(403).json({ error: 'Forbidden' });
    }
    next();
  };
}

// ------------------------------------------------------------------
// Routes
// ------------------------------------------------------------------
app.post('/login', async (req, res) => {
  const { username, password } = req.body;
  const user = findUser(username);
  if (!user || !(await bcrypt.compare(password, user.passwordHash))) {
    return res.status(401).json({ error: 'Invalid credentials' });
  }
  const accessToken = generateAccessToken(user);
  const refreshToken = generateRefreshToken(user);
  res.json({ accessToken, refreshToken });
});

app.post('/refresh', async (req, res) => {
  const { refreshToken } = req.body;
  try {
    const payload = jwt.verify(refreshToken, REFRESH_SECRET) as { sub: number };
    const user = users.find((u) => u.id === payload.sub);
    if (!user) throw new Error();
    const newAccess = generateAccessToken(user);
    res.json({ accessToken: newAccess });
  } catch {
    res.status(401).json({ error: 'Invalid refresh token' });
  }
});

app.post('/logout', authMiddleware, async (req, res) => {
  const authHeader = req.headers.authorization!;
  const token = authHeader.split(' ')[1];
  // Store token in revocation list for its remaining lifetime
  const decoded = jwt.decode(token) as { exp: number };
  const ttl = decoded.exp - Math.floor(Date.now() / 1000);
  await redis.set(`revoked:${token}`, '1', { EX: ttl });
  res.json({ message: 'Logged out' });
});

app.get('/orders', authMiddleware, (req, res) => {
  const user = (req as any).user;
  // Example: only admins can see all orders
  if (user.role === 'admin') {
    return res.json({ orders: ['order1', 'order2'] });
  }
  // Regular users see only their own orders
  res.json({ orders: ['order1'] });
});

app.get('/admin', authMiddleware, requireRole('admin'), (req, res) => {
  res.json({ secret: 'Top secret data' });
});

// ------------------------------------------------------------------
// Start server
// ------------------------------------------------------------------
const PORT = process.env.PORT ?? 3000;
app.listen(PORT, () => console.log(`🚀 Server listening on ${PORT}`));

Key lines explained

• jwt.sign(payload, JWT_SECRET, { expiresIn }) – creates a signed JWT.
• redis.set('revoked:${token}', '1', { EX: ttl }) – revokes a token until it would naturally expire.
• requireRole('admin') – simple role‑based guard.

Tip: In production, store JWT_SECRET and REFRESH_SECRET in a secrets manager, rotate them regularly, and use HTTPS to protect tokens in transit.

6. Production considerations

7. Common mistakes

8. Senior engineer perspective

What changes at scale?

• Distributed policy enforcement: Instead of embedding RBAC checks in each service, use a central policy engine (OPA, Keycloak) and query it via gRPC or HTTP.
• Token revocation strategy: Stateless JWTs are great for read‑heavy workloads, but for write‑heavy or highly regulated systems you may need opaque tokens or a short‑lived JWT with a revocation list.
• Key rotation: Automate key rollover with JWKs and support key ID (kid) in JWT headers.
• Observability: Instrument auth flows with distributed tracing (OpenTelemetry) to detect bottlenecks.
• Cost/performance: JWT verification is CPU‑bound; cache public keys, batch verification, or use hardware acceleration if needed.
• Bottlenecks: Policy engine can become a single point of failure; mitigate with caching and replication.
• Failure scenarios: If the auth server is down, services should fallback to a cached token or deny access gracefully.
• When NOT to use: For internal tooling with a single user, a simple API key may suffice; for microservices that only need mutual TLS, skip JWTs entirely.

9. Interview questions

10. Hands‑on task

Goal: Extend the example above to support role‑based access control for a new endpoint /reports.

1. Add a new role analyst to the user store.
2. Create a middleware requireAnyRole(['admin', 'analyst']).
3. Protect /reports so that only admins and analysts can access it.
4. Write a unit test that verifies a user with role user receives 403.
5. Deploy the updated service in Docker and verify the endpoint works.

11. Quick revision

• Auth = prove identity; Authz = decide permissions.
• JWTs are stateless; opaque tokens require a store.
• Use sub claim for user ID; role or scope for permissions.
• Revocation: Redis set with TTL, or short token lifetime + refresh token.
• Never store passwords in plain text; hash with bcrypt/scrypt/argon2.
• Validate token signature and expiration; check revocation list.
• Use HttpOnly & Secure flags for cookies; avoid localStorage.
• Rotate secrets regularly; support JWK kid.
• Central policy engine (OPA, Keycloak) scales better than per‑service checks.
• Log auth decisions; expose metrics (auth_success, auth_fail).
• For high‑traffic APIs, cache policy decisions and public keys.

12. References

• RFC 7519 – JSON Web Token (JWT)
• OAuth 2.0 Authorization Framework
• OpenID Connect Core 1.0
• Node.js jsonwebtoken documentation
• OWASP Authentication Cheat Sheet
• Open Policy Agent (OPA) docs
• PostgreSQL Row‑Level Security
• Redis Revocation List Pattern