The Security Glossary: 50+ Terms Every Dev Team Should Know

Security terminology confusion turns into architecture mistakes. A team that builds login on OAuth2 alone finds out weeks later that OAuth2 grants authorization and says nothing about identity. The fix is OIDC, and by then the token handling is already wired the wrong way on both the client and the API.

The terms below cover authentication, tokens, access control, and the Zero Trust vocabulary that shows up in design reviews. Each entry gives the definition, the implementation detail that decides whether it holds up, and the misconception that usually costs time. Where a sane default exists (OIDC over SAML for new systems, passkeys over passwords, short-lived access tokens over convenient ones), it is named.

Authentication Fundamentals

MFA (Multi-Factor Authentication)

Definition: Authentication requiring two or more independent factor types: something you know (password), something you have (phone), or something you are (fingerprint).

Implementation Reality: True MFA requires different factor types. Password + security question isn’t MFA - both are knowledge factors.

// Proper MFA implementation with FIDO2/WebAuthn
interface MFAChallenge {
  primaryAuth: 'password' | 'biometric';
  secondaryAuth: 'totp' | 'webauthn' | 'sms'; // Avoid SMS
  fallbackOptions: string[];
}

const authenticateUser = async (challenge: MFAChallenge) => {
  const primaryResult = await validatePrimary(challenge.primaryAuth);
  if (!primaryResult.success) return { success: false };

  const secondaryResult = await validateSecondary(challenge.secondaryAuth);
  return { success: secondaryResult.success };
};

Why SMS fails: SMS OTP is exposed to SIM swapping and carrier-level interception, so a factor that passed review years ago no longer counts as strong. NIST SP 800-63B treats SMS as a restricted authenticator for exactly this reason.

2FA vs 2SV (Two-Factor vs Two-Step Verification)

Key Difference: 2FA uses different factor types, 2SV can use the same type twice.

• 2FA: Password (knowledge) + hardware key (possession)
• 2SV: Password (knowledge) + SMS code (also knowledge - you know your phone number)

Industry Confusion: Google calls their 2SV implementation “2FA” in their UI, contributing to widespread misunderstanding.

Implementation Guidance: Always prefer true 2FA with hardware keys or biometric authenticators when possible.

OTP (One-Time Password)

TOTP (Time-based OTP): 30-second windows, RFC 6238 standard HOTP (Counter-based OTP): Less common, RFC 4226 standard SMS OTP: Deprecated due to SIM swapping vulnerabilities

import { authenticator } from 'otplib';

// Generate TOTP secret for new user
const secret = authenticator.generateSecret();

// Validate user's TOTP
const validateTOTP = (token: string, secret: string): boolean => {
  try {
    return authenticator.verify({ token, secret });
  } catch (error) {
    return false;
  }
};

// Always use window tolerance for clock drift
authenticator.options = { window: 1 }; // Allow 1 step tolerance

Implementation: Use authenticator apps like Google Authenticator or Authy, never SMS for new systems.

Biometric Authentication

Types: Fingerprint, facial recognition, iris scan, voice pattern Key Metrics: False Acceptance Rate (FAR) vs False Rejection Rate (FRR)

Critical Rule: Never use biometrics as sole authentication - always as second factor. Biometric data can’t be changed if compromised.

Platform Integration:

// WebAuthn biometric authentication
const authenticateWithBiometric = async () => {
  const credential = await navigator.credentials.create({
    publicKey: {
      challenge: new Uint8Array(32),
      rp: { name: "Your App" },
      user: { id: userId, name: username, displayName: displayName },
      pubKeyCredParams: [{ alg: -7, type: "public-key" }],
      authenticatorSelection: {
        authenticatorAttachment: "platform", // Built-in biometric
        userVerification: "required"
      }
    }
  });
};

Privacy Concerns: Biometric templates must be stored securely and be revocable. Apple’s Secure Enclave and Android’s TEE are current best practices.

Modern Authentication Protocols

OAuth2

Purpose: Authorization framework (NOT authentication!) Common Confusion: “We’re using OAuth2 for login” - No, OAuth2 tells you what someone can do, not who they are.

Grant Types:

• Authorization Code + PKCE (recommended for SPAs)
• Client Credentials (service-to-service)
• Device Flow (IoT/TV apps)
• Implicit Flow (deprecated, security issues)

