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, it is named: OIDC for new systems, passkeys as the primary factor, short-lived access tokens with rotating refresh tokens.

Authentication Fundamentals#

MFA (Multi-Factor Authentication)#

MFA requires two or more independent factor types: something you know (password), something you have (phone), or something you are (fingerprint). True MFA needs different factor types; password plus security question isn’t MFA, since 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 };
};

SMS OTP is exposed to SIM swapping and carrier-level interception. NIST SP 800-63B treats SMS as a restricted authenticator for this reason.

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

2FA uses different factor types; 2SV can reuse the same type twice, which is where the confusion starts.

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

Google’s own UI blurs the line further: it labels its 2SV implementation “2FA.” When there’s a choice, prefer true 2FA with hardware keys or biometric authenticators.

OTP (One-Time Password)#

TOTP (time-based OTP) uses 30-second windows under RFC 6238. HOTP (counter-based OTP) is less common and follows RFC 4226. SMS OTP is deprecated because of 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

Use authenticator apps like Google Authenticator or Authy for new systems; never SMS.

Biometric Authentication#

Biometric authentication covers fingerprint, facial recognition, iris scan, and voice pattern, evaluated against False Acceptance Rate (FAR) and False Rejection Rate (FRR).

Never use biometrics as the sole authentication factor; treat them as a second factor only, since biometric data can’t be changed once it’s compromised.

A WebAuthn platform authenticator call looks like this:

// 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"
      }
    }
  });
};

Biometric templates must be stored securely and stay revocable. Apple’s Secure Enclave and Android’s TEE are the current best practices for that.

Modern Authentication Protocols#

OAuth2#

OAuth2 is an authorization framework. Teams that build login directly on it hit a wall the moment something asks who the user is, since the access token only carries scopes.

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);
};

OIDC (OpenID Connect)#

OIDC is an authentication layer built on top of OAuth2; its main addition is the ID token, which actually tells you who the user is.

It adds three pieces on top of OAuth2:

• 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
};

Modern web apps, mobile apps, and SPAs need it whenever they must know who the user is.

ID Token (OIDC)#

The ID token is a JWT containing user identity information, part of OpenID Connect. It exists for authentication (who the user is), unlike access tokens, which cover what they can do.

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;
};

The two tokens diverge in a few concrete ways:

• 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

The mistakes that show up in review tend to repeat:

• 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#

SAML 2.0 is an XML-based authentication and authorization standard. It’s still widespread in large enterprises with established identity providers, and moving to OIDC for modernization alone rarely pays off: enterprise buyers standardize on the identity provider integrations they already run, so the protocol choice follows their infrastructure.

It supports two flow types:

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

Implementation complexity runs high: XML signatures, certificate management, and configuration that gets complicated fast.

<!-- 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">
      user@company.com
    </saml:NameID>
  </saml:Subject>
  <saml:AttributeStatement>
    <saml:Attribute Name="Role">
      <saml:AttributeValue>Manager</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

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)

A few practices keep JWTs from becoming the weak point:

• 15-minute maximum expiry for access tokens (a 30-day token turns a single leak into a month of exposure)
• Use RS256 (asymmetric) over HS256 (symmetric) when possible
• Never put sensitive data in payload: Base64 is reversible encoding that anyone can decode

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;
};

JWKS (JSON Web Key Set)#

JWKS is a JSON document containing public keys used to verify JWT signatures, typically served at /.well-known/jwks.json. OAuth2 and OpenID Connect providers publish their public keys this way 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;
};

A few guardrails keep key rotation from silently breaking verification:

• Cache JWKS but implement automatic refresh (a cache that never refreshes fails every signature check after the provider rotates keys)
• Always verify the kid (Key ID) matches, and refetch the set when the kid is unknown
• Handle key rotation gracefully

Signing Key / Private Key#

The signing key is the cryptographic private key used to digitally sign JWTs, creating the signature portion that proves authenticity. It must be stored securely and rotated regularly, with access limited to the token issuer.

// 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');
};

Treat the private key itself as the asset that matters most:

• 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+)

Access Tokens vs Refresh Tokens#

Access tokens are short-lived (5-15 minutes) and cover API calls; refresh tokens live longer (7 days) and exist to fetch new access tokens.

Store each one differently:

• 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;
    }
  }
}

Rotate refresh tokens on every use, so a single compromise doesn’t stay valid indefinitely.

Bearer Tokens vs API Keys#

Bearer tokens are dynamic and short-lived, part of the OAuth2/JWT ecosystem; API keys are static, long-lived, and a simpler authentication mechanism.

The choice usually follows the caller:

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

// 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#

Zero Trust runs on one principle: never trust, always verify. It covers identity, device, network, application, and data verification as one continuous check.

Teams usually work through four 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

It runs as a program spanning teams: identity, device posture, and segmentation sit with different owners, and the sequencing of those four phases sets the timeline.

// 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)#

ZTNA replaces the traditional VPN with microsegmentation, giving application-specific access instead of full network reachability once a client connects.

