Comprehensive Authentication Guide#
A practitioner’s reference for authentication security — protocols, mechanisms, vulnerabilities, exploitation techniques, and defense strategies. Covers traditional and modern authentication methods from enterprise to web applications. Compiled from 55 research sources.
Table of Contents#
- Fundamentals
- Password-Based Authentication
- Multi-Factor Authentication (MFA)
- OAuth 2.0 & OpenID Connect
- SAML & Enterprise SSO
- Modern Authentication (FIDO, WebAuthn, Passkeys)
- JWT Security
- Session Management
- Authentication Bypasses & Attacks
- Implementation Security
- Testing & Verification
1. Fundamentals#
Core Concepts#
| Term | Definition | Security Impact |
|---|
| Authentication (AuthN) | Process of verifying identity claims | Foundation of access control |
| Digital Identity | Unique representation in online context | Basis for authorization decisions |
| Identity Proofing | Binding digital identity to real person | KYC/compliance requirement |
| Session Management | Maintaining state across requests | Critical for web application security |
| Non-Human Identity (NHI) | API keys, OAuth tokens, service accounts | Path of least resistance for attackers — not bound by MFA or IP restrictions |
Authentication Factors#
| Factor Type | Examples | Vulnerability Classes |
|---|
| Something You Know | Passwords, PINs, security questions | Brute force, credential stuffing, social engineering |
| Something You Have | Hardware tokens, mobile apps, SMS | SIM swapping, device theft, malware |
| Something You Are | Biometrics (fingerprint, face, voice) | Spoofing, template theft, privacy concerns |
2. Password-Based Authentication#
Password Strength Requirements#
| Requirement | NIST SP800-63B Standard | Security Rationale |
|---|
| Minimum Length | 8 chars (with MFA), 14+ (without MFA) | Increases brute force difficulty |
| Maximum Length | At least 64 characters | Prevents artificial length limits |
| Character Composition | No mandatory complexity rules | Avoid predictable patterns |
| Dictionary Checking | Block common passwords | Prevent credential stuffing |
Common Password Vulnerabilities#
ATTACK VECTORS:
├── Credential Stuffing
│ ├── Breach databases (HaveIBeenPwned)
│ ├── Password reuse across sites
│ └── Automated login attempts
├── Brute Force Attacks
│ ├── Dictionary attacks
│ ├── Rule-based mutations
│ └── Hybrid attacks
└── Password Reset Flows
├── Weak reset tokens
├── Token reuse vulnerabilities
├── Account enumeration
└── Email interception for ATO (Post SMTP CVE-2025-24000 — Subscriber+ reads reset emails via broken REST API permissions)
Secure Implementation Patterns#
| Security Control | Implementation | Bypass Techniques |
|---|
| Rate Limiting | Progressive delays, account lockouts | IP rotation, distributed attacks |
| CAPTCHA | Human verification challenges | OCR bypass, solving services |
| Password Hashing | bcrypt, scrypt, Argon2 | Rainbow tables (if salts weak) |
| Breach Detection | Monitor for credential exposure | Private/corporate breaches |
| REST API Auth | Role-based permission callbacks (not just is_user_logged_in()) | Subscriber-level access to admin endpoints |
3. Multi-Factor Authentication (MFA)#
MFA Implementation Types#
| Method | Security Level | User Experience | Attack Vectors |
|---|
| SMS OTP | Low | High friction | SIM swapping, SS7 attacks |
| TOTP Apps | Medium | Medium friction | Device compromise, social engineering |
| Push Notifications | Medium-High | Low friction | MFA fatigue, device takeover |
| Hardware Tokens | High | Medium friction | Physical theft, supply chain |
| Biometrics | High | Low friction | Spoofing, template extraction |
| Passwordless (FastPass/FIDO2) | Very High | Low friction | Device compromise (Okta Terrify), endpoint proxy |
MFA Bypass Techniques#
BYPASS METHODS:
├── Social Engineering
│ ├── MFA fatigue (push spam)
│ ├── Vishing (voice phishing)
│ └── SIM swapping
├── Technical Bypasses
│ ├── Session fixation
│ ├── MFA enrollment abuse
│ ├── Backup code exploitation
│ └── Race conditions
├── Adversary-in-the-Middle (AiTM)
│ ├── Real-time phishing (Evilginx, Tycoon 2FA, Evilproxy, Mamba 2FA)
│ ├── Session cookie interception and replay
│ ├── Token replay
│ └── Cloudflare Workers as transparent proxy (IOActive research)
├── Authentication Downgrade Attacks
│ ├── JSON config manipulation — flip FIDO2 isDefault:false, push isDefault:true
│ ├── CSS injection to hide passkey/FIDO2 UI options
│ ├── Browser User-Agent spoofing (e.g., Safari on Windows) to trigger Entra ID fallback
│ └── WebAuthn immediate mediation abuse for non-WebAuthn fallback steering
├── Conditional Access Policy (CAP) Bypasses
│ ├── IP whitelisting bypass (VPN, Zscaler pivoting)
│ ├── Geo-whitelisting bypass (VPN/location spoofing)
│ ├── User-agent whitelisting bypass (custom UA strings)
│ ├── Cloud tooling bypasses (ROADtools, BloodHound, AADInternals)
│ └── Non-MFA hosts (legacy protocols, password reset portals)
└── Machine-Based Attacks
├── Session token theft from memory (Cobalt Strike BOFs)
├── OTP keylogging / seed QR code theft
├── Okta Terrify — extract passwordless keys from compromised endpoint
└── Stolen/unlocked devices
Phishing-as-a-Service (PhaaS) Kits#
| Kit | Technique | Detection Evasion |
|---|
| Evilginx | Open-source reverse proxy AiTM | Default LetsEncrypt certs, 8-char URL paths, TLS fingerprint differs from target |
| Tycoon 2FA | PhaaS MFA bypass | Dynamically obfuscated JS, phishing URL gating, IP/UA filtering |
| Evilproxy | PhaaS MFA bypass | Templates for popular targets, bot detection |
| Mamba 2FA | PhaaS MFA bypass | Anti-crawler delays, redirect to benign pages |
| Cloudflare Workers | Serverless transparent proxy (IOActive PoC) | Zero forensic footprint, trusted CDN IPs, ephemeral execution |
Implementation Security Checklist#
| Control | Verification | Common Mistakes |
|---|
| Enrollment Security | Verify primary auth before MFA setup | Allow MFA changes without re-auth |
| Backup Mechanisms | Secure recovery codes | Weak backup code generation |
| Device Trust | Risk-based authentication | Unlimited device trust |
| Rate Limiting | Throttle MFA attempts | No limits on failed attempts |
| Eliminate Fallbacks | No SMS/TOTP/push if FIDO2 deployed | Mixed-mode policies allow downgrade |
| Audit MFA Logs | Detect new MFA device registration post-compromise | Missing persistence detection |
4. OAuth 2.0 & OpenID Connect#
OAuth 2.0 Flow Types#
| Grant Type | Use Case | Security Considerations |
|---|
| Authorization Code | Server-side web apps | Most secure, requires PKCE for SPAs |
| Authorization Code + PKCE | Public clients, SPAs | Prevents authorization code injection |
| Implicit | Legacy SPAs | Deprecated, token in URL fragment |
| Client Credentials | Service-to-service | No user context, secure storage critical |
| Device Code | IoT/limited input devices | Phishing risk during user approval |
Common OAuth Vulnerabilities#
| Vulnerability | Attack Vector | Mitigation |
|---|
| Authorization Code Interception | Redirect URI manipulation | Strict redirect validation |
| State Parameter Missing | CSRF attacks | Cryptographically strong state |
| Scope Escalation | Privilege elevation | Minimal scope principle |
| Client Impersonation | Stolen client credentials | Client authentication |
| OAuth Parameter Injection | Inject arbitrary params (redirect_uri, scope) into auth flow | Input sanitization (Okta auth0/nextjs-auth0 vuln) |
| Implicit Flow Token Theft | Access token in URL fragment, referer leakage | Migrate to Authorization Code + PKCE |
| CSRF via Missing State | Attacker injects own authorization code into victim session | State parameter enforcement |
| Redirect URI Bypass | Pattern-matching bypass (%2f%2f, %5c%5c, %3F, %23, port injection) | Exact string match, no wildcards |
| Credential Leakage via Referer | Authorization code or token in Referer header to third-party content | No third-party resources on callback pages |
| Non-Human Identity Abuse | Compromised OAuth tokens with overly broad scopes, null expiry refresh tokens | Scope minimization, token rotation, vendor vetting |
Dynamic Client Registration SSRF (PortSwigger Research)#
SSRF ATTACK SURFACE VIA DYNAMIC REGISTRATION:
├── logo_uri — Server fetches logo image → SSRF on /authorize
├── jwks_uri — Server fetches JWK set for client_assertion validation → Blind SSRF
├── sector_identifier_uri — Server fetches redirect_uri list → SSRF on registration or authorization
├── request_uris — Whitelisted request_uri values → SSRF on /authorize via request_uri param
│ (Even without dynamic registration, test request_uri on /authorize directly)
└── Discovery: GET /.well-known/openid-configuration
├── registration_endpoint
├── request_uri_parameter_supported
└── require_request_uri_registration
CVE-2021-26715: SSRF via logo_uri in MITREid Connect
ForgeRock OpenAM: SSRF via request_uri + redirect_uri Session Poisoning
OAuth Security Implementation#
SECURITY CONTROLS:
├── Authorization Server
│ ├── Strict redirect URI validation (exact match, no wildcards)
│ ├── State parameter enforcement
│ ├── PKCE for public clients
│ ├── Short-lived authorization codes (single use)
│ └── Disable Dynamic Client Registration if not needed
├── Resource Server
│ ├── Token introspection
│ ├── Scope validation
│ ├── Audience verification
│ └── Rate limiting
├── Client Application
│ ├── Secure token storage (never in browser history/URL)
│ ├── Token refresh handling with expiry
│ ├── CSRF protection via state parameter
│ ├── PKCE code_verifier/code_challenge
│ └── TLS everywhere
└── Non-Human Identity Governance
├── Monitor OAuth app registrations and consent grants
├── Audit token scopes vs actual usage
├── Enforce refresh token expiry (no null expiry)
└── Vendor breach monitoring for third-party OAuth apps
OAuth Pentesting Checklist (Authorization Code Grant)#
| Test Case | What to Check | Impact |
|---|
| Redirect URI Validation | Change redirect_uri to attacker domain, test pattern bypasses | Token/code theft |
| State Parameter | Remove or reuse state, test CSRF | Account hijacking |
| Code Reuse | Replay authorization code | Session hijacking |
| Client Secret Exposure | Check JS source, mobile app binaries | Full OAuth flow compromise |
| Scope Manipulation | Request elevated scopes | Privilege escalation |
| Token in URL/History | Check if access_token appears in URL fragment or browser history | Token theft |
| Referer Leakage | Check callback pages for third-party resource loads | Code/token leakage |
| request_uri SSRF | Supply attacker URL in request_uri param on /authorize | Server-side request forgery |
5. SAML & Enterprise SSO#
SAML Attack Surface#
| Component | Attack Vectors | Security Controls |
|---|
| Identity Provider (IdP) | XML signature bypass, SAML injection | Strong XML validation, signature verification |
| Service Provider (SP) | Assertion replay, audience restriction bypass, parser differential exploitation | Strict temporal/audience checks, single XML parser |
| SAML Assertions | XXE, signature wrapping (XSW), attribute pollution | Secure XML parsing, validation |
| Metadata | Metadata spoofing, certificate substitution | Out-of-band verification |
| FortiCloud SSO | Crafted SAMLResponse to /remote/saml/login (CVE-2025-59718) | Disable FortiCloud SSO until patched |
XML Signature Wrapping (XSW) Attacks — Deep Dive#
XSW ATTACK TAXONOMY:
├── Classic XSW
│ ├── Move signed element, inject forged element in original location
│ ├── Application processes forged data, signature validates against hidden original
│ └── 8+ documented XSW variants in USENIX "On Breaking SAML" research
├── Parser Differential Exploits
│ ├── ruby-saml: REXML + Nokogiri dual parser → different XPath results
│ │ ├── CVE-2025-25291 / CVE-2025-25292 (ruby-saml < 1.18.0)
│ │ ├── CVE-2024-45409 (ruby-saml signature bypass by ahacker1)
│ │ └── Exploited in GitLab — sign in as any user with single valid signature
│ ├── Attribute pollution — parser-specific attribute handling differences
│ ├── REXML namespace confusion — without DTDs
│ └── Void Canonicalization — novel technique (PortSwigger "The Fragile Lock")
├── Signature Exclusion / Comment Injection
│ ├── Removing Signature element entirely
│ ├── XML comment injection between signature elements
│ └── Bypassing signature validation in libraries that don't enforce presence
├── Encrypted Assertion Bypass
│ ├── GitHub Enterprise: signature extracted pre-decryption, inner assertion signature never validated
│ │ ├── CVE-2024-4985 / CVE-2024-9487
│ │ └── Forge assertion inside encrypted envelope, only outer response signature checked
│ └── samlify (Node.js): CVE-2025-47949 — Signature Wrapping with unsigned assertion extraction
└── Improper Cryptographic Signature Verification
├── FortiGate FortiCloud SSO: CVE-2025-59718 / CVE-2025-59719 (CVSS 9.8)
│ ├── SAML response signature not validated → forged SAMLResponse grants super_admin
│ ├── Endpoint: POST /remote/saml/login
│ ├── Actively exploited in the wild (Arctic Wolf, CISA KEV)
│ └── Affects FortiOS, FortiProxy, FortiSwitchManager, FortiWeb
└── CWE-347 pattern: system checks temporal claims but skips signature verification
Real-World SAML CVEs#
| CVE | Product | Vulnerability | Impact |
|---|
| CVE-2025-59718 | FortiGate FortiCloud SSO | Missing SAML signature validation | Unauthenticated admin access |
| CVE-2025-59719 | FortiGate FortiCloud SSO | Related bypass variant | Unauthenticated admin access |
| CVE-2025-25291 | ruby-saml | Parser differential (REXML/Nokogiri) | Sign in as any user |
| CVE-2025-25292 | ruby-saml | Parser differential (REXML/Nokogiri) | Sign in as any user |
| CVE-2024-45409 | ruby-saml | Signature bypass | Authentication bypass |
| CVE-2024-4985 | GitHub Enterprise | Encrypted assertion signature skip | SAML SSO bypass |
| CVE-2024-9487 | GitHub Enterprise | Follow-up encrypted assertion fix | SAML SSO bypass |
| CVE-2025-47949 | samlify (Node.js) | Signature Wrapping — unsigned assertion consumed | Authentication bypass, user impersonation |
SAML Bug Hunting Methodology#
SAML TESTING WORKFLOW (using SAML Raider):
├── Setup
│ ├── Install SAML Raider Burp extension
│ ├── Import/clone X.509 certificates
│ └── Capture SAML Response in proxy
├── Signature Wrapping Tests
│ ├── Apply all 8 XSW variants from SAML Raider
│ ├── Test with both signed Response and signed Assertion
│ └── Test with cloned/self-signed certificates
├── Signature Removal
│ ├── Remove Signature element entirely
│ ├── Remove SignatureValue content
│ └── Test if SP accepts unsigned assertions
├── Assertion Manipulation
│ ├── Modify NameID to target user
│ ├── Modify role/group attributes
│ ├── Change audience restriction
│ └── Alter temporal conditions (NotBefore/NotOnOrAfter)
├── XML-Level Attacks
│ ├── XXE injection in SAML Response
│ ├── XML comment injection in NameID
│ ├── DTD-based attacks (if not blocked)
│ └── Namespace confusion / attribute pollution
└── Certificate Tests
├── Clone IdP certificate, self-sign assertion
├── Test if SP validates certificate chain
└── Test if SP accepts any valid signature (not just from trusted IdP)
6. Modern Authentication (FIDO, WebAuthn, Passkeys)#
FIDO2/WebAuthn Architecture#
| Component | Function | Security Properties |
|---|
| Authenticator | Private key storage, user verification | Hardware-backed, phishing-resistant |
| Client (Browser) | Protocol handling, user interaction | Sandboxed execution, origin binding |
| Relying Party | Credential management, verification | Challenge-response validation |
| FIDO Server | Registration/authentication logic | Cryptographic verification |
Passkey Types and Security Properties#
| Type | Storage | Security Level | Enterprise Suitability |
|---|
| Device-Bound (Hardware Key) | YubiKey, security key hardware | Highest — non-exportable, hardware-backed | Recommended for enterprise |
| Synced (Multi-Device) | iCloud Keychain, Google Password Manager | Medium — inherits cloud account risk | Consumer use only; not recommended for enterprise |
Synced Passkey Risks#
SYNCED PASSKEY ATTACK SURFACE:
├── Cloud Account Compromise
│ ├── iCloud/Google account takeover → all synced passkeys compromised
│ ├── Recovery workflow abuse → authorize new device with stolen credentials
│ └── Personal cloud account on corporate device → passkeys leak to personal devices
├── Authentication Downgrade
│ ├── AiTM proxy spoofs unsupported browser → Entra ID disables passkey option
│ ├── User steered to SMS/OTP/push → captured by proxy
│ └── WebAuthn immediate mediation abused to offer weak fallback
├── Browser Extension Attacks
│ ├── webAuthenticationProxy API — intercept navigator.credentials.create()/get()
│ ├── Content script DOM injection — manipulate passkey UI elements
│ ├── DOM-based extension clickjacking — trigger autofill and exfiltration
│ └── Malicious extension forces password fallback or re-registration
└── Help Desk Social Engineering
└── Recovery process = real control point attackers target
WebAuthn Security Benefits#
| Protection | Traditional Auth | WebAuthn |
|---|
| Phishing Resistance | Credentials reusable | Origin binding prevents cross-site use |
| Credential Theft | Server breaches expose passwords | Public key only stored server-side |
| Replay Attacks | Static credentials | Cryptographic challenges with freshness |
| Man-in-the-Middle | Credentials interceptable | Origin verification blocks proxy attacks |
Enterprise Passkey Deployment Guidance#
| Area | Recommendation | Rationale |
|---|
| Credential Type | Device-bound only (hardware security keys) | Non-exportable, hardware-backed, inventoriable |
| Fallback Methods | Eliminate all (SMS, TOTP, push, email) | Weakest method = real security level |
| Browser Extensions | Allowlist only; block webAuthenticationProxy permission | Prevent WebAuthn API interception |
| Attestation | Capture device model and assurance at registration | Reject unrecognized authenticators |
| Recovery | Hardware key-based reproofing only | No help desk/email-based recovery |
| Session Binding | Tie sessions to device context, not just initial auth | Prevent portable session cookie theft |
Cloudflare FIDO2 Deployment Case Study#
CLOUDFLARE ROLLOUT TIMELINE:
├── 2018: Distributed YubiKey 5 Nano + YubiKey 5 NFC to all employees
├── 2020: Selective enforcement via Cloudflare Access (Zero Trust proxy)
│ ├── OAuth2 integration with IdP, enforce "swk" (security key) AMR value
│ └── Incremental rollout — one service at a time
├── Feb 2021: Full enforcement — disabled all TOTP/SMS
│ ├── Triggered by social engineering phone calls to employees
│ └── Offline recovery process for lost keys (distribute 2 keys per employee)
├── SSH via Cloudflare Tunnel: cloudflared + Access policies enforce FIDO2 for SSH
└── Result: Zero successful phishing attacks post-deployment
7. JWT Security#
JWT Attack Vectors#
| Vulnerability | Technique | Real-World Example |
|---|
| Algorithm Confusion (alg=none) | Set JWT header alg to “none”, remove signature | Classic JWT bypass |
| Missing Signature Verification | Server decodes JWT but never checks signature | Convoy KVM CVE-2026-33746 (CVSS 9.8) — JWTService::decode() missing SignedWith constraint |
| JWE Encryption Mix-Up | Encrypt unsigned PlainJWT with server’s RSA public key; server decrypts and accepts without signature check | pac4j-jwt CVE-2026-29000 — forge admin tokens with public key only |
| Hardcoded JWT Secrets | Static/weak signing secrets | Zendesk Android SDK — hardcoded secret “987sdasdlkjlakdjf” + sequential IDs → mass ATO |
| Weak Cookie Auth Tags | Brute-forceable authentication tags on session cookies | Auth0-PHP SDK CVE-2025-47275 (CVSS 9.1) — brute force CookieStore auth tags |
| Default Signing Keys | Predictable or default JWT signing keys | Apache StreamPipes CVE-2025-47411 |
JWT Security Checklist#
| Control | Implementation | Common Mistakes |
|---|
| Algorithm Enforcement | Whitelist allowed algorithms server-side | Accept alg from JWT header without validation |
| Signature Verification | Always verify before trusting claims | Check only expiration (Convoy pattern) |
| Key Management | Rotate secrets, use asymmetric keys | Hardcoded secrets, public key in source |
| Claim Validation | Verify iss, aud, exp, nbf, iat | Trust user-controlled claims |
| JWE Handling | Enforce inner JWT must be signed, not PlainJWT | Accept PlainJWT inside JWE (pac4j-jwt pattern) |
8. Session Management#
Session Security Requirements#
| Property | Implementation | Attack Prevention |
|---|
| Uniqueness | Cryptographically random IDs | Session prediction |
| Unpredictability | High entropy (128+ bits) | Brute force guessing |
| Secure Transmission | HTTPS only, Secure flag | Network interception |
| Proper Expiration | Absolute/idle timeouts | Session hijacking |
| Device Binding | Tie session to device context/posture | Portable cookie theft via AiTM |
Session Attack Vectors#
SESSION ATTACKS:
├── Session Hijacking
│ ├── Network sniffing
│ ├── Cross-site scripting (XSS)
│ ├── Malware/browser compromise
│ └── AiTM reverse proxy cookie interception (Evilginx, Tycoon 2FA)
├── Session Fixation
│ ├── Pre-authentication session reuse
│ ├── URL-based session ID
│ └── Missing session regeneration
├── Session Timing
│ ├── Concurrent sessions
│ ├── Logout handling
│ └── Session timeout bypass
└── Session Token Portability
├── Stolen session cookies replayed from different device/IP
├── Impossible travel detection evasion
└── Post-compromise MFA device registration for persistence
9. Authentication Bypasses & Attacks#
Business Logic Bypasses#
| Bypass Type | Technique | Testing Approach |
|---|
| Direct Access | URL manipulation | Forced browsing, parameter tampering |
| State Manipulation | Session/workflow bypass | Multi-step process analysis |
| Role Confusion | Privilege escalation | Horizontal/vertical privesc testing |
| Reset Abuse | Account takeover | Password reset flow analysis |
| Middleware-Only Auth | Next.js CVE-2025-29927 — x-middleware-subrequest header bypass | Verify auth in page routes/API routes, not just middleware |
Technical Bypasses#
COMMON BYPASS PATTERNS:
├── Authentication Logic Flaws
│ ├── Boolean bypass (admin=true)
│ ├── SQL injection in auth queries
│ ├── LDAP injection
│ └── Authentication timing attacks
├── Protocol-Specific Issues
│ ├── JWT manipulation (alg=none, missing signature verification, JWE mix-up)
│ ├── OAuth state bypass / parameter injection
│ ├── SAML signature bypass (XSW, parser differential, encrypted assertion)
│ └── Kerberos attacks (Golden/Silver tickets)
├── Framework-Specific Bypasses
│ ├── Next.js middleware bypass (CVE-2025-29927) — set x-middleware-subrequest header
│ ├── WordPress REST API permission flaws (Post SMTP CVE-2025-24000)
│ └── Grafana open redirect + CSPT → XSS → account takeover (CVE-2025-6023)
├── Predictable Token Generation
│ ├── Zendesk Android SDK — SHA-1(REDACTED-{AccountID}-{HardcodedSecret}) → zero-click mass ATO
│ ├── Sequential ID enumeration + static secrets
│ └── No rate limiting on token validation endpoints
└── Implementation Weaknesses
├── Default credentials
├── Weak password policies
├── Missing rate limiting
├── Insecure session handling
└── AI-generated code with insufficient input sanitization (Okta nextjs-auth0 OAuth injection)
Real-World Authentication CVEs#
| CVE | Product | Type | CVSS | Impact |
|---|
| CVE-2025-59718 | FortiGate | SAML signature bypass | 9.8 | Unauthenticated admin access (actively exploited, CISA KEV) |
| CVE-2026-33746 | Convoy KVM | JWT signature skip | 9.8 | Full account takeover including admin |
| CVE-2026-29000 | pac4j-jwt | JWE encryption mix-up | Critical | Forge admin tokens with RSA public key |
| CVE-2025-47275 | Auth0-PHP SDK | Cookie auth tag brute force | 9.1 | Unauthorized account access |
| CVE-2025-47949 | samlify | SAML Signature Wrapping | Critical | Authentication bypass, user impersonation |
| CVE-2025-29927 | Next.js | Middleware auth bypass | Critical | Authorization bypass via internal header |
| CVE-2025-25291/92 | ruby-saml | Parser differential | Critical | Sign in as any user (GitLab exploitable) |
| CVE-2024-4985 | GitHub Enterprise | Encrypted assertion bypass | Critical | SAML SSO bypass |
| CVE-2025-24000 | Post SMTP (WordPress) | Broken access control | High | Subscriber reads admin emails → ATO |
| CVE-2025-6023 | Grafana | Open redirect + CSPT → XSS | High | Full account takeover |
| CVE-2025-47411 | Apache StreamPipes | JWT default key | High | Admin privilege escalation |
10. Implementation Security#
Secure Coding Practices#
| Security Control | Implementation Pattern | Common Mistakes |
|---|
| Input Validation | Whitelist validation | Blacklist approaches |
| Cryptography | Industry-standard algorithms | Custom/weak crypto |
| Error Handling | Generic error messages | Information disclosure |
| Logging | Security event logging | Sensitive data in logs |
| AI Code Review | Manual security audit of AI-generated auth code | AI “slop” — functional but insecure patterns (Okta nextjs-auth0 case) |
Framework-Specific Guidance#
FRAMEWORK SECURITY:
├── Spring Security
│ ├── Method-level security
│ ├── CSRF protection
│ └── Session management
├── ASP.NET Identity
│ ├── Identity configuration
│ ├── Cookie authentication
│ └── External providers
├── Express.js/Passport
│ ├── Strategy configuration
│ ├── Session security
│ └── Middleware order
├── Next.js
│ ├── Never rely solely on middleware for auth (CVE-2025-29927)
│ ├── Verify auth in Server Components, Page Routes, and API Routes
│ └── Block x-middleware-subrequest header from external requests
├── WordPress
│ ├── REST API permission callbacks must check capabilities, not just login status
│ ├── Audit plugins exposing sensitive data via REST endpoints
│ └── Post SMTP pattern: get_logs_permission() → is_user_logged_in() is insufficient
└── Node.js SAML (samlify)
├── Upgrade to >= 2.10.0 to fix Signature Wrapping (CVE-2025-47949)
└── Use single XML parser for validation + processing
Defensive Architecture Principles#
| Principle | Implementation | Why It Matters |
|---|
| Eliminate Weak Fallbacks | Remove SMS/TOTP/push when FIDO2 is available | Weakest method = real security posture |
| Single XML Parser | Use one parser for signature validation and data extraction | Parser differentials enable XSW bypasses |
| Defense in Depth for Auth | Auth check at middleware AND route/controller level | Single-layer bypass (Next.js pattern) |
| Hardware-Rooted Trust | Device-bound credentials with attestation | Prevents credential export and synced passkey risks |
| Continuous Auth | Re-evaluate posture on device/location/behavior changes | A login is not a permanent hall pass |
11. Testing & Verification#
Authentication Testing Methodology#
| Phase | Focus Areas | Tools/Techniques |
|---|
| Reconnaissance | Authentication mechanisms, IdP discovery | Manual analysis, Burp Suite, /.well-known/openid-configuration |
| Enumeration | User accounts, endpoints, registration endpoints | Username enumeration, timing attacks, /connect/register |
| Attack Execution | Credential attacks, bypasses, AiTM | Hydra, Evilginx, custom scripts |
| Post-Exploitation | Session security, privilege escalation, persistence | Manual testing, token analysis, MFA device registration |
TESTING ARSENAL:
├── Credential Attacks
│ ├── Hydra (brute force)
│ ├── Medusa (parallel login)
│ ├── Patator (modular brute forcer)
│ └── MFASweep (CAP misconfiguration discovery)
├── OAuth/JWT Testing
│ ├── jwt_tool (JWT manipulation)
│ ├── Burp JWT Editor
│ ├── request_uri SSRF testing via /authorize
│ └── Dynamic Client Registration fuzzing
├── SAML Testing
│ ├── SAML Raider (Burp extension) — 8 XSW variants, cert cloning, assertion editing
│ ├── SAMLReq (CLI tool)
│ ├── Manual XML manipulation
│ └── Parser differential toolkit (PortSwigger "The Fragile Lock")
├── MFA Bypass Testing
│ ├── Evilginx (AiTM reverse proxy)
│ ├── Cloudflare Workers PoC (IOActive auth downgrade)
│ └── ROADtools / AADInternals (Azure AD CAP bypass)
└── Passkey / WebAuthn Testing
├── Browser extension permission auditing (webAuthenticationProxy)
├── Downgrade scenario simulation (UA spoofing, CSS injection)
└── Device-bound vs synced credential policy verification
Security Assessment Checklist#
| Category | Verification Points | Risk Level |
|---|
| Password Security | Strength requirements, storage, reset flows | High |
| Multi-Factor Auth | Implementation, bypass resistance, fallback elimination | Critical |
| Session Management | Generation, transmission, expiration, device binding | High |
| OAuth Protocol Security | Redirect validation, state, PKCE, dynamic registration | Critical |
| SAML Protocol Security | Signature validation, single parser, XSW resistance | Critical |
| JWT Security | Algorithm enforcement, signature verification, key management | Critical |
| WebAuthn/Passkeys | Device-bound enforcement, no fallback, attestation | High |
| Framework Auth | Auth at every layer, not just middleware | High |
| Business Logic | Authentication flows, error handling, race conditions | Medium |
Key Takeaways#
- Defense in Depth: Combine multiple authentication factors and security controls — but eliminate weak fallbacks that attackers will force
- Protocol Compliance: Follow established standards (NIST, OWASP, OAuth specs, FIDO2) and keep libraries updated
- Single Parser Principle: Never use dual XML parsers for SAML signature validation and data extraction
- Phishing-Resistant MFA: Deploy device-bound FIDO2/WebAuthn; synced passkeys are insufficient for enterprise
- JWT Rigor: Always enforce algorithm whitelists, verify signatures before trusting claims, and reject PlainJWT inside JWE
- Implementation Quality: Secure coding practices prevent logic bypasses — audit AI-generated auth code carefully
- Continuous Monitoring: Log authentication events, audit MFA device registrations, detect impossible travel and session anomalies
- Test Real Attack Paths: Use AiTM tools, XSW variants, and downgrade scenarios in security assessments — not just credential brute force
This guide compiles practical authentication security knowledge from 55 research sources. Keep updated with emerging authentication technologies and attack techniques.