// Secure OAuth2 implementation with PKCE
const oauth2Flow = async () => {
  const codeVerifier = generateCodeVerifier();
  const codeChallenge = await generateCodeChallenge(codeVerifier);

  const authUrl = `${authServer}/authorize?` +
    `response_type=code&` +
    `client_id=${clientId}&` +
    `redirect_uri=${redirectUri}&` +
    `scope=${scope}&` +
    `code_challenge=${codeChallenge}&` +
    `code_challenge_method=S256`;

  // After callback with authorization code
  const tokenResponse = await exchangeCodeForToken(code, codeVerifier);
};

Where teams lose time: Login built on plain OAuth2 works until someone asks who the user is. An access token carries scopes, not verified identity. Adding OIDC afterwards means reworking token handling on the client and the API at the same time.

OIDC (OpenID Connect)

Definition: Authentication layer built on OAuth2 Key Addition: ID tokens that actually tell you who the user is

Core Components:

• ID Token (JWT with user info)
• UserInfo Endpoint
• Discovery Endpoint (/.well-known/openid-configuration)

interface OIDCTokenResponse {
  access_token: string;  // For API calls (OAuth2)
  id_token: string;  // For authentication (OIDC)
  refresh_token: string;  // To get new tokens
  token_type: 'Bearer';
  expires_in: number;
}

const validateIdToken = async (idToken: string) => {
  const jwks = await fetchJWKS(issuer);
  const payload = jwt.verify(idToken, jwks);

  // Validate required claims
  assert(payload.iss === expectedIssuer);
  assert(payload.aud === clientId);
  assert(payload.exp > Date.now() / 1000);

  return payload; // Contains user identity info
};

When to Use: Modern web apps, mobile apps, SPAs - anything that needs to know who the user is.

ID Token (OIDC)

Definition: JWT containing user identity information, part of OpenID Connect Purpose: Authentication (who the user is) vs access tokens (what they can do)

Structure: Standard JWT with specific claims

interface IDTokenPayload {
  iss: string;  // Issuer (identity provider)
  sub: string;  // Subject (user identifier)
  aud: string;  // Audience (your client ID)
  exp: number;  // Expiry timestamp
  iat: number;  // Issued at timestamp
  auth_time: number; // When user actually authenticated
  nonce?: string;  // Prevents replay attacks

  // Standard profile claims
  name?: string;
  email?: string;
  picture?: string;

  // Custom claims
  roles?: string[];
  department?: string;
}

const validateIDToken = async (idToken: string) => {
  // 1. Verify signature using provider's public keys
  const jwks = await fetchJWKS(issuerUrl + '/.well-known/jwks.json');
  const decoded = jwt.verify(idToken, jwks) as IDTokenPayload;

  // 2. Validate standard claims
  if (decoded.iss !== expectedIssuer) throw new Error('Invalid issuer');
  if (decoded.aud !== clientId) throw new Error('Invalid audience');
  if (decoded.exp <= Math.floor(Date.now() / 1000)) throw new Error('Token expired');

  // 3. Validate auth_time if max_age was specified
  if (maxAge && decoded.auth_time < (Date.now()/1000 - maxAge)) {
    throw new Error('Authentication too old');
  }

  return decoded;
};

Key Differences from Access Tokens:

• ID tokens are for the client app to know who the user is
• Access tokens are for API calls to know what the user can do
• ID tokens should NOT be sent to APIs (use access tokens)
• ID tokens contain user profile information

Common Mistakes:

• Using ID token for API authentication (security risk)
• Not validating the signature server-side
• Storing sensitive data in ID token payload (it’s not encrypted)
• Sharing ID tokens between applications

SAML 2.0

Definition: XML-based authentication and authorization standard Enterprise Reality: Still widespread in large enterprises with established identity providers

Flow Types:

• SP-initiated (your app starts the flow)
• IdP-initiated (identity provider starts the flow)

Implementation Complexity: High due to XML signatures, certificate management, and complex configuration.

<!-- SAML Assertion Example -->
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
  <saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
      [email protected]
    </saml:NameID>
  </saml:Subject>
  <saml:AttributeStatement>
    <saml:Attribute Name="Role">
      <saml:AttributeValue>Manager</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Migration note: Moving from SAML to OIDC for modernization alone rarely pays off. Enterprise buyers standardize on the identity provider integrations they already run, so the protocol choice usually follows their infrastructure rather than yours.

