By synthesizing the OWASP Top 10 (A01 Broken Access Control as the #1 web risk, tested in 94% of applications; A07 Identification and Authentication Failures), SAML SSO bypass research (CVE-2026-3047 in Keycloak, CVE-2025-47949 in samlify, CVE-2025-59718 in FortiCloud), OAuth 2.0/OIDC attack chain analysis, passkey/WebAuthn deployment census data, ReBAC/OpenFGA literature, service mesh mTLS authentication, and microservice authz research, the following 50 can be compiled. owasp

SAML & SSO Protocol Security

1. SAML signature wrapping attacks — Attackers insert a forged assertion into a legitimately signed SAML response; the SP validates the original signature but processes the attacker’s assertion. CVE-2025-47949 in samlify (CVSS 9.9) demonstrated complete authentication bypass including admin impersonation. csoonline
2. SAML parser differential attacks — XML parser discrepancies between IdP and SP allow signature wrapping to succeed. GitHub’s 2025 disclosure in ruby-saml showed that parser differentials enable forging any user identity. github
3. SAML XML canonicalization ambiguity — XML canonicalization (C14N) differences between signer and verifier allow an attacker to modify signed content while preserving signature validity. pt.slideshare
4. Disabled SAML client bypass — CVE-2026-3047 in Keycloak showed that disabled SAML clients configured as IdP-initiated broker landing targets can still establish SSO sessions, granting access to all enabled clients without re-authentication. sentinelone
5. SAML assertion replay across SPs — A SAML assertion valid for one service provider can be replayed against another SP that trusts the same IdP; audience restriction enforcement is inconsistently implemented. guptadeepak
6. SAML response injection via unvalidated issuer — CVE-2025-59718 in FortiCloud allowed unauthenticated attackers to craft a SAMLResponse claiming to be from sso.forticloud.com with super_admin identity; signature validation was absent. picussecurity
7. IdP-initiated SSO without forced re-authentication — IdP-initiated flows skip the user authentication step entirely; any attacker with IdP session access can initiate SSO to any connected SP. sentinelone
8. SAML X.509 certificate trust chain manipulation — Service providers that accept self-signed IdP certificates or fail to validate certificate chains are vulnerable to assertion forgery via attacker-controlled certificates. pt.slideshare

OAuth 2.0 Security

1. redirect_uri validation bypass via path traversal — Attackers craft redirect_uri values with path traversal or encoding tricks (%2e%2e, Unicode normalization) to intercept authorization codes; CVE-2026-16336 in Trino demonstrated this. basefortify
2. Authorization code theft via open redirect — An open redirect in the OIDC provider’s endpoints allows an authenticated user to steal OAuth 2.0 authorization codes by redirecting the callback to an attacker-controlled domain. github
3. iss + sub claim confusion — When multiple IdPs issue tokens, an attacker obtains a token from IdP-A (with iss=IdP-A) and replays it against a service that expects tokens from IdP-B; insufficient iss validation enables the confusion. blogs.jsmon
4. OAuth state parameter omission or predictability — Without a cryptographically random state parameter, CSRF attacks allow an attacker to inject their own authorization code into a victim’s session. decryptiondigest
5. Implicit grant flow token leakage — The deprecated implicit flow (response_type=token) returns access tokens in the URL fragment; these leak via Referer headers, browser history, and proxy logs. decryptiondigest
6. OAuth scope escalation via dynamic consent — Dynamic client registration and consent screens that don’t enforce scope hierarchies allow clients to request scopes beyond their authorization. guptadeepak
7. Authorization code interception via public clients — SPAs and mobile apps cannot securely store client secrets; PKCE mitigates code interception but adoption is inconsistent. blogs.jsmon
8. Refresh token rotation race conditions — Refresh token rotation (RTR) creates a race where concurrent refresh requests yield multiple valid tokens; atomic rotation is not universally implemented. decryptiondigest

OpenID Connect (OIDC)

1. OIDC hybrid flow nonce confusion — The hybrid flow uses both code and id_token; mismatched nonce validation between the two stages allows session fixation. guptadeepak
2. ID token algorithm confusion (RS256 to HS256) — If the IdP uses RS256, an attacker can change the alg header to HS256 and sign with the public key as an HMAC secret; libraries that don’t enforce algorithm pinning are vulnerable. guptadeepak
3. OIDC userinfo endpoint authentication bypass — Access tokens not validated at the userinfo endpoint; an expired or revoked token still returns user claims. decryptiondigest
4. DPoP proof acceptance with embedded private keys — CVE-2026-54431 in liboauth2 showed the DPoP verifier accepted proofs whose JWK header contained private EC key material, violating RFC 9449 Section 4.3. cert
5. JWKS endpoint SSRF — CVE-2026-54430 in liboauth2 showed that the AWS ALB JWT verifier reads kid from the unverified JWT header and appends it to an internal URL without sanitization, enabling SSRF before signature verification. cert
6. OIDC discovery document poisoning — The .well-known/openid-configuration endpoint is cached and trusted; a compromised or MITM’d discovery document redirects all auth flows to attacker-controlled endpoints. guptadeepak

JWT & Token Security

1. JWT alg: none bypass — Tokens with the algorithm set to none are accepted by libraries that don’t explicitly reject unsigned tokens; this remains the most common JWT vulnerability. guptadeepak
2. JWT key ID (kid) injection — The kid header is attacker-controllable; path traversal, SQL injection, or command injection via kid enables server-side exploitation. guptadeepak
3. JWT revocation and blacklisting at scale — Stateless JWTs cannot be revoked without server-side state; blacklisting requires a distributed cache (Redis, Hazelcast) checked on every request, negating the stateless benefit. guptadeepak
4. JWT storage in browser-accessible locations — Storing JWTs in localStorage or sessionStorage exposes them to XSS-driven theft; HttpOnly cookies prevent XSS theft but are vulnerable to CSRF unless SameSite is enforced. naturalspublishing
5. JWT claim tampering without signature verification — Libraries that decode JWTs without verifying signatures allow attackers to modify role, scope, or user ID claims. guptadeepak
6. Long-lived JWT token accumulation — JWTs issued without expiration or with excessively long TTLs accumulate in the wild; no mechanism exists to force token refresh or re-authentication. guptadeepak

Session Management

1. Session fixation in SSO flows — SAML and OIDC flows that don’t rotate session IDs after authentication allow session fixation; the relay state or state parameter is attacker-controllable. owasp
2. Session token theft via XSS — Session cookies without HttpOnly attribute are accessible via JavaScript; even with HttpOnly, session tokens in SPAs using Bearer tokens are exposed to DOM-based XSS. owasp
3. Cross-site request forgery (CSRF) on state-changing endpoints — Despite SameSite cookie defaults, state-changing API endpoints without CSRF tokens remain exploitable; SameSite=None allows cross-site cookie transmission. owasp
4. Concurrent session management — Preventing concurrent logins across devices requires server-side session tracking; this conflicts with stateless JWT architectures and horizontal scaling. owasp
5. Session timeout vs. user experience tradeoff — Short session timeouts improve security but degrade UX; no adaptive timeout mechanism adjusts based on risk signals (device, location, behavior) at scale. owasp
6. Distributed session invalidation — In microservice architectures, logout must propagate across all services; a centralized session store introduces a single point of failure and latency. mdpi

Access Control Models

1. Broken Object Level Authorization (BOLA/IDOR) — APIs expose object IDs directly in URLs; OWASP API Security ranks this #1, with 3.73%+ of tested applications affected; the check must be enforced at the data-access layer, not the controller. owasp
2. Broken Function Level Authorization (BFLA) — Administrative or privileged API endpoints lack function-level access checks; attackers enumerate hidden endpoints via parameter fuzzing and HTTP method overrides. owasp
3. RBAC role explosion and static privilege accumulation — Role-Based Access Control leads to combinatorial role explosion; over time, users accumulate privileges through role assignments that are never revoked. csrc.nist
4. ABAC policy evaluation performance — Attribute-Based Access Control evaluates complex policy rules per request; at high throughput, policy evaluation latency becomes a bottleneck, and policy debugging is NP-hard in the general case. brighttalk
5. ReBAC relationship graph traversal scalability — Relationship-Based Access Control (Google Zanzibar/OpenFGA) traverses relationship tuples to check permissions; deep relationship chains (e.g., “user → group → folder → document → comment”) require graph traversal that does not scale linearly. session-management
6. ReBAC tuple consistency in distributed systems — OpenFGA writes tuples to a centralized store; eventual consistency between the tuple store and application state creates a TOCTOU window where authorization decisions use stale relationship data. session-management
7. Hybrid access control model conflicts — Applications combining RBAC, ABAC, and ReBAC across different layers (API gateway, service mesh, application code) produce conflicting authorization decisions; no formal model resolves cross-layer policy conflicts. manning

Multi-Factor Authentication

1. MFA fatigue (push bombing) — Attackers repeatedly trigger MFA push notifications until the user approves out of frustration or mistake; number-matching mitigates but adoption is incomplete. chs
2. SIM swap bypass of SMS-based MFA — Social engineering of mobile carriers enables SIM swaps that redirect SMS OTPs; NIST deprecated SMS for new systems but legacy adoption persists. chs
3. MFA bypass via OAuth consent phishing — Attackers obtain valid OAuth tokens with sufficient scopes to bypass MFA entirely; the application trusts the IdP’s MFA assertion without re-validating. guptadeepak
4. MFA enrollment race conditions — The window between initial authentication and MFA enrollment allows an attacker who has compromised credentials to enroll their own MFA device before the legitimate user. chs
5. Recovery flow as MFA bypass — Account recovery flows that bypass MFA (email-based reset) are the weakest link; attackers target recovery flows specifically to avoid MFA. corbado

WebAuthn & Passkeys

1. Passkey account recovery without fallback to passwords — If a user loses all synced passkey devices, recovery requires a fallback mechanism; the fallback (email, SMS, or security questions) becomes the new weakest link, defeating passkey’s phishing resistance. thebackenddevelopers.substack
2. Passkey RP ID mismatch across subdomains — The Relying Party ID (e.g., example.com) must be consistent across all subdomains; misconfiguration causes passkey autofill to fail or, worse, to be scoped too broadly, enabling cross-subdomain credential theft. insights.nomadlab
3. Conditional UI mediation timing attacks — Conditional mediation (autofill UI) leaks which credentials are registered on a site via timing side channels; an attacker can enumerate registered passkeys without user interaction. arxiv
4. Enterprise passkey deployment fragmentation — Only 11.3% of scanned sites support passkeys, and 82.3% require JavaScript execution for detection; enterprise deployments face fragmented device management, lack of standardized discovery endpoints (only 12 of 100,000 domains expose .well-known/passkey-endpoints), and inconsistent support across Windows Hello, Apple Platform Authenticator, and Android. arxiv

Several structural themes recur across these 50: the statelessness-vs-revocation tension (JWTs eliminate server-side state but cannot be revoked), the protocol-layer confusion problem (SAML, OAuth, and OIDC each have distinct trust models that are inconsistently enforced across implementations), the authorization-everywhere challenge (access control must be enforced at every object, function, and relationship level with no single enforcement point), and the fallback-as-weakest-link paradox (every strong authentication mechanism requires a recovery fallback that is inherently weaker). corbado