Authentication vs Authorization: The Core Security Primitives

In distributed systems security, Authentication (AuthN) and Authorization (AuthZ) form the two foundational pillars of access control. Confusing them or coupling their implementations is one of the most common causes of architectural security flaws.

Authentication (AuthN) — "Who are you?"

Authentication is the process of verifying that an entity (a human user, a microservice, a background worker, or an IoT device) is genuinely who they declare themselves to be.

• Input: Proof of identity (passwords, MFA one-time codes, FIDO2/WebAuthn hardware tokens, X.509 client certificates, biometric hashes).
• Mechanism: The system verifies the proof against a trusted Identity Provider (IdP) or user directory.
• Output: An authenticated security context—typically a cryptographic identity token (e.g., OIDC ID token, signed JWT) or a session identifier containing the subject identifier (sub: "usr_98124").
• Failure Status: HTTP 401 Unauthorized (the standard RFC name is historically a misnomer; it strictly means Unauthenticated or Authentication Required). The response must include a WWW-Authenticate challenge header.

Authorization (AuthZ) — "What are you allowed to do?"

Authorization is the process of determining whether an already-authenticated subject is permitted to execute a specific operation (e.g., READ, WRITE, DELETE, EXECUTE) on a targeted resource (e.g., document_id: "doc_552", tenant_id: "tenant_99") under specific environmental conditions (e.g., IP subnet, time of day, device trust level).

• Input: Authenticated subject attributes, resource identifier, requested action, and contextual environment data.
• Mechanism: Evaluation of security policies via models like RBAC (Role-Based Access Control), ABAC (Attribute-Based Access Control), or ReBAC (Relationship-Based Access Control).
• Output: A deterministic decision: ALLOW or DENY.
• Failure Status: HTTP 403 Forbidden (the server understands who you are, but you lack the necessary permissions to perform this operation). Unlike 401, re-authenticating with the same credentials will not change the outcome.

In enterprise distributed architectures, authorization is decoupled from application business logic using the XACML (eXtensible Access Control Markup Language) conceptual model:

1. PEP (Policy Enforcement Point):

   • Located directly in the request path (e.g., API Gateway, service mesh Envoy sidecar, or application middleware).
   • Intercepts incoming requests, extracts the authenticated identity context, and pauses execution.
   • Forwards a query to the PDP: "Is subject alice allowed to perform PUT /api/v1/invoices/992?"
   • Strictly enforces the PDP's decision (ALLOW → proceed; DENY → return HTTP 403).

2. PDP (Policy Decision Point):

   • The centralized or local decision engine (e.g., Open Policy Agent (OPA), AWS IAM engine, Google Zanzibar service).
   • Evaluates the policy logic against state data and returns a pure boolean answer (true / false).
   • Does not execute business logic; it solely calculates permissions.

3. PIP (Policy Information Point):

   • The data source that provides contextual attributes needed for the decision (e.g., LDAP directory, user profile database, tenant metadata store).

4. PAP (Policy Administration Point):

   • The management plane where administrators write, test, version, and publish security policies.

code
Copy
[ Client ] ──(Request)──► [ PEP (Middleware / Envoy) ] ──► [ Business Handler ]
                                │                ▲
                  1. Evaluate   │                │ 4. ALLOW / DENY
                     Query      ▼                │
                          [ PDP (OPA Engine) ]
                                │
                  2. Fetch Data ▼
                          [ PIP (User DB / Redis) ]

Understanding the strict semantic boundary between status codes is crucial for API security and developer ergonomics:

Security Masking (404 vs 403):

If an attacker probes GET /api/v2/organizations/secret-corp/contracts/592:

• Returning 403 Forbidden confirms to the attacker that contract 592 exists under secret-corp.
• Returning 404 Not Found hides the existence of the document entirely from unauthorized actors. High-security platforms (GitHub, AWS S3) return 404 for private resources when the caller has no read permissions.

Below is a clean architectural implementation demonstrating the decoupled execution of AuthN and AuthZ in a Node.js/Express API:

typescript
Copy
import { Request, Response, NextFunction } from 'express';
import jwt from 'jsonwebtoken';

export interface AuthenticatedUser {
  id: string;
  tenantId: string;
  roles: string[];
  permissions: string[];
}

// Extend Express Request type
declare global {
  namespace Express {
    interface Request {
      user?: AuthenticatedUser;
    }
  }
}

/**
 * 1. Authentication Middleware (AuthN)
 * Verifies the caller's identity via JWT signature.
 * Returns 401 Unauthorized if verification fails.
 */
export function authenticateToken(publicKey: string) {
  return (req: Request, res: Response, next: NextFunction): void => {
    const authHeader = req.headers['authorization'];
    const token = authHeader && authHeader.split(' ')[1]; // Bearer <token>

    if (!token) {
      res.setHeader('WWW-Authenticate', 'Bearer error="invalid_token"');
      res.status(401).json({ error: 'Authentication required. No token provided.' });
      return;
    }

    jwt.verify(token, publicKey, { algorithms: ['RS256'] }, (err, decoded) => {
      if (err) {
        res.setHeader('WWW-Authenticate', 'Bearer error="invalid_token", error_description="Token expired or invalid"');
        res.status(401).json({ error: 'Invalid or expired token.' });
        return;
      }

      // Attach authenticated subject context
      req.user = decoded as AuthenticatedUser;
      next();
    });
  };
}

/**
 * 2. Authorization Middleware (AuthZ - PEP)
 * Checks if the authenticated user possesses the required permission.
 * Returns 403 Forbidden if permissions are insufficient.
 */
export function requirePermission(requiredPermission: string) {
  return (req: Request, res: Response, next: NextFunction): void => {
    if (!req.user) {
      // Invariant check: AuthZ must always follow AuthN
      res.status(401).json({ error: 'Unauthenticated context.' });
      return;
    }

    const hasPermission = req.user.permissions.includes(requiredPermission) ||
                          req.user.roles.includes('super_admin');

    if (!hasPermission) {
      res.status(403).json({ 
        error: 'Forbidden: Insufficient privileges for this action.',
        requiredPermission 
      });
      return;
    }

    next();
  };
}