Protocol Comparison Matrix

Protocol	Format	Complexity	Enterprise Adoption	Mobile Support
OAuth2	JSON	Low	Medium	Excellent
OIDC	JSON	Medium	Growing	Excellent
SAML	XML	High	Dominant	Poor

Token Security

JWT (JSON Web Token)

Structure: Header.Payload.Signature (all Base64URL encoded)

Best Practices:

• 15-minute maximum expiry for access tokens
• Use RS256 (asymmetric) over HS256 (symmetric) when possible
• Never put sensitive data in payload (it’s just Base64, not encrypted)

interface JWTPayload {
  iss: string;  // Issuer
  sub: string;  // Subject (user ID)
  aud: string;  // Audience
  exp: number;  // Expiry (UNIX timestamp)
  iat: number;  // Issued at
  nbf: number;  // Not before
  jti: string;  // JWT ID (for revocation)
}

const validateJWT = (token: string, publicKey: string): JWTPayload => {
  const decoded = jwt.verify(token, publicKey, {
    algorithms: ['RS256'],
    issuer: expectedIssuer,
    audience: expectedAudience
  });

  // Always check expiry server-side
  if (decoded.exp <= Math.floor(Date.now() / 1000)) {
    throw new Error('Token expired');
  }

  return decoded as JWTPayload;
};

Why short expiry matters: A 30-day access token turns a single leak into a month of access, because a stateless JWT stays valid until it expires. Keep access tokens short and move the lifetime pressure to the refresh flow, which you can revoke server-side.

JWKS (JSON Web Key Set)

Definition: A JSON document containing public keys used to verify JWT signatures, typically served at /.well-known/jwks.json.

Implementation: OAuth2/OpenID Connect providers publish their public keys as JWKS for token verification.

interface JWKSKey {
  kty: string;  // Key type (RSA, EC)
  use: string;  // Usage (sig for signature)
  kid: string;  // Key ID
  n: string;  // RSA modulus (Base64URL)
  e: string;  // RSA exponent (Base64URL)
}

const fetchJWKS = async (issuerUrl: string): Promise<JWKSKey[]> => {
  const response = await fetch(`${issuerUrl}/.well-known/jwks.json`);
  const jwks = await response.json();
  return jwks.keys;
};

// Find the correct key by kid (Key ID)
const getSigningKey = (jwks: JWKSKey[], kid: string): JWKSKey => {
  const key = jwks.find(k => k.kid === kid);
  if (!key) throw new Error(`Key ${kid} not found in JWKS`);
  return key;
};

Cache trap: A JWKS cache that never refreshes keeps failing signature checks after the provider rotates keys, and the error message says only “invalid signature”. Match the kid in the token header against the key set, and refetch the set when the kid is unknown.

Best Practices:

• Cache JWKS but implement automatic refresh
• Always verify the kid (Key ID) matches
• Handle key rotation gracefully

Signing Key / Private Key

Definition: The cryptographic private key used to digitally sign JWTs, creating the signature portion that proves authenticity.

Implementation: Must be securely stored and rotated regularly. Only the token issuer should have access.

// Server-side JWT signing (RS256)
const signJWT = (payload: JWTPayload, privateKey: string): string => {
  return jwt.sign(payload, privateKey, {
    algorithm: 'RS256',
    keyid: currentKeyId,  // Include kid for JWKS lookup
    expiresIn: '15m'
  });
};

// Key rotation strategy
interface SigningKeyPair {
  kid: string;
  privateKey: string;
  publicKey: string;
  createdAt: Date;
}

const rotateSigningKeys = async (): Promise<void> => {
  // Generate new keypair
  const newKeyPair = generateRSAKeyPair();

  // Store new private key securely
  await keyStore.store(newKeyPair.kid, newKeyPair.privateKey);

  // Update JWKS with new public key
  await updateJWKS(newKeyPair.publicKey, newKeyPair.kid);

  // Keep old key active for grace period
  scheduleKeyRetirement(previousKeyId, '24h');
};

Security Requirements:

• Store private keys in HSM or secure key management system
• Rotate keys regularly (monthly minimum)
• Never expose private keys in logs or client code
• Use strong key lengths (RSA 2048+ or EC P-256+)

