Under Pressure
The Expanding Auth Surface
The surface area of identity and authentication is expanding in two directions at once. The old foundations (SAML, JWTs, OAuth consent flows, MFA itself) keep producing serious vulnerabilities. And the new frontiers (AI agents, MCP tool chains, CLI-first developer workflows) are introducing entirely new categories of identity risk that most teams haven’t accounted for yet. Both sides are producing exploitable bugs, often at same time, and the blast radius compounds because identity infrastructure is load-bearing for everything else in your stack.
SAML
On one side, the foundations are cracking. Five critical SAML vulnerabilities landed in four months across Citrix, Cisco, Ruby-SAML, Authentik, and OneUptime. The Citrix NetScaler bug (CVSS 9.3) was actively exploited within days of disclosure, leaking authenticated session IDs to unauthenticated attackers. PortSwigger demonstrated full auth bypass by exploiting the fact that most SAML libraries use two different XML parsers that disagree on just enough to let an attacker through. Two of the five bugs were functionally identical injection flaws discovered independently in separate codebases. That’s the kind of coincidence that tells you the problem is structural, baked into SAML’s XML foundations, and not going away with incremental patches.
JWTs
JWTs have their own persistent weakness. Algorithm confusion attacks exploit a design tension in the spec where tokens carry metadata about how they should be verified. An attacker swaps the alg header from RS256 to HS256, signs with the server’s public RSA key as the HMAC secret, and the forged token passes verification for any identity they choose. This has been documented since 2015 and keeps surfacing in production because the root cause is subtle enough that competent engineers still get it wrong. The fix is straightforward (server-side algorithm allowlists, rejecting unexpected algorithms before any crypto runs), but you have to know to do it, and a lot of teams don’t.
AiTM
Meanwhile, adversary-in-the-middle attacks have turned MFA from a strong defense into a speed bump. Obsidian Security found that 84% of accounts compromised through AiTM already had MFA enabled. The attacker proxies the real login page, relays every keystroke and MFA challenge in real time, and walks away with a valid session cookie. AiTM attacks rose 46% in 2025, driven by Phishing-as-a-Service kits selling the capability as a subscription. And OAuth consent phishing adds another layer to that problem: attackers register a legitimate-looking OAuth app, redirect the victim to the real identity provider, and the victim authenticates through MFA on an actual trusted domain. One click on a consent prompt, and the attacker gets a refresh token that survives password changes and persists until someone explicitly revokes the grant. Detection is hard because the entire flow happens on trusted infrastructure with no spoofed domains.
That’s the old foundations. Now look at the new frontiers.
Agents
AI agents are creating identity problems the industry hasn’t fully internalized yet. The most common pattern in production agentic apps is the agent borrowing the user’s full OAuth session, which means your support agent that only needs to read one invoice holds credentials that could refund every account in the system. The fix requires treating agents as first-class principals with their own scoped tokens, where the agent’s permissions are narrower than the user’s and delegation chains enforce the intersection of both parties’ access. This is the same evolution enterprise security teams went through with microservices a decade ago, just compressed into months instead of years.
MCP
The tools those agents depend on are also under active attack. Between January and February 2026, researchers filed roughly 30 CVEs against MCP servers, clients, and infrastructure. A fake npm package called postmark-mcp built trust over 15 normal versions before adding a single line that BCC’d every outgoing email to an external address. A vulnerability in Smithery.ai could have exposed credentials for 3,000+ hosted MCP servers. Agentic supply chain attacks target runtime rather than build time, and traditional defenses like pinned versions and Dependabot miss the MCP-specific vectors entirely because your agent dynamically loads tools from servers that can change behavior between approval and invocation.
CLI
CLIs are another expanding surface. The rise of AI coding agents means the terminal has become a primary product interface, and the authentication patterns that work for web apps (redirect to login, set a cookie) don’t translate. API keys are simple but can’t express identity or enforce SSO. Token files break in headless environments. The OAuth Device Flow solves both problems by decoupling the browser from the CLI, and it’s becoming the standard for any developer tool that sells to teams.
The defensive layer that consistently performs across all of these attack surfaces is cryptographic.
Passkeys
Passkeys are the clearest answer at the authentication layer. Cryptographic origin binding fuses the credential to a specific domain at the protocol level. During authentication, the browser only presents the passkey to the exact domain it was registered on. An attacker’s AiTM proxy on a different domain gets nothing. NIST now recognizes synced passkeys as phishing-resistant alongside FIDO2 security keys. The caveat that matters: if your system still allows password recovery or SMS fallbacks alongside passkeys, attackers will target those weaker paths, so the entire auth chain needs to be phishing-resistant, not just the strongest method in it.
Permission
At the authorization layer, the patterns that Slack, Notion, and Linear have proven at scale are worth studying. Slack decomposed admin capabilities into granular permission primitives before building custom roles on top. Notion used layered inheritance where workspace settings cascade down with overrides only for exceptions. Linear kept a small fixed role set and pushed flexibility to the edges. The common thread: build granular permission primitives first, scope delegation to specific entities, and let inheritance handle the defaults so most tenants never have to configure anything.
And at the implementation layer, the Node.js authentication guide we published is a reminder that the framework you’re building on gives you a runtime and leaves auth entirely to you. Every decision about sessions versus JWTs, password hashing, rate limiting, CSRF protection, and enterprise SSO is yours to make and yours to maintain through every future CVE.
Identity infrastructure is load-bearing, and when it breaks, the damage compounds. A single SAML vulnerability cascades across every federated service. One JWT misconfiguration lets an attacker forge tokens for any identity in the system. Remember, the blast radius is always wider than the bug itself, and the cost of getting it wrong scales with every service, agent, and user that depends on the identity layer you chose to build or chose to outsource.
✌🏽 SR