Authentication & Authorization: Zero-Trust Identity Engineering

Identity Fundamentals: AuthN vs. AuthZ & Cryptographic Password Hashing

Full-stack security begins with a rigorous distinction between two foundational concepts:

• Authentication (AuthN): "Who are you?" The verification of an entity's claimed identity through provided credentials (passwords, biometrics, signed tokens, or cryptographic keys).
• Authorization (AuthZ): "What are you permitted to do?" The policy enforcement mechanism determining whether an authenticated subject possesses the necessary permissions to perform an operation on a specific resource.

1. The Physics of Password Hashing: Why Fast Hashes Are Dangerous

Cryptographic hash algorithms such as MD5, SHA-1, and SHA-256 were designed for high-throughput data integrity verification. A modern GPU cluster can compute billions of SHA-256 hashes per second. If an attacker exfiltrates a database of SHA-256 password hashes, they can execute offline dictionary and brute-force attacks in minutes, pre-computing outputs into Rainbow Tables.

Password hashing requires intentionally slow, computationally expensive, adaptive key derivation functions:

• Cryptographic Salt: A cryptographically secure pseudo-random byte sequence (typically 16 bytes) generated uniquely for every user. Salting ensures that two users with the exact same password produce completely different hashes, completely neutralizing pre-computed Rainbow Table attacks.
• Adaptive Cost Factor (Work Factor): Algorithms like Bcrypt (based on the Blowfish cipher's Eksblowfish key setup), Argon2id (winner of the Password Hashing Competition), and PBKDF2 incorporate a configurable cost factor:

  Number of Iterations = 2 ^ CostFactor

  A Bcrypt cost factor of 12 executes 4,096 key expansion rounds (~250-350 milliseconds per hash). As hardware advances over time, system architects simply increment the cost factor, doubling the computational effort required by attackers without altering the underlying code.

$2b$12$e8Y4J2zB6q7A9eM1kL3oPuN9gV5tW8yX0rZ3sC1vB4nQ7wE2rT5uY
--- -- ---------------------- -----------------------------------
 |   |           |                             |
 |   |           |                             +--> 31-character checksum (184 bits)
 |   |           +--> 22-character Base64 salt (128 bits)
 |   +--> Cost Factor = 12 (2^12 = 4,096 iterations)
 +--> Algorithm Identifier: $2b$ (Bcrypt standard)

Session-Based Authentication vs. Stateless JSON Web Tokens (JWT)

Enterprise architectures authenticate subsequent HTTP requests using one of two primary paradigms:

1. Stateful Session-Based Authentication

Upon successful login, the server generates a cryptographically random 128-bit Session ID, stores session state (e.g., user ID, permissions, IP address) in a shared in-memory data store (such as Redis), and transmits the Session ID to the browser inside a Set-Cookie response header. On subsequent requests, the browser automatically transmits the cookie. The server retrieves the session record from Redis.

• Pros: Immediate server-side revocation (calling redis.del(sessionId) instantly logs out the user); compact cookie size.
• Cons: Requires stateful infrastructure; every incoming request triggers an external database or Redis network round-trip; challenges in cross-domain multi-service topologies.

2. Stateless Token-Based Authentication (JWT)

A JSON Web Token (RFC 7519) is a compact, URL-safe container format consisting of three base64url-encoded parts separated by periods (header.payload.signature):

• Header: Specifies token type and cryptographic signature algorithm ({ "alg": "HS256", "typ": "JWT" }).
• Payload: Contains identity claims (sub: user ID, iat: issued at, exp: expiration, roles: ['admin']). The payload is signed, not encrypted—never store plaintext passwords or secrets inside a JWT!
• Signature: Cryptographic hash calculated over HMACSHA256(base64Url(header) + "." + base64Url(payload), secretKey).

Browser Storage Security: Cookie Flags & Attack Vector Defenses

Where should client applications store authentication tokens? Storing tokens in browser localStorage or sessionStorage is an existential vulnerability: any malicious script injected through a Cross-Site Scripting (XSS) flaw can immediately access localStorage.getItem('token') and exfiltrate user credentials to an attacker's command-and-control server.

1. The Four Mandatory Security Cookie Flags

Tokens must be transmitted using HTTP Cookies configured with strict defensive flags:

• HttpOnly: Completely blocks client-side JavaScript from accessing the cookie via document.cookie. Completely neutralizes token exfiltration via XSS.
• Secure: Mandates that the browser will only transmit the cookie over encrypted TLS/HTTPS connections, preventing cleartext sniffing on public Wi-Fi networks.
• SameSite (CSRF Mitigation): Controls whether cookies are attached to cross-site requests:
  • SameSite=Strict: Cookie is never sent on cross-site requests (e.g., following a link from an external website). Highest security.
  • SameSite=Lax (Default): Cookie is withheld on cross-site subrequests (images, iframes), but included when a user navigates to the origin via top-level link clicks.
  • SameSite=None: Cookie is sent on all cross-site requests; requires Secure flag (used for third-party widget embeds).
• Domain & Path: Strictly limits the scope of cookie transmission to specific subdomains (Domain=api.devascent.me) and endpoint roots (Path=/api/v1/auth).

The Dual-Token Refresh Rotation Architecture

Stateless JWTs suffer from a major architectural drawback: once issued, a token cannot be revoked until it naturally expires. If an access token with a 30-day lifetime is compromised, the attacker retains full access for 30 days.

The enterprise solution is the Dual-Token Refresh Pattern with Automatic Rotation:

• Short-Lived Access Token: Lifetime of 5 to 15 minutes. Stored in memory (React JavaScript memory or closure). Transmitted in the Authorization: Bearer <token> header. Used for rapid, stateless endpoint access.
• Long-Lived Refresh Token: Lifetime of 7 to 30 days. Stored inside an HttpOnly, Secure, SameSite=Strict cookie restricted to the /api/v1/auth/refresh path. Its cryptographic hash is recorded in the database.

Federated Identity: OAuth 2.0, OpenID Connect & PKCE

OAuth 2.0 (RFC 6749) is an authorization delegation framework allowing a third-party application to obtain limited access to a user's HTTP resources without obtaining their password. OpenID Connect (OIDC) is an identity layer built directly atop OAuth 2.0 that provides standardized user authentication via an id_token.

1. The Four Core OAuth 2.0 Roles

• Resource Owner: The end-user who grants access to their account.
• Client: The web or mobile application requesting access (e.g., DevAscent Portal).
• Authorization Server: The identity provider authenticating the user and issuing tokens (e.g., Google Accounts, GitHub).
• Resource Server: The API hosting protected user data (e.g., Google Drive API, GitHub Repositories API).

2. The Authorization Code Flow with PKCE

For Single Page Applications (React, Vue) where client secrets cannot be securely stored on client machines, OAuth 2.0 mandates the Authorization Code Flow with Proof Key for Code Exchange (PKCE):

Access Control Architectures: Role-Based Access Control (RBAC)

Once authenticated, authorization governs user capabilities across API endpoints. Role-Based Access Control (RBAC) models permissions hierarchically:

• Users are assigned one or more Roles (e.g., STUDENT, INSTRUCTOR, ADMIN).
• Roles encapsulate discrete Permissions (e.g., course:read, course:write, user:delete).
• Route guard middlewares inspect user claims on incoming requests: if req.user.role lacks the required capability, execution immediately terminates with HTTP 403 Forbidden.

Cryptographic Reset Flows & Email Verification Architecture

Password reset and account verification workflows are frequent targets for account takeover attacks. Secure systems adhere to strict cryptographic workflows:

• High-Entropy Unpredictable Tokens: Generate a 256-bit cryptographically secure random token (crypto.randomBytes(32).toString('hex')).
• Hashed Token Storage: Never store the raw token in the database! Compute a SHA-256 hash of the token (crypto.createHash('sha256').update(rawToken).digest('hex')) and persist only the hash with an expiration timestamp (typically 15 to 30 minutes). If the database is compromised, attackers cannot forge reset links.
• Single-Use Invalidation & Session Termination: When the user submits their new password alongside the token, verify the hash, update the Bcrypt password, immediately clear the token field, and revoke all active refresh tokens to disconnect unauthorized sessions.
• Anti-Enumeration Responses: When a user requests a reset for an email address, always return a uniform response: "If an account exists with this email, a reset link has been dispatched." Never reveal whether the email exists in the database.

Multi-Factor Authentication (MFA): TOTP RFC 6238 Internals

Multi-factor authentication requires verification across at least two distinct authentication categories: (1) Something you know (password), (2) Something you have (authenticator app, hardware key), or (3) Something you are (biometrics).

1. Mathematical Mechanics of TOTP (RFC 6238)

The Time-Based One-Time Password (TOTP) algorithm operates completely offline without SMS networks:

1. During enrollment, server and client share an unguessable secret key (Base32 encoded), typically exchanged via a QR code (otpauth://totp/...).
2. Both parties compute a counter representing the current epoch timestamp divided into 30-second time steps:

   Counter = Floor(UnixTime / 30)

3. Compute an HMAC-SHA1 (or SHA256) digest of the counter using the shared secret:

   Hash = HMAC-SHA1(SharedSecret, Counter)

4. Perform Dynamic Truncation to extract a 4-byte integer from the hash, then compute modulo 1,000,000 to produce a 6-digit numeric verification code.
5. The server allows a drift window of +/- 1 time step (allowing for +/- 30 seconds clock drift between phone and server).

Production Implementations: Express Auth Engine & RBAC Route Guards

1. Enterprise Express Authentication Controller & Dual-Token Issuance

The code below demonstrates production user registration, secure Bcrypt hashing, dual-token generation, and HTTP-only cookie setting.

import { Request, Response, NextFunction, Router } from 'express';
import bcrypt from 'bcrypt';
import jwt from 'jsonwebtoken';
import crypto from 'node:crypto';

const router = Router();
const BCRYPT_ROUNDS = 12;
const ACCESS_SECRET = process.env.JWT_ACCESS_SECRET || 'super-secret-access-key-2026';
const REFRESH_SECRET = process.env.JWT_REFRESH_SECRET || 'super-secret-refresh-key-2026';

interface TokenPayload {
  userId: string;
  role: string;
}

// User Registration Handler
router.post('/register', async (req: Request, res: Response, next: NextFunction) => {
  try {
    const { email, password, fullName } = req.body;

    // 1. Hash password with Bcrypt using 12 salt rounds (~300ms)
    const salt = await bcrypt.genSalt(BCRYPT_ROUNDS);
    const passwordHash = await bcrypt.hash(password, salt);

    // 2. Persist user in database (Simulated)
    const newUser = {
      id: crypto.randomUUID(),
      email,
      passwordHash,
      role: 'STUDENT',
      isEmailVerified: false
    };

    res.status(201).json({
      success: true,
      message: 'User registered. Please verify your email.',
      userId: newUser.id
    });
  } catch (err) {
    next(err);
  }
});

// User Login Handler with Dual-Token Issuance
router.post('/login', async (req: Request, res: Response, next: NextFunction) => {
  try {
    const { email, password } = req.body;

    // 1. Find user (Mock lookup)
    const user = { id: 'usr_9182', email, role: 'STUDENT', hash: '$2b$12$...' };

    // 2. Verify password with timing-safe comparison
    const isMatch = await bcrypt.compare(password, user.hash);
    if (!isMatch) {
      return res.status(401).json({ error: 'Invalid email or password credentials' });
    }

    const payload: TokenPayload = { userId: user.id, role: user.role };

    // 3. Issue Short-Lived Access Token (15m)
    const accessToken = jwt.sign(payload, ACCESS_SECRET, { expiresIn: '15m' });

    // 4. Issue Long-Lived Refresh Token (7d)
    const refreshToken = jwt.sign(payload, REFRESH_SECRET, { expiresIn: '7d' });

    // 5. Transmit Refresh Token in HttpOnly Secure Cookie
    res.cookie('refreshToken', refreshToken, {
      httpOnly: true,
      secure: process.env.NODE_ENV === 'production',
      sameSite: 'strict',
      maxAge: 7 * 24 * 60 * 60 * 1000, // 7 days
      path: '/api/v1/auth/refresh'
    });

    // 6. Return Access Token in Response Body for In-Memory Storage
    res.status(200).json({ success: true, accessToken });
  } catch (err) {
    next(err);
  }
});

// ==========================================
// 2. RBAC ROUTE GUARD MIDDLEWARE FACTORY
// ==========================================
export const requireAuth = (allowedRoles: string[] = []) => {
  return (req: Request, res: Response, next: NextFunction) => {
    const authHeader = req.headers.authorization;
    if (!authHeader || !authHeader.startsWith('Bearer ')) {
      return res.status(401).json({ error: 'Missing or malformed Authorization Bearer token' });
    }

    const token = authHeader.split(' ')[1];

    try {
      const decoded = jwt.verify(token, ACCESS_SECRET) as TokenPayload;
      (req as any).user = decoded;

      // Check Role Authorization
      if (allowedRoles.length > 0 && !allowedRoles.includes(decoded.role)) {
        return res.status(403).json({ error: 'Forbidden: Insufficient role permissions' });
      }

      next();
    } catch (err) {
      return res.status(401).json({ error: 'Expired or invalid access token' });
    }
  };
};

export default router;

2. Production React Protected Route Guard

The component below prevents unauthorized layout rendering, checks user roles against required privileges, and routes unauthenticated users to the login screen with redirection memory.

import React from 'react';
import { Navigate, Outlet, useLocation } from 'react-router-dom';

interface ProtectedRouteProps {
  isAuthenticated: boolean;
  userRole?: string;
  allowedRoles?: string[];
}

export const ProtectedRoute: React.FC<ProtectedRouteProps> = ({
  isAuthenticated,
  userRole,
  allowedRoles = []
}) => {
  const location = useLocation();

  // 1. Unauthenticated: Redirect to login while preserving target path for post-login redirect
  if (!isAuthenticated) {
    return <Navigate to="/login" state={{ from: location }} replace />;
  }

  // 2. Unauthorized Role: Redirect to 403 Forbidden screen
  if (allowedRoles.length > 0 && (!userRole || !allowedRoles.includes(userRole))) {
    return <Navigate to="/unauthorized" replace />;
  }

  // 3. Authorized: Render child routes
  return <Outlet />;
};

University & Industrial Examination Review