Lifecycle: Signing keys meant to be temporary tend to stay in production until an incident forces a change, because nothing in the system expires them. Decide the rotation interval and write the retirement job when the first key is issued.

Access Tokens vs Refresh Tokens

Access Tokens: Short-lived (5-15 minutes), used for API calls Refresh Tokens: Longer-lived (7 days), used to get new access tokens

Storage Strategy:

• Access tokens: Memory only (never localStorage)
• Refresh tokens: Secure, httpOnly cookies when possible

class TokenManager {
  private accessToken: string | null = null;
  private refreshToken: string | null = null;
  private refreshPromise: Promise<string> | null = null;

  async getValidAccessToken(): Promise<string> {
    if (this.accessToken && !this.isTokenExpired(this.accessToken)) {
      return this.accessToken;
    }

    // Prevent concurrent refresh requests
    if (!this.refreshPromise) {
      this.refreshPromise = this.refreshAccessToken();
    }

    return this.refreshPromise;
  }

  private async refreshAccessToken(): Promise<string> {
    try {
      const response = await fetch('/auth/refresh', {
        method: 'POST',
        credentials: 'include', // Include httpOnly refresh token
      });

      const { access_token, refresh_token } = await response.json();

      this.accessToken = access_token;
      // Refresh token rotation - always get new refresh token
      if (refresh_token) {
        this.refreshToken = refresh_token;
      }

      return access_token;
    } finally {
      this.refreshPromise = null;
    }
  }
}

Token Rotation: Always rotate refresh tokens on use to limit damage if compromised.

Bearer Tokens vs API Keys

Bearer Tokens: Dynamic, short-lived, part of OAuth2/JWT ecosystem API Keys: Static, long-lived, simple authentication mechanism

When to Use:

• Bearer tokens: User authentication, dynamic permissions
• API keys: Service-to-service, simple integrations, webhooks

Security Comparison:

// Bearer Token (preferred for user auth)
const callAPIWithBearer = async (endpoint: string) => {
  const token = await tokenManager.getValidAccessToken();
  return fetch(endpoint, {
    headers: {
      'Authorization': `Bearer ${token}`
    }
  });
};

// API Key (acceptable for service auth)
const callAPIWithKey = async (endpoint: string) => {
  return fetch(endpoint, {
    headers: {
      'X-API-Key': process.env.API_KEY, // Never expose in client
      'User-Agent': 'MyService/1.0'
    }
  });
};

Zero Trust & Modern Security

Zero Trust Architecture

Principle: “Never trust, always verify” Core Components: Identity, device, network, application, data verification

Implementation Phases:

1. Identify: Map all users, devices, applications, data
2. Protect: Implement least-privilege access controls
3. Detect: Monitor for anomalies and threats
4. Respond: Automated threat response and remediation

Scope: Zero Trust is a program, not a component. Identity, device posture, and segmentation sit with different teams, so the sequencing of those four phases decides the timeline more than the tooling does.

// Zero Trust policy example
interface ZeroTrustPolicy {
  user: {
    verified: boolean;
    riskScore: number;
    mfaCompleted: boolean;
  };
  device: {
    managed: boolean;
    compliant: boolean;
    lastSeen: Date;
  };
  network: {
    location: string;
    trustLevel: 'high' | 'medium' | 'low';
  };
  resource: {
    classification: 'public' | 'internal' | 'confidential' | 'restricted';
    requiredClearance: number;
  };
}

const evaluateAccess = (policy: ZeroTrustPolicy): boolean => {
  // Continuous verification - every request
  if (!policy.user.verified || !policy.user.mfaCompleted) return false;
  if (!policy.device.managed || !policy.device.compliant) return false;
  if (policy.user.riskScore > policy.resource.requiredClearance) return false;

  return true;
};

ZTNA (Zero Trust Network Access)

Replaces: Traditional VPN with microsegmentation Benefits: Application-specific access instead of full network reachability once a client connects

Implementation Types:

• Agent-based: Software on each device
• Agentless: Browser-based access

Major Vendors: Zscaler, Palo Alto Prisma, Cloudflare Access

SASE (Secure Access Service Edge)

Components: SD-WAN + ZTNA + CASB + FWaaS + SWG Definition: Cloud-native security platform combining networking and security