It comes in two flavors:

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

Zscaler, Palo Alto Prisma, and Cloudflare Access lead the vendor field.

SASE (Secure Access Service Edge)#

SASE combines SD-WAN, ZTNA, CASB, FWaaS, and SWG into one cloud-native security platform that merges networking and security. Consolidating on one vendor removes integration work between the components. It also concentrates vendor risk in a single control plane.

Web Security Headers#

HSTS (HTTP Strict Transport Security)#

HSTS forces HTTPS for a specified duration, using a header like Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.

Roll it out in stages, starting with a short max-age before the final long-duration policy:

# 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;

Chrome, Firefox, and Edge also maintain hardcoded preload lists of HSTS domains.

CSP (Content Security Policy)#

CSP prevents XSS and injection attacks by controlling what resources a page can load.

A progressive rollout avoids breaking production on day one:

# 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:

The common pitfall is breaking third-party scripts, like Google Analytics or chat widgets; always test in report-only mode first.

Certificate Pinning (Deprecated)#

HPKP is deprecated and removed from major browsers, so the header no longer protects anything, and it still carries a self-DOS risk if keys change unexpectedly.

Certificate Transparency (CT) combined with CAA records has taken its place:

; CAA record example
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild ";"
example.com. CAA 0 iodef "mailto:security@example.com"

Access Control Models#

RBAC (Role-Based Access Control)#

RBAC chains users to roles to permissions, and it fits stable organizational structures best.

-- 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)
);

Hierarchical roles and role composition prevent role explosion, avoiding a dedicated role for every permission combination.

ABAC (Attribute-Based Access Control)#

ABAC grants dynamic permissions based on user, resource, environment, and action attributes, the kind of policy that reads like “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;
};

It fits complex, contextual access requirements that static roles can’t model.

IAM (Identity and Access Management)#

IAM covers comprehensive identity lifecycle management: authentication, authorization, administration, and audit.

Major platforms include AWS IAM, Microsoft Entra ID (formerly Azure AD), Okta, and Auth0. The hosted providers price per active user or per monthly active user.

Federation connects multiple identity sources, such as Active Directory or Google Workspace.

Principle of Least Privilege#

The principle of least privilege means granting the minimum necessary permissions, implemented through time-bound access (JIT/JEA) and 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);
};

Removing unused permissions works best as an automatic step driven by usage patterns.

Emerging Standards#

Passkeys (FIDO2/WebAuthn)#

Passkeys enable passwordless authentication using device-native biometrics or PINs. Apple, Google, and Microsoft support them natively, syncing credentials through their respective password managers.

// 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;
};

FIDO2 Components#

WebAuthn is the W3C standard implemented by current Chrome, Safari, Firefox, and Edge; CTAP2 is the communication protocol between the platform and the authenticators.

Authenticators come in two types:

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

DPoP (Demonstration of Proof of Possession)#

DPoP binds OAuth2 tokens to the client’s private key to prevent token theft and replay; it’s specified in RFC 9449 (2023) and still in an early adoption phase.

Here’s how a client proves possession of that 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#

Basic Authentication sends a Base64-encoded username:password pair in the Authorization header on every request; that’s low security on its own, so HTTPS is mandatory.

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

It still fits simple scripts and legacy system integrations when HTTPS is enforced.

Digest Authentication#

Digest Authentication is obsolete: it relies on broken MD5 hashing, so it belongs only in legacy system support, never in a new system. Replace it with OAuth2/OIDC or, at minimum, a modern token-based scheme.

Mutual TLS (mTLS)#

mTLS means both client and server present certificates, which fits service-to-service communication, IoT devices, and 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)
  });
};

The operational overhead includes certificate management, rotation, and revocation lists; a service mesh with automatic mTLS (Istio, Linkerd) is the modern alternative that absorbs it.

Metrics to Track#

• Failed authentication rate
• MFA adoption for admin accounts
• Password reset frequency (should drop with passwordless rollout)
• Token refresh rate and failures
• Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR) for security incidents
• Privilege escalation attempts and unusual authentication patterns (geographic, time-based)
• Login success rate and authentication abandonment rate
• Support ticket volume tied to authentication issues
• Biometric authentication failure rate

Where Authentication Systems Break#

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 and Operational 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
• 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
• 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

Process Improvements#

• Security Training First: Train the team before implementing
• Incremental Rollout: Use feature flags for gradual authentication method rollouts
• Testing & Friction Monitoring: Test authentication flows for user experience impact, then keep measuring and optimizing friction after launch
• Regular Drills: Conduct security incident response drills quarterly

Authentication infrastructure is worth buying rather than building in-house, and regulatory requirements (SOX, HIPAA, GDPR) belong in the architecture decision from the start, since they constrain retention, logging, and factor choice.

These defaults hold until an enterprise buyer’s identity provider speaks only SAML, the device fleet cannot register platform authenticators, or a regulator names a specific control.

References#

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