Trade-off: One vendor for networking and security removes integration work between the components and concentrates vendor risk in a single control plane.

Web Security Headers

HSTS (HTTP Strict Transport Security)

Purpose: Forces HTTPS for specified duration Header Example: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Implementation Strategy:

# Start with short duration for testing
add_header Strict-Transport-Security "max-age=300" always;

# After testing, increase duration
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

# Finally, add preload for maximum security
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Preload Lists: Chrome, Firefox, Edge maintain hardcoded lists of HSTS domains.

CSP (Content Security Policy)

Purpose: Prevents XSS and injection attacks by controlling resource loading

Progressive Implementation:

# Start with report-only mode
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

# Basic policy
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'

# Strict policy (goal)
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:

Common Pitfall: Breaking third-party scripts (Google Analytics, chat widgets). Always test in report-only mode first.

Certificate Pinning (Deprecated)

Status: HPKP is deprecated and removed from major browsers, so the header no longer protects anything Risk: Self-DOS if keys change unexpectedly

Modern Alternative: Certificate Transparency (CT) + CAA records

; CAA record example
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild ";"
example.com. CAA 0 iodef "mailto:[email protected]"

Access Control Models

RBAC (Role-Based Access Control)

Pattern: Users → Roles → Permissions Best For: Stable organizational structures

-- RBAC Database Schema
CREATE TABLE roles (
  id UUID PRIMARY KEY,
  name VARCHAR(255) NOT NULL,
  description TEXT
);

CREATE TABLE permissions (
  id UUID PRIMARY KEY,
  resource VARCHAR(255) NOT NULL,
  action VARCHAR(255) NOT NULL
);

CREATE TABLE role_permissions (
  role_id UUID REFERENCES roles(id),
  permission_id UUID REFERENCES permissions(id),
  PRIMARY KEY (role_id, permission_id)
);

CREATE TABLE user_roles (
  user_id UUID REFERENCES users(id),
  role_id UUID REFERENCES roles(id),
  granted_at TIMESTAMP DEFAULT NOW(),
  PRIMARY KEY (user_id, role_id)
);

Role Explosion Prevention: Use hierarchical roles and role composition instead of creating specific roles for every permission combination.

ABAC (Attribute-Based Access Control)

Pattern: Dynamic permissions based on user, resource, environment, and action attributes

Example Policy: “Doctors can view patient records in their department during work hours”

interface ABACAttributes {
  user: {
    role: string;
    department: string;
    clearanceLevel: number;
  };
  resource: {
    type: string;
    owner: string;
    classification: string;
  };
  environment: {
    time: Date;
    location: string;
    network: string;
  };
  action: string;
}

const evaluateABACPolicy = (attrs: ABACAttributes): boolean => {
  // Complex rule evaluation
  if (attrs.user.role === 'doctor' &&
      attrs.resource.type === 'patient_record' &&
      attrs.action === 'read') {

    const currentHour = attrs.environment.time.getHours();
    const isWorkHours = currentHour >= 8 && currentHour <= 18;
    const sameDepartment = attrs.user.department === attrs.resource.owner;

    return isWorkHours && sameDepartment;
  }

  return false;
};

Use Case: Complex, contextual access requirements that can’t be modeled with static roles.

IAM (Identity and Access Management)

Definition: Comprehensive identity lifecycle management Components: Authentication, authorization, administration, audit

Major Platforms: AWS IAM, Microsoft Entra ID (formerly Azure AD), Okta, Auth0. The hosted providers price per active user or per monthly active user, so cost tracks directory size rather than request volume; check the current tier list before budgeting.

Federation: Connecting multiple identity sources (Active Directory, Google Workspace, etc.)

Principle of Least Privilege

Definition: Grant minimum necessary permissions Implementation: Time-bound access (JIT/JEA), regular access reviews

// Just-in-Time (JIT) access example
interface JITAccessRequest {
  userId: string;
  resource: string;
  permissions: string[];
  duration: number; // minutes
  justification: string;
  approver?: string;
}

const grantJITAccess = async (request: JITAccessRequest) => {
  // Require approval for sensitive resources
  if (request.resource.includes('production')) {
    await requireApproval(request);
  }

  // Grant access with automatic revocation
  await grantPermissions(request.userId, request.permissions);

  // Schedule automatic revocation
  setTimeout(async () => {
    await revokePermissions(request.userId, request.permissions);
  }, request.duration * 60 * 1000);

  // Log for audit
  auditLog.log('JIT_ACCESS_GRANTED', request);
};

Automation: Remove unused permissions automatically based on usage patterns.

Emerging Standards

Passkeys (FIDO2/WebAuthn)

Definition: Passwordless authentication using device-native biometrics or PINs Adoption: Supported natively by Apple, Google, and Microsoft platforms, with credential sync through their respective password managers

Implementation:

// Create passkey for new user
const createPasskey = async () => {
  const credential = await navigator.credentials.create({
    publicKey: {
      challenge: new Uint8Array(32),
      rp: { name: "Your App", id: "yourapp.com" },
      user: {
        id: new TextEncoder().encode(userId),
        name: userEmail,
        displayName: userName
      },
      pubKeyCredParams: [
        { type: "public-key", alg: -7 },  // ES256
        { type: "public-key", alg: -257 } // RS256
      ],
      authenticatorSelection: {
        authenticatorAttachment: "platform", // Built into device
        requireResidentKey: true,
        userVerification: "required"
      }
    }
  });

  // Store credential ID and public key on server
  await registerCredential(userId, credential);
};

// Authenticate with passkey
const authenticateWithPasskey = async () => {
  const assertion = await navigator.credentials.get({
    publicKey: {
      challenge: new Uint8Array(32),
      allowCredentials: userCredentials.map(cred => ({
        type: "public-key",
        id: cred.id
      })),
      userVerification: "required"
    }
  });

  // Verify assertion on server
  const isValid = await verifyAssertion(assertion);
  return isValid;
};

User Experience: Touch Face ID or Windows Hello, no passwords to remember.

FIDO2 Components

WebAuthn: W3C standard implemented by current Chrome, Safari, Firefox, and Edge CTAP2: Communication protocol between platform and authenticators

Authenticator Types:

• Platform: Built into device (Touch ID, Face ID, Windows Hello)
• Roaming: External keys (YubiKey, USB/NFC devices)

DPoP (Demonstration of Proof of Possession)

Purpose: Binds OAuth2 tokens to client’s private key to prevent token theft/replay Status: RFC 9449 (2023), early adoption phase

Implementation: Client proves possession of private key with each token use

// DPoP token binding
const createDPoPProof = async (httpMethod: string, url: string, accessToken: string) => {
  const header = {
    typ: 'dpop+jwt',
    alg: 'ES256',
    jwk: publicKeyJWK
  };

  const payload = {
    jti: generateUUID(),
    htm: httpMethod,
    htu: url,
    iat: Math.floor(Date.now() / 1000),
    ath: await sha256(accessToken) // Access token hash
  };

  return jwt.sign(payload, privateKey, { header });
};

// Use DPoP proof with API request
const callAPIWithDPoP = async (url: string, accessToken: string) => {
  const dPopProof = await createDPoPProof('GET', url, accessToken);

  return fetch(url, {
    headers: {
      'Authorization': `DPoP ${accessToken}`,
      'DPoP': dPopProof
    }
  });
};

Legacy Authentication Methods

Basic Authentication

Method: Base64 encoded username:password in Authorization header Security: Low - credentials sent with every request

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Use Cases: Simple scripts, legacy system integration Requirements: MUST use HTTPS

Digest Authentication

Status: Obsolete - uses broken MD5 hashing Use: Legacy system support only, never for new systems

Migration Path: Replace with OAuth2/OIDC or at minimum, modern token-based auth.

Mutual TLS (mTLS)

Definition: Both client and server present certificates Use Cases: Service-to-service communication, IoT devices, high-security environments

// mTLS client configuration
const httpsOptions = {
  cert: fs.readFileSync('client-cert.pem'),
  key: fs.readFileSync('client-key.pem'),
  ca: fs.readFileSync('ca-cert.pem'),
  rejectUnauthorized: true
};

const makeSecureRequest = () => {
  return fetch('https://api.example.com/secure', {
    agent: new https.Agent(httpsOptions)
  });
};

Operational Overhead: Certificate management, rotation, revocation lists Modern Alternative: Service mesh with automatic mTLS (Istio, Linkerd)

Metrics to Track

Authentication Metrics

• Failed authentication rate (target: <2%)
• MFA adoption percentage (target: 100% for admin accounts)
• Average authentication time (target: <3 seconds)
• Password reset frequency (reduce with passwordless)
• Token refresh rate and failures

Security Metrics

• Mean Time to Detect (MTTD) security incidents
• Mean Time to Respond (MTTR) to threats
• Privilege escalation attempts
• Unusual authentication patterns (geographic, time-based)
• Cross-origin authentication failures

User Experience Metrics

• Login success rate (target: >99%)
• Authentication abandonment rate (target: <1%)
• Support ticket volume
• Session duration patterns
• Biometric authentication failure rate

Common Pitfalls & Implementation Lessons

Authentication Pitfalls

• OAuth2 Confusion: Using OAuth2 without OIDC for authentication (common expensive mistake)
• Password Storage: Storing plaintext or poorly hashed passwords (use Argon2id)
• Token Lifetimes: Long-lived tokens without rotation (creates extended vulnerability windows)
• SMS OTP Reliance: Using SMS as the sole second factor today (SIM swapping is prevalent)
• Account Lockout: Missing or inadequate lockout policies

Implementation Pitfalls

• Single Point of Failure: No fallback authentication method
• Session Management: Poor session handling and timeout policies
• Rate Limiting: Missing rate limiting on authentication endpoints
• Information Disclosure: Error messages that enable user enumeration
• Synchronous Validation: Blocking token validation affecting performance

Operational Pitfalls

• Token Revocation: No mechanism to revoke compromised tokens
• Audit Gaps: Missing comprehensive authentication logging
• Key Rotation: Manual key rotation processes that fail
• Certificate Expiry: No automated certificate renewal (an expired cert takes the service down)
• Manual Provisioning: Lack of automated user lifecycle management

Defaults for New Projects

Technical Decisions

• Start with OIDC: Add SAML only when enterprise customers specifically require it
• Passkeys First: Implement FIDO2/WebAuthn from day one for any new project
• Managed Services: Use Auth0, Okta, or AWS Cognito instead of building authentication systems
• Certificate Automation: Implement automated certificate management (Let’s Encrypt, AWS ACM) immediately
• Token Rotation: Design for refresh token rotation from the start, not as an afterthought

Process Improvements

• Security Training First: Train the team before implementing, not after the first incident
• Incremental Rollout: Use feature flags for gradual authentication method rollouts
• A/B Testing: Test authentication flows for user experience impact
• Friction Monitoring: Continuously measure and optimize authentication friction
• Regular Drills: Conduct security incident response drills quarterly

Strategic Choices

• Buy vs Build: Buy authentication infrastructure; a bespoke identity provider is rarely a differentiator and always a maintenance burden
• Compliance Upfront: Check regulatory requirements (SOX, HIPAA, GDPR) before architecture decisions, because they constrain retention, logging, and factor choice

These defaults hold for new systems on current stacks: OIDC for identity, passkeys where the platform supports them, short-lived access tokens with rotating refresh tokens, and least privilege enforced by policy instead of convention. Override them when an enterprise buyer’s identity provider speaks only SAML, when the device fleet cannot register platform authenticators, or when a regulator names a specific control.

References

• OWASP Top Ten Web Application Security Risks - The foundational OWASP list of the most critical security risks to web applications, updated regularly by the community.
• OWASP Authentication Cheat Sheet - Practical guidance on implementing secure authentication, covering passwords, MFA, session management, and common pitfalls.
• NIST SP 800-63B Digital Identity Guidelines: Authentication - NIST’s authoritative guidelines on authentication assurance levels, authenticator types, and lifecycle management.
• RFC 6749 - The OAuth 2.0 Authorization Framework - The IETF standard defining OAuth 2.0 roles, grant types, and token mechanics.
• RFC 7519 - JSON Web Token (JWT) - The IETF standard specifying the JWT format, claims structure, and signing requirements.
• W3C WebAuthn Level 2 Specification - The W3C Recommendation defining the Web Authentication API for strong, phishing-resistant passwordless authentication using FIDO2/passkeys.
• NIST Cybersecurity Glossary - Comprehensive glossary of over 10,000 cybersecurity and privacy terms from NIST standards and guidelines.