Authentication Trends in 2026: Passkeys, AI Agents, and Edge Auth

What are the major authentication trends in 2026?

The three load-bearing shifts are (1) mainstream passkey adoption replacing passwords and SMS MFA, with 15 billion user accounts now passkey-enabled and Microsoft defaulting new consumer accounts to passkeys (FIDO Alliance⁠); (2) OAuth 2.1 emerging as the baseline for authenticating AI agents — including Model Context Protocol servers, whose 2025-11-25 specification mandates OAuth 2.1 with PKCE and dynamic client registration (MCP⁠); and (3) edge-centric ingress verification, where short-lived JWTs issued by a central identity provider are validated inside the CDN layer before requests ever reach origin. Each section below covers the primary data, the current standard, and concrete TypeScript-first implementation patterns for the matching shift.

The organizing frame throughout is a three-by-three matrix — three principal types (humans, machines, AI agents) crossed with three runtime environments (origin servers, serverless functions, CDN edge) — because most real 2026 design decisions are about which principal you are authenticating and which runtime is doing the verifying. One clarification before the deep dive: "edge authentication" in this article means ingress-layer JWT verification of tokens issued by a central IdP, not a replacement for browser session management — the IdP still owns durable session state and revocation authority.

Key Trends at a Glance

The three shifts below are the load-bearing structure of the rest of the article.

Each row is drawn from primary telemetry or specification, not vendor marketing. The passkey numbers come from the FIDO Alliance's ongoing passkey index and Microsoft's May 2025 security-blog update on default passkey enrollment (FIDO Passkey Index⁠, Microsoft Security Blog⁠). The agent-identity row reflects the MCP authorization specification finalized on 2025-11-25, which codifies OAuth 2.1 with PKCE as the baseline transport (MCP specification⁠). The edge row reflects the Next.js 16 release, which renamed and re-scoped middleware.ts to proxy.ts to make its network-boundary role explicit (Next.js 16 release notes⁠), alongside the now-conventional jose plus Web Crypto toolchain for JWT validation inside Cloudflare Workers and Vercel Edge Functions (SSOJet⁠, Daily Dev Post⁠).

Three caveats up front, because each trend has a failure mode and this article will not pretend otherwise. Passkeys solve phishing but do not solve account recovery, and recovery UX is where most 2026 passkey rollouts still stumble. Agent identity via OAuth 2.1 is the right direction, but token-exchange flows for delegated agent access are not yet uniformly implemented across IdPs. And edge verification buys latency, not authorization — any decision more complex than "is this JWT signed and unexpired" still belongs at the origin or in the IdP. Each deep-dive section below names the caveat alongside the benefit.

Why Authentication Needs to Evolve in 2026

Authentication in 2026 is not a single product problem. It is the intersection of a faster adversary, a new class of non-human caller, tightening regulation across every major jurisdiction, and a performance budget that no longer tolerates an origin round-trip. Each of those forces is moving independently, and each one pushes the same way: away from shared secrets, toward phishing-resistant credentials verified as close to the user as possible.

The forces reshaping authentication

Credential theft is still the dominant initial-access vector. The 2025 Verizon Data Breach Investigations Report is widely quoted as finding "88% of breaches involved stolen credentials", but that figure is scoped specifically to Basic Web Application Attacks; across the full corpus, credential abuse accounts for roughly 22% of initial access vectors (Verizon DBIR 2025⁠). That caveat does not soften the finding — it sharpens it. For the internet-facing apps most readers of this article build, compromised credentials remain the single most common way in. IBM's 2025 X-Force Threat Index reinforces the trend: a 180% increase in phishing emails delivering infostealers measured against a 2023 baseline, with credential theft the outcome in one in three incidents (IBM X-Force 2025⁠).

eCrime moves faster than humans can respond. CrowdStrike's 2026 Global Threat Report puts average eCrime breakout time at 29 minutes, with the fastest observed breakout at 22 seconds. Eighty-two percent of intrusions were malware-free — the attacker logged in with stolen credentials rather than dropping a binary — and the report measured an 89% year-over-year increase in AI-enabled attacks (CrowdStrike 2026⁠). A 29-minute window does not give a SOC time to page a human; it demands authentication that refuses the attack in the first place.

SIM-swap fraud is scaling in the channels MFA still relies on. Cifas, operator of the UK's National Fraud Database, reported roughly 3,000 unauthorised SIM-swap cases in 2024 — a 1,055% year-over-year surge (Cifas⁠). Action Fraud tracks the same phenomenon with a different methodology and reports roughly 2,037 cases for the period; the number you cite depends on the source, but both point the same direction.

Agentic software changes the threat model. Non-human callers with LLM reasoning now sit in front of APIs that assumed an interactive user session, and they do not behave like the CSRF-token-bearing browser clients those APIs were designed for.

Performance expectations have eaten origin auth. Global TTFB budgets now push session verification to the CDN edge. A documented case study reports that moving verification to the edge cut international checkout TTFB from roughly 2 seconds to ~45ms (Daily Dev Post⁠).

Regulation is accelerating phishing-resistant authentication on parallel tracks. In the EU, the NIS2 Directive (EU) 2022/2555⁠ had to be transposed by Member States by 17 October 2024 and applied from 18 October 2024, while DORA Regulation (EU) 2022/2554⁠ reached its application date on 17 January 2025. NIST SP 800-63-4⁠, released July 2025, for the first time formally qualifies syncable passkeys at AAL2. The EU AI Act (Regulation (EU) 2024/1689)⁠ is under phased application, with general application from 2 August 2026. India's RBI Authentication Directions 2025⁠ require compliance by 1 April 2026 with additional cross-border card-not-present validation by 1 October 2026. Singapore's PDPC ruling⁠ requires organisations to cease NRIC-number-based authentication by 31 December 2026, with enforcement from 1 January 2027. The Philippines BSP Circular 1213 (2025)⁠ defines a one-year compliance window, with a derived deadline around 30 June 2026. Under eIDAS 2.0 (Regulation (EU) 2024/1183)⁠, Member States must provide EUDI Wallets within 24 months of the implementing acts — the commonly cited outside date is around 21 November 2026. For financial messaging, SWIFT CSP v2026⁠ ships 26 mandatory plus 6 advisory controls, with Control 2.4 moved from advisory to mandatory. For payment data, PCI DSS 4.0.1⁠ retired v4.0 on 1 January 2025, and v4.0's new requirements became effective 31 March 2025. Cyber insurance sits across all of this: Marsh McLennan's cyber-risk research⁠ consistently ranks MFA as a top insurer-required control.

Federal signal on agent identity. NIST's AI Agent Standards Initiative, announced February 2026, explicitly covers identity, authorization, and compliance for interoperable agents — the first federal standards work to treat agents as a first-class identity tier.

Contrarian callout. Gartner predicts⁠ that 30% of enterprises will consider identity verification unreliable in isolation by 2026, thanks to AI-generated deepfakes. The authentication layer alone is no longer the verification layer.

Foundational concepts, recapped succinctly

OAuth 2.1 versus OpenID Connect. OAuth 2.1 is an authorization framework; OpenID Connect is an identity layer built on top of it. OAuth 2.1⁠ consolidates best-current-practice guidance from RFC 6749 and the various security BCPs into a single spec, with RFC 9700⁠ codifying the OAuth 2.0 Security Best Current Practice that informs it. If your mental model is "OAuth is login", invert it: OAuth delegates access, OIDC carries identity.

JWT, JWS, JWKS in one paragraph. A JSON Web Token is a header, payload, and signature triple. The signature is a JSON Web Signature, produced with an asymmetric algorithm such as RS256, ES256, or EdDSA. Public verification keys are distributed through a JSON Web Key Set hosted at a well-known URL (conventionally /.well-known/jwks.json). Asymmetric signing is what makes edge verification viable: the public key can live in every CDN PoP, while the private key stays in the IdP. Symmetric signing requires the verifier to hold the signing key — a hard non-starter when the verifier is 300+ edge locations you do not want to be breach blast radius.

Session, access, and refresh tokens. A session token represents a logged-in user to your application and is typically an HttpOnly cookie. An access token is a short-lived bearer credential passed to an API to authorize a specific request. A refresh token is a longer-lived credential exchanged at the IdP for a fresh access token when the current one expires, keeping active sessions alive without re-prompting the user.

WebAuthn, FIDO2, passkey. WebAuthn is the W3C Web Authentication API⁠ that lets a browser talk to an authenticator. FIDO2 is the umbrella name for WebAuthn plus the Client to Authenticator Protocol (CTAP) that connects browsers to external authenticators. A passkey⁠ is the branded consumer UX layered on top of WebAuthn and FIDO2 — a discoverable credential, typically synced across a platform vendor's ecosystem, presented through a familiar system-level prompt.

Why these primitives remain load-bearing. The UX above them is changing fast, but the substrate — OAuth 2.1 for delegation, OIDC for identity, JWT/JWKS for portable claims, WebAuthn for origin-bound assertions — is what every trend in the rest of this article composes onto. Agent identity, edge auth, and passkey rollouts all assume these primitives work; they differ mainly in where the verification happens and what the authenticator is.

Trend 1: Passkeys and Passwordless Authentication Go Mainstream

2026 is the year passkeys stopped being a roadmap item and became the default sign-in for a material share of consumer and workforce traffic. The numbers below are bounded to primary sources — FIDO Alliance, the platform vendors themselves, and the specific case studies published on their developer blogs — because the passkey space has an unusually high volume of secondary and tertiary citations that have drifted from their original context.

Passkey adoption data for 2026

Consumer adoption and platform support

The FIDO Alliance reports 15 billion+ user accounts with passwordless access via passkeys⁠, with more than 1 billion passkey activations across consumer platforms. The FIDO Passkey Index (October 2025)⁠ puts account eligibility at 93%, enrollment at 36%, and passkey-completed sign-ins at 26% of the total across participating services. In the same report, passkey sign-ins succeed 93% of the time against 63% for password sign-ins, and complete 73% faster — a median of 8.5 seconds against 31.2 seconds for passwords. Help-desk authentication incidents drop 81% for passkey-enabled populations.

Microsoft made passkeys the default for new consumer accounts in May 2025 and, according to its own security blog, is registering "nearly a million passkeys every day" (Microsoft Security Blog⁠). Consumer awareness has moved in step with the rollout: from 39% in 2023 to 57% in 2025 per the FIDO Alliance Consumer Insights survey (FIDO Alliance⁠).

Platform support is effectively universal on the client side. Every evergreen browser supports WebAuthn and conditional UI; iOS, Android, macOS, and Windows all ship platform authenticators with synced passkey storage (caniuse.com⁠, passkeys.dev⁠).

Vendor case studies

Primary, vendor-published numbers hold up the clearest picture of the business case:

• Google. 800 million accounts use passkeys, with more than 2.5 billion sign-ins to date. Passkey sign-ins succeed 4× more often than password sign-ins, and Google measured a 352% increase in passkey usage after making passkeys the default sign-in option in October 2023 (Google Identity case studies⁠).
• Mercari. 82.5% passkey success rate with sign-in 3.9× faster than SMS OTP — 4.4 seconds against 17 seconds (Google Identity case studies⁠).
• Kayak. 50% reduction in sign-in time after rolling out passkeys (Google Identity case studies⁠).
• Tokyu. Approximately 12× faster sign-in, to 12.2 seconds (web.dev⁠).
• Dashlane. 70% increase in sign-in conversion rate for passkey flows compared with password flows (Google Developers Blog⁠).
• DocuSign. 99% passkey success rate against 76% for passwords, as reported in the FIDO Authenticate 2025 Day 2 recap (FIDO Alliance⁠) and on the DocuSign blog (DocuSign⁠).
• Roblox. 18% of active users adopted passkeys per the FIDO Authenticate 2025 Day 2 recap (FIDO Alliance⁠); Dashlane's Power 20 vault telemetry separately reported 856% year-over-year growth in Roblox passkey credentials stored in Dashlane (Dashlane⁠).
• Air New Zealand. 50% abandonment reduction after introducing passkeys (FIDO Alliance⁠).

Enterprise and workforce adoption

On the workforce side, the FIDO Alliance's State of Passkey Deployment in the Enterprise in the US and UK (February 2025)⁠ found that 87% of surveyed US and UK workforces are deploying passkeys for employee sign-ins. Corbado's separate analysis — secondary and illustrative — reports that organisations with dedicated adoption tooling reach 80%+ enrollment while those without stall at 5–10% (Corbado⁠). Treat the gap between those two numbers as the project-management tax on passkey rollouts, not a ceiling on the technology.

Passwordless beyond passkeys

"Passwordless" in 2026 is a spectrum, not a single method. Magic links are still widely deployed, and social / OIDC federation is the de-facto passwordless consumer path for a large share of sites. Mojoauth's own State of Passwordless 2026 survey⁠ reports that 41% of passwordless implementations still use magic links — attribute that number to mojoauth's survey, not to the industry at large. In practice, "passwordless" in enterprise contexts now means "passkey-first with a fallback", and the interesting design question has shifted from "should we support passkeys" to "what is the recovery path when a passkey is not present".

Why passkeys outperform passwords and legacy MFA

Security outcomes

Passkeys are phishing-resistant by construction. Every WebAuthn⁠ assertion is bound to the origin it was created on, so a credential enrolled at example.com cannot be replayed against a lookalike domain — the browser refuses to produce the assertion. That one property eliminates the entire category of credential stuffing and password reuse, because there is no static secret on the client to steal in the first place.

The gap against legacy MFA is where 2026 gets interesting. Adversary-in-the-middle kits are now commodity: WorkOS's 2026 analysis reports that Tycoon 2FA accounts for roughly 62% of phishing volume and generates around 30 million fraudulent emails per month (WorkOS⁠). These kits proxy the legitimate login flow in real time, harvest the user's SMS or TOTP code, and replay it against the real IdP inside the validity window. MFA-fatigue attacks time their push prompts to moments when the user is most likely to click through on autopilot. And SMS-based MFA is undermined at the carrier layer by the SIM-swap surge documented by Cifas⁠. Passkeys collapse all of that because the assertion is origin-bound and proximity-bound — the AiTM proxy cannot produce an assertion for the real origin, the fatigue prompt has nothing to approve, and a SIM swap does not help you forge a WebAuthn signature.

UX and conversion outcomes

The conversion case is as strong as the security case. The FIDO Passkey Index numbers above are the anchor: 93% login success against 63% for passwords, and a median 8.5-second sign-in against 31.2 seconds for passwords, a 73% improvement. Vendor case studies round out the shape — Tokyu's roughly 12× faster sign-in on web.dev⁠, Dashlane's 70% conversion uplift on the Google Developers Blog⁠, and the 81% help-desk incident reduction in the FIDO Passkey Index. That last number is the line that moves CFO conversations: the faster sign-in saves seconds, the help-desk reduction saves salaries.

FIDO2 and WebAuthn in the enterprise

Synced versus device-bound authenticators. NIST SP 800-63-4 (July 2025)⁠ classifies syncable authenticators at AAL2 — the first version of the guideline to do so formally. AAL3, required for privileged access in federal systems, still demands device-bound authenticators. Microsoft Entra ID tracks the same distinction: device-bound passkeys shipped in January 2024 and synced passkeys followed in November 2025⁠.

Attestation, AAGUIDs, and authenticator allowlists. Enterprise passkey programs typically lean on WebAuthn attestation statements and Authenticator Attestation GUIDs to restrict which authenticator models can be enrolled. The common patterns are allowlists for employee-issued devices, conditional allowlists keyed to assurance level, and separate policies for administrators. The FIDO Alliance's State of Passkey Deployment in the Enterprise⁠ puts workforce deployment at 87% across the US and UK enterprises surveyed.

Hardware security keys. YubiKey, Google Titan, and Feitian keys remain the dominant choice for admin and privileged accounts — device-bound, attestable, and immune to synced-credential-store attack vectors.

Integrating with SAML/OIDC federation. The pragmatic pattern for 2026 is passkey-at-IdP plus OIDC to downstream apps: the IdP owns the WebAuthn ceremony and issues an ID token or SAML assertion that downstream applications trust.

What's still holding back universal passkey adoption

Passkeys are the right default. They are not yet a solved problem.

Account recovery is the hardest unsolved problem. There is no universal best practice. Vendors variously fall back to backup codes, email magic links, phone-number verification, knowledge-based questions, or human-assisted identity proofing — each of which reintroduces part of the attack surface the passkey was meant to eliminate. A 2025 peer-reviewed literature review identifies account recovery, sharing and delegation, and misaligned user perception as the core challenges to wider adoption (MDPI Applied Sciences — Matzen et al. 2025⁠).

Cross-device and cross-ecosystem sync. Apple, Google, and Microsoft each run their own synced credential stores, and portability between them has historically required the user to re-enroll on each platform. The Credential Exchange Protocol and Credential Exchange Format (CXP/CXF)⁠ were published as a FIDO Alliance Proposed Standard in August 2025, and Apple shipped CXF in iOS and macOS 26. Portability is improving, but it is not yet universal in 2026.

Legacy clients and call-center channels. Desktop applications stuck on older WebAuthn-incompatible runtimes, IVR call flows, and phone-based account recovery still require knowledge factors. These do not go away because passkeys got better; they require parallel hardening.

Change-management friction. In the FIDO Alliance / Thales 2025 enterprise deployment study, groups that do not have active passkey projects cite complexity (43%), costs (33%), and lack of clarity on how to start (29%) as the top reasons for holding off (FIDO Alliance — State of Passkey Deployment in the Enterprise⁠).

Emerging passkey attacks. Honest caveat: 2025 produced the first wave of practical passkey-targeted research. Proofpoint documented synced-passkey downgrade attacks against Microsoft Entra in which browser spoofing is used to force the user into a weaker fallback method. SquareX demonstrated passkey hijacking via WebAuthn API interception at DEF CON 2025. Prove published analysis of SIM-swap-enabled passkey-sync recovery fraud — attacking the recovery path rather than the passkey itself. None of this undermines the recommendation to deploy passkeys; all of it underscores that passkey security depends on closing fallback paths, hardening recovery, and treating the synced credential store as part of the trust boundary.

Trajectory: passwordless by default in 2027–2028

Per the Gartner Market Guide for User Authentication (Hoover & Allan, November 2024), more than 90% of MFA transactions will be completed via FIDO passkey by 2027. Insurance pressure and the regulatory deadlines listed earlier in this article will keep pushing enterprise rollouts through 2027 and into 2028, when the default corporate sign-in is a synced passkey with device-bound escalation for admins.

The open questions for the next two years are not whether passkeys win but how cleanly they compose: whether CXP/CXF adoption reaches every major platform, how workforce SSO converges around passkey-at-IdP, and how organisations govern synced credential stores when the credential lives in a consumer cloud account rather than a corporate device.

Trend 2: AI Agents as First-Class Authentication Principals

The second major shift in 2026 authentication is that identity providers, standards bodies, and protocol designers now treat AI agents as a distinct principal type — not a special case of either human users or machine clients. This section covers what changed, the standards underneath the change, and the concrete patterns teams are using when agents call APIs on behalf of users or organizations.

Why AI agent authentication needs its own model

For this article, an AI agent is non-human software that uses LLM reasoning to call APIs or tools on behalf of a user or organization. Examples include a productivity assistant that reads a user's calendar, a backend summarization service that invokes an internal search API, and an IDE coding agent that edits files and opens pull requests.

Reusing a human user's session for an agent is the wrong primitive on four counts:

• Attribution. Audit logs need to answer "was this action taken by the human or by the agent acting for the human?" A raw user session collapses both into one identity.
• Revocation. If a user wants to disable one agent without logging out everywhere, a shared session gives the security team no handle to pull.
• Scope. A human's browser session typically carries broad permissions. An agent invoking a specific tool should carry only the permissions required for that call.
• Audit. Compliance and incident review need the full chain: which agent, which user, which tool, which resource, which time window.

A modern auth system therefore has to distinguish three principals as table stakes: human users, machine clients (internal and third-party services), and agents-on-behalf-of-users. The third category is where the 2025-Q4 through 2026-Q1 product wave landed.

Every major identity vendor now ships agent-specific identity primitives. Okta announced Okta for AI Agents⁠ with an Agent Gateway and a virtual MCP server as part of its "Secure Agentic Enterprise" blueprint. Auth0 shipped Auth0 for AI Agents⁠ plus its Token Vault for agent secrets. Microsoft launched Entra Agent ID⁠ in preview as part of Microsoft Agent 365. Google Cloud is previewing Agent Identities. Descope released Agentic Identity Hub 2.0⁠. Scalekit offers MCP Auth and Agent Actions⁠. And Clerk's October 2025 Series C explicitly earmarked capital for agent identity work.

The honest callout: despite the productization, enterprise governance of agent identity is immature. Strata's February 2026 research found only 18% of enterprises report confidence in their agent-identity governance. The OpenID Foundation's October 2025 paper, Identity Management for Agentic AI⁠, argues that existing standards can secure agentic use cases today but recommends specialized authorization servers and clean separation of concerns from human-user flows. Most production agent auth in the wild is still ad-hoc personal access tokens and API keys; the standards-aligned stack described below is the direction of travel, not the current average.

OAuth 2.1 as the baseline

OAuth 2.1 is the consolidation of fifteen years of OAuth 2.0 errata and security best practice into a single, opinionated specification. The current version is draft-15⁠, which expires in September 2026. Despite the draft status, the MCP specification and every major vendor in the list above treat OAuth 2.1 as the baseline for new deployments. The oauth.net/2.1 overview⁠ is a good primer. In parallel, RFC 9700 (OAuth 2.0 Security Best Current Practice)⁠ captures the consolidated security guidance that OAuth 2.1 pulls in.

What OAuth 2.1 consolidates:

• PKCE is required for all authorization code flows, public and confidential clients alike.
• Implicit flow is deprecated. The browser-based implicit grant is removed.
• Resource Owner Password Credentials (ROPC) is deprecated.
• Strict redirect URI matching — no substring or pattern matching.
• Refresh tokens for public clients must be sender-constrained or single-use.
• Bearer tokens are banned from URL query strings — they belong in the Authorization header.

Pick the grant that matches the call pattern. Client credentials is the grant to use for pure machine-to-machine calls where no end user is present — for example, a backend agent calling an internal API under its own identity. Access tokens should be short-lived, scoped to the minimum permissions needed, and audience-constrained to a specific resource server. Prefer JWT client assertions over long-lived client secrets.

Authorization code with PKCE is the grant for delegated agent access, where a user has authorized the agent to act for them. Here it matters whether the agent is impersonating the user (holding the user's token) or the user is effectively logged in as the agent with a distinct delegated token that carries actor information. The latter is the preferred model and is what token exchange enables. Curity's PKCE explainer⁠ is a solid introduction if PKCE is new to your team.

Token exchange and delegated agent access (RFC 8693)

RFC 8693⁠ defines OAuth 2.0 Token Exchange — the ability to swap one token for another with narrower scope, a different audience, or a different subject. This is the standards-native primitive for delegated agent access.

When a user hands an agent permission to call a downstream API, the agent does not reuse the raw user access token. It exchanges that token at the authorization server for a new token with a narrower scope, a specific audience, and an act claim identifying the agent as the actor. As the request propagates through a chain of tools, each hop can exchange again and further narrow scope. The resulting delegation chain is visible in the token itself.

The act and may_act claims are the auditability layer. act records who performed the action (the agent), while the sub claim records on whose behalf (the user). may_act lets a token declare which actors are permitted to delegate against it. Together they give a compliance reviewer a single token they can introspect to answer "which agent did what, for whom, when."

Use token exchange when the agent acts for a human user. Use a fresh client_credentials token when the agent is operating autonomously under its own identity. The two patterns coexist — a user-delegated flow can still spawn M2M sub-calls that use client credentials for infrastructure calls that have no user context.

Auth0 productized a related async pattern under Asynchronous Authorization for AI Agents⁠, which combines Client-Initiated Backchannel Authentication (CIBA) with Rich Authorization Requests (RAR) to let an agent request a specific, semantically-rich authorization from the user out-of-band — for example, "approve this agent to transfer up to $50 from account X."

Scoped, short-lived tokens for AI agents

Industry guidance has converged on two properties for agent tokens: narrow scopes and short lifetimes. The SuperTokens auth-for-AI-agents guide⁠ recommends capability tokens in the 60-to-300-second range for individual tool calls, refreshed as needed. The reasoning: an agent token that leaks is far less dangerous if it expires before an attacker can chain it into a larger exploit, and narrow scopes mean even a valid stolen token is bounded in what it can do.

Audience restrictions (aud claim) prevent a token issued for one API from being replayed against another. A calendar-scoped token should not be accepted by the payments API, even if both sit behind the same authorization server. RFC 8707 Resource Indicators⁠ is the standards mechanism: the client sends a resource parameter on the authorization and token requests, and the authorization server binds the resulting token to that resource via the aud claim. In multi-tenant deployments this is also how you tenant-isolate tokens — the resource indicator carries the tenant-specific API URL.

Confidential vs public clients matters for agent deployments. A backend service running in a trusted environment can be a confidential client and hold a real secret. An agent running in a user-controlled environment (an IDE plugin, a desktop app) is a public client and cannot — it uses PKCE plus sender-constrained tokens to compensate.

Sender-constrained tokens bind the token to a client-held key so that a stolen token is useless without the matching key. DPoP (RFC 9449)⁠ — Demonstration of Proof-of-Possession — is the HTTP-layer mechanism. The client signs a JWT over each request with its private key, and the resource server checks the proof against a key thumbprint baked into the access token. This is particularly valuable for public-client agents where the token is more exposed.

Model Context Protocol (MCP) authentication

MCP is the protocol AI agents use to discover and call external tools. Its authorization story matured significantly in late 2025 and early 2026, and it is worth separating three concepts to avoid slippage.

(a) What the spec actually requires. The live MCP authorization specification is revision 2025-11-25⁠. It opens with a stance worth quoting directly:

The spec then splits requirements by transport:

• HTTP-based transports SHOULD conform to the MCP authorization specification.
• stdio transports SHOULD NOT conform — they retrieve credentials from the environment.
• Other transports MUST follow established security best practices for their protocol.

When an MCP deployment does implement authorization over HTTP, the spec requires the following. Authorization servers MUST implement OAuth 2.1. MCP clients MUST implement PKCE with S256, and they MUST refuse to proceed if an authorization server's metadata does not advertise code_challenge_methods_supported. Clients MUST send the resource parameter (RFC 8707 Resource Indicators) on every authorization and token request, regardless of whether the server is known to support it. MCP servers MUST expose RFC 9728 Protected Resource Metadata⁠, and clients MUST support both discovery mechanisms — the WWW-Authenticate header and the .well-known/oauth-protected-resource document. MCP servers MUST validate the token audience against their own resource URI.

(b) Optional extensions. Dynamic Client Registration (RFC 7591⁠) is MAY, not MUST, and the spec is explicit that DCR is retained "for backwards compatibility with earlier versions of the MCP authorization spec." The preferred pattern for first-time client registration is Client ID Metadata Documents (SHOULD). The priority order for client registration is pre-registration, then CIMD, then DCR, then a user prompt.

(c) Current ecosystem practice. MCP clients ship inside Claude, ChatGPT, VS Code, Cursor, Windsurf, Zed, and Codex — see modelcontextprotocol.io⁠ for the current directory. Remote MCP servers with OAuth-based authorization are documented and in production at WorkOS AuthKit⁠, Stytch Connected Apps with the OpenAI Apps SDK⁠ (see also Stytch's guide to authentication for the OpenAI Apps SDK⁠), Descope Agentic Identity Hub⁠, and Scalekit MCP Auth⁠. On the open-source side, NapthaAI's http-oauth-mcp-server, mcpauth/mcpauth, and mcp-oauth-gateway are community implementations of the authorization server side.

Clerk ships a remote MCP server at mcp.clerk.com/mcp that serves up-to-date Clerk SDK snippets to AI coding assistants — see the Clerk MCP server changelog entry and Clerk's MCP guide. This is a vertical MCP server for Clerk documentation, not a general-purpose MCP authorization server for third-party MCP clients. Teams that want to stand up their own MCP server with Clerk-backed authentication should follow the build-your-own MCP server guide.

Common patterns for authenticating AI agents accessing APIs

Three patterns cover the large majority of real agent deployments.

Pattern 1: Machine-to-machine tokens for service agents. The agent has its own identity and there is no human in the loop. The canonical example is a backend summarization agent calling an internal search API. Use OAuth 2.1 client credentials, a JWT client assertion instead of a long-lived client secret, a tightly-scoped and audience-bound access token, and short lifetimes. Pseudocode illustrating the flow:

// Pseudocode: M2M token for a service agent
const { access_token } = await authServer.clientCredentials({
  client_id,
  client_assertion, // JWT client assertion, not a long-lived secret
  scope: 'search:read',
  audience: 'https://api.internal/search',
})

await fetch(url, {
  headers: { Authorization: `Bearer ${access_token}` },
})

Pattern 2: Delegated user access for user-initiated agents. The agent acts on behalf of an authenticated user, and the agent's token is derived from the user's session via token exchange or a Rich Authorization Request — not by re-using the user's raw access token. The canonical example is a productivity assistant reading a user's calendar. The resulting token carries an act claim that identifies the agent as the actor while the sub still identifies the user. Pseudocode for the token exchange:

// Pseudocode: token exchange to obtain a narrower agent token
const agentToken = await authServer.tokenExchange({
  grant_type: 'urn:ietf:params:oauth:grant-type:token-exchange',
  subject_token: userAccessToken,
  subject_token_type: 'urn:ietf:params:oauth:token-type:access_token',
  actor_token: agentAssertion,
  actor_token_type: 'urn:ietf:params:oauth:token-type:jwt',
  scope: 'calendar:read', // narrowed
  audience: 'https://api.example.com/calendar',
  // resulting token carries an `act` claim identifying the agent
})

Pattern 3: Agent identity with auditable action trails. Every call carries both the agent identity (via act or azp) and the principal it acts for (via sub). The resource server logs sub, azp, act, the request path, the scopes exercised, and the request metadata. Downstream SIEM and compliance tooling queries this log to answer "which agent did what, for whom" without having to join across multiple systems. This pattern is the operational complement to Patterns 1 and 2 — it is what makes the delegation chain useful after the fact.

Open questions in agent authentication

The standards are moving faster than most production deployments. A few of the open questions worth tracking:

Consent UX for long-running agents. A multi-step agent that runs for hours or days needs a consent model that does not re-prompt the user on every tool call but also does not silently escalate. Re-prompt timing and scope-change triggers are an unsolved UX problem.

Revocation propagation. When a user revokes an agent's access mid-task, how quickly does that propagate through in-flight tokens at downstream resource servers? Microsoft's Continuous Access Evaluation (CAE) is a productized near-real-time revocation pattern for this class of problem. Short token lifetimes are the simpler answer, but they do not fully close the window.

Agentic identity management. Provisioning, rotating, and deprovisioning agent identities at scale is still mostly manual. The Strata 18% governance-confidence number is the symptom.

Emerging work worth watching:

• Fine-grained authorization via policy engines — Oso, Amazon Verified Permissions built on Cedar, and attribute-based access control (ABAC) more generally. Tokens carry identity; policy engines decide what that identity is allowed to do against specific resources.
• Workload identity — the IETF's WIMSE architecture draft⁠ formalizes identity for workloads, and SPIFFE/SPIRE is the operational implementation cited by HashiCorp Vault and Red Hat deployments for agent identity in infrastructure.
• OIDC-A⁠ — a research direction for an OIDC profile tailored to agents.
• Agentic JWT⁠ — a research proposal for JWT semantics that encode agent actor chains natively.
• Rich Authorization Requests (RFC 9396) — structured, semantically-rich authorization requests for agent actions like "transfer up to $X to account Y."
• FAPI 2.0 — a concrete profile that mandates DPoP or mTLS for financial-grade agent integrations.
• CIBA (OpenID CIBA Core 1.0) — human-in-the-loop asynchronous authorization, suited to out-of-band approvals for sensitive agent actions.
• NIST AI Agent Standards Initiative (February 2026) — early U.S. government standards work on agent identity and interoperability.
• Stripe's agentic commerce and Machine Payments Protocol — an early agent-to-service payment standard with authorization primitives built in.

The through-line across this list is that standards bodies, research labs, and commercial identity vendors are all working on the same problem: giving agents their own identity, binding that identity tightly to scope and audience, and keeping the human principal visible through the chain. The next section turns to where that authentication has to happen — at the edge.

Trend 3: Edge-Centric Ingress Verification

The third structural shift in 2026 authentication is where token verification happens in the request path. For a decade, verifying that a caller held a valid session token meant a round trip — at minimum to the origin, often to a session store behind it. In 2026, that check has moved to the network boundary for most high-traffic TypeScript apps, and the framework defaults (Next.js 16 proxy.ts, SvelteKit hooks, Remix/React Router loaders) make running a JWT check as the first thing that touches a request the path of least resistance.

But "edge auth" has also matured past its marketing phase. The honest framing in 2026 is narrower than the 2023 pitch: the edge handles one specific pipeline well, and trying to run the whole IdP there was always overclaimed.

Why edge-centric ingress verification is winning — and what's maturing about it

Performance. Verifying a short-lived JWT at a CDN point of presence takes under 2 ms once the JWKS is cached; the first verification in a cold cache pays a 15–30 ms JWKS fetch and then amortizes. Published case studies of moving token verification from origin to edge show global checkout TTFB improvements from ~2 s to ~45 ms, driven almost entirely by eliminating the origin round trip on unauthenticated or already-authenticated requests. See SSOJet's Cloudflare Workers and Vercel JWT guide⁠, Daily Dev Post on edge vs origin business logic⁠, and Fastly's patterns for authentication at the edge⁠.

Security. Rejecting unauthenticated and malformed traffic at the edge shrinks the origin blast radius. Credential stuffing, naive scrapers, and malformed-token floods never reach application servers. This is necessary but not sufficient: edge verification says the token is cryptographically valid and unexpired, not that the principal is authorized to do a particular thing.

Compliance. Region-pinned processing at PoPs aligns naturally with GDPR data minimization, India's DPDPA, and Saudi Arabia's PDPL — a claim extraction at a local PoP never ships the raw token to a different jurisdiction. See Security Boulevard's 2025 data-residency analysis⁠.

Framework alignment. Next.js 16's proxy.ts runs at the network boundary. SvelteKit's handle hook, Remix and React Router loaders, and Hono middleware all make it trivial to run a verification call as the first thing that touches a request. The ergonomics of "verify here, then continue" are finally uniform across the TypeScript ecosystem.

Honest maturation beat. Vercel's 2026 shift from pure "edge functions" to fluid compute is a concrete signal that the industry is moving from "everything at the edge" to hybrid runtimes. Ingress-layer token verification stays edge-relevant. Runtime choice — Node.js runtime in Next.js 16 proxy.ts, V8 isolates on Cloudflare Workers, Compute@Edge on Fastly — now matters more than the old "edge vs origin" binary.

JWT validation at the edge

Stateless validation patterns

Ingress verification uses asymmetric signatures so the edge never needs the signing key. Verify RS256, ES256, or EdDSA against a cached JWKS and there is no database round trip. EdDSA is roughly 62× faster than RS256 for signing in JWT contexts and noticeably faster to verify; ES256 is a balanced edge pick; RS256 remains the broadest-compatibility option. See WorkOS on RS256 vs HS256⁠.

JWKS distribution and key rotation

A stateless verifier is only as good as its key rotation story. The pattern that holds up in production is four-phase rotation with overlapping key lifetimes and an explicit grace window for stale caches: publish the new key, verify with both, sign with the new key only, then retire the old key. JWKS endpoints are typically refreshed every 5–10 minutes at the edge. See Zalando Engineering on automated JWK rotation⁠ and David Sulc on JWS APIs and JWKS basics⁠.

The canonical edge library jose ships documented defaults on the RemoteJWKSetOptions interface for createRemoteJWKSet(): cooldownDuration = 30,000 ms (30 seconds) and cacheMaxAge = 600,000 ms (10 minutes). Those values matter for rotation planning — your grace window needs to be longer than cacheMaxAge plus the cooldown. See the jose repository⁠.

Claim validation beyond the signature

Signature validity is the first check, not the only one. A correct verifier validates iss (issuer), aud (audience), exp (expiry), nbf (not-before), azp (authorized party) where present, and any custom claims your application depends on. Skipping claim validation — especially aud and iss — is the most common edge-auth bug and turns a "verified JWT" into a token from any issuer your JWKS happens to trust. See Curity's JWT best practices⁠ and Descope on JWT claims⁠.

Library recommendation

jose (panva/jose) is the de-facto standard for edge JWT work. It uses the Web Crypto API, has zero runtime dependencies, and runs unchanged on Node, browsers, Cloudflare Workers, Deno, Bun, and Vercel Edge. createRemoteJWKSet() handles JWKS caching and cooldown automatically. See github.com/panva/jose⁠. The older jsonwebtoken package is incompatible with edge runtimes because it depends on Node built-ins — see Wael Habbal's guide to Next.js and the Edge runtime⁠. Runtime-specific alternatives worth knowing: @tsndr/cloudflare-worker-jwt for Workers-specific deployments; Fastly's compute-js-auth and compute-rust-auth starters for Compute@Edge; Deno's djwt (see Netlify Edge Functions docs⁠); and Akamai EdgeWorkers with its built-in JWT module, which can pair edge JWT verification with EdgeKV for denylist lookups and near-real-time revocation.

Pseudocode:

// Pseudocode: verify a JWT at the edge against a cached JWKS
import { createRemoteJWKSet, jwtVerify } from 'jose'

const JWKS = createRemoteJWKSet(new URL('https://your-idp.example.com/.well-known/jwks.json'))

export async function verifyEdgeToken(token: string) {
  const { payload } = await jwtVerify(token, JWKS, {
    issuer: 'https://your-idp.example.com',
    audience: 'https://api.example.com',
  })
  return payload
}

The pattern is uniform across providers: fetch-and-cache JWKS, verify signature, assert claims, return the payload or throw.

Ingress runtime support across providers

Next.js 16 proxy.ts. Next.js 16 replaces middleware.ts with proxy.ts and makes the application's network boundary explicit. proxy.ts defaults to the Node.js runtime, and the runtime config option is not available on proxy.ts — setting it throws an error. Next.js positions Proxy as an ingress-layer concern (redirects, rewrites, header manipulation, optimistic checks), not as an authorization decision point, and the docs explicitly warn:

middleware.ts is retained for existing Edge-runtime code paths but is deprecated in 16.0.0. See the Next.js 16 announcement⁠ and the Proxy API reference⁠.

CVE-2025-29927. Pre-16 Next.js versions were vulnerable to a middleware bypass via the x-middleware-subrequest header. If you are still on an affected version, strip the header at your reverse proxy or upgrade. See NVD CVE-2025-29927⁠.

Cloudflare Workers. True edge runtime on V8 isolates with roughly 5 ms cold spin-up, full Web Crypto API, and Durable Objects / D1 / KV / R2 for adjacent state. See Cloudflare Workers docs⁠.

Deno Deploy, Netlify Edge Functions, Fastly Compute@Edge, Akamai EdgeWorkers. Other runtimes where ingress token verification runs close to users, each with its own constraints on cold-start, bundle size, and API surface.

Runtime constraints that matter. Web Crypto only (no Node crypto), strict bundle-size caps, and missing Node built-ins are the cross-cutting gotchas. jose is the safe pick across all of these.

Tradeoffs you need to understand

Revocation vs statelessness. Stateless JWT verification has no built-in revocation. The practical answer in 2026 is short-lived access tokens (60 seconds to 5 minutes) so compromised tokens have a small blast radius. When that is not enough, allow-list or deny-list caches at the edge give near-real-time revocation at the cost of a cache read — and session lookups are worth the round trip for high-stakes operations (payments, admin, account changes). See SuperTokens on JWT blacklist and revocation strategies⁠. Microsoft's Continuous Access Evaluation (CAE) is a productized near-real-time revocation pattern worth studying.

Session stickiness vs global auth. The pattern that wins is hybrid — stateless JWT checks paired with stateful session verification where centralized revocation matters. Curity's token handler pattern⁠ walks through the same trade-off for single-page apps: a stateless implementation encrypts tokens in session cookies, while a stateful implementation persists them in a store the OAuth agent reads from — both aim at the same security guarantees with different operational shapes. In a 2026 edge deployment that cashes out as: edge-verify short-lived access tokens on every request, and origin-validate long-lived refresh tokens when a renewal happens.

State storage options. Cloudflare Durable Objects (V8 isolates with embedded SQLite) are a concrete primitive for edge-adjacent session state when stateless-only does not fit — region-pinned, strongly consistent, and colocated with the verifier.

The "edge isn't automatically better" callout. Below a real traffic threshold, the operational burden of multi-region JWKS caching, key-rotation monitoring, and cross-PoP time-drift handling outweighs the latency win. Small apps are fine with origin auth and should stay there. Vercel's fluid compute shift is a concrete industry acknowledgment that "pure edge for everything" was overclaimed.

Three pipelines, not one

The most important distinction in 2026 edge auth is that there are three distinct pipelines, and edge verification only handles one of them cleanly. Flattening them is where architectures break.

Pipeline A — Browser session auth. Passkey, password, social, or magic-link authentication happens at the IdP. The IdP issues a long-lived client credential (in Clerk's case, the __client token on the FAPI domain) and short-lived session tokens (60-second JWTs). During SSR and any time the short session token is expired or missing server-side, the IdP performs a handshake — server to browser to IdP — to re-issue a fresh short session token. This is not a stateless edge operation; it requires a redirect, IdP state, and cookie context. See How Clerk works.

Pipeline B — Ingress request gating (edge-native). On every request, a short-lived JWT (user session JWT, M2M JWT, or agent access token) is verified against cached JWKS using Web Crypto and jose. This is what "edge auth" means in this article. It runs at the network boundary, returns 401/403 fast, and never round-trips to the IdP.

Pipeline C — Machine and agent verification. JWT-format M2M tokens follow Pipeline B. Opaque M2M tokens and API keys still require a network verification call to the IdP (in Clerk, billed at $0.00001 per verification) — they cannot be verified statelessly at the edge. Statelessness and revocability are a tradeoff, not a universal property.

The edge handles Pipeline B uniformly for users, machines, and agents. It does not replace Pipeline A (session renewal) or Pipeline C when opaque tokens are in use. Treat those three pipelines as separate design problems and edge auth stops being confusing.

What This Means for Developers

Three structural shifts — passkeys, agent-aware auth, and edge-centric ingress verification — collapse into a concrete decision surface for teams shipping in 2026. This section is the pragmatic checklist.

The 2026 authentication checklist

An authentication stack that will age well for the next 24 months should cover all of the following:

• First-class passkey support across the full lifecycle: registration, sign-in, recovery, and multi-device synchronization.
• OAuth 2.1 compliance and machine-to-machine token support for agent and service workloads.
• MCP-compatible authorization flows if your application exposes tools or data to AI agents.
• Edge runtime compatibility for middleware- or ingress-level token verification on Next.js 16 proxy.ts, Cloudflare Workers, and similar.
• TypeScript-first SDKs that work unchanged across Node, edge, and native runtimes.
• Organization and multi-tenant primitives for B2B workloads: invitations, roles, SSO, and directory sync.
• Observability: per-request identity in logs, audit trails of authentication events, and session diagnostics your on-call can actually use.

Missing any one of these is not fatal today, but the cost of adding them later — especially passkey recovery and MCP authorization — has been empirically high for teams that deferred them.

Evaluating authentication providers in 2026

The evaluation axes that actually matter in 2026 are narrower and more specific than the generic feature grids of 2022:

• Passkey UX and recovery coverage. Not just "we support passkeys." Recovery — what happens when a user loses every device — is the real differentiator. Ask providers to walk through the full recovery flow.
• Machine tokens, scoped credentials, and token-exchange support. Does the provider issue JWT M2M tokens (verifiable at the edge) or opaque tokens (IdP round trip required)? Does it support RFC 8693 token exchange for delegated agent access?
• MCP and agent-era readiness. Can the provider act as an OAuth 2.1 IdP for MCP clients? Does it publish documented MCP authorization server guidance, or do you have to build the adapter yourself?
• Framework integration depth. First-party SDKs and working examples for Next.js 16, Remix, Expo, SvelteKit, and Astro — not just a generic "use our REST API."
• Pricing model fit for machine and agent traffic patterns. Metered M2M verifications, per-request opaque-token checks, and per-connection SSO pricing can add up fast once agents are issuing tokens on your behalf.
• Breach and incident track record, with status-page transparency. A provider that sits in front of every login is a tier-zero dependency; treat it like one.

Build vs buy: the 2026 calculus

"Rolling your own auth" in 2026 is a materially larger scope than it was in 2020. A serious DIY stack now has to deliver passkeys (WebAuthn, conditional UI, recovery), an OAuth 2.1 IdP, M2M tokens, an MCP authorization server, edge runtime compatibility, audit and telemetry, and the compliance paperwork that large customers will ask for on day one of procurement.

That breadth has shifted the build-vs-buy line for most teams. The expected cost of keeping a DIY stack current with passkey platform changes, CVE disclosures, and the MCP specification iterations alone is now larger than the cost of a managed provider for most application companies.

Where DIY still makes sense: very narrow scope (a single internal tool, a single auth method), highly regulated custom flows that off-the-shelf providers cannot accommodate, internal-only tools behind a corporate SSO, and air-gapped environments where a SaaS provider is not an option.

Choosing the best authentication stack for TypeScript in 2026

The stack characteristics that age well are narrower than the marketing suggests. A stack worth betting on is edge-first (JWT verification runs at ingress without an origin round trip), standards-compliant (OAuth 2.1, WebAuthn Level 3, OIDC, and MCP authorization), passkey-primary (passkey as the default, passwords retained only for legacy), and agent-ready (M2M tokens and delegated access as first-class primitives, not afterthoughts).

Framework alignment matters concretely. A 2026 TypeScript stack should integrate cleanly with Next.js 16's proxy.ts model, React 19's Server Components and Actions, and modern Expo / React Native for mobile — without per-framework shims that drift out of sync.

The role of type-safe SDKs and end-to-end TypeScript is practical, not aesthetic. When auth() returns a typed userId, sessionId, and orgId, entire categories of authentication bugs — wrong-tenant reads, missing-session crashes, untyped claim access — surface at compile time instead of in production. The reduction in auth-adjacent incidents from typed SDKs is one of the quieter wins of the 2026 TypeScript ecosystem.

The specific-vendor question — who actually delivers this — is the subject of the next two sections.

Implementation: Modern Authentication with Clerk

Why Clerk fits 2026 requirements

Clerk bundles the authentication primitives that matter in 2026 into a single TypeScript-first stack. Passkeys are built-in on Pro and higher tiers — the Hobby tier excludes passkeys, MFA, and enterprise SSO (pricing). That matters because passkey-primary UX is the table-stakes consumer flow this year, and teams shouldn't discover tier limits mid-rollout.

On the agent side, Clerk ships first-class machine-to-machine tokens in two formats: JWT (verified locally for free against the instance public key) and opaque (verified over the network, revocable). The February 2026 changelog entry introduced the JWT format explicitly for stateless verification at the edge (changelog).

For AI coding workflows, Clerk publishes a remote MCP server at mcp.clerk.com/mcp that serves SDK snippets to AI coding assistants (changelog, docs). Separately — and scoped strictly to what's documented — Clerk can be configured as an OAuth 2.0/OIDC IdP while you build your own MCP server, per the Express.js MCP build guide.

The backend SDK is, in Clerk's own phrasing, "built for Node.js/V8 isolates (Cloudflare Workers, Vercel Edge Runtime, etc.)" (docs). Combined with clerkMiddleware() at the proxy.ts layer in Next.js 16⁠, ingress checks run at the network boundary. The DX is TypeScript-first across web, mobile, and backend.

The industry signal matches the product direction: Clerk's October 2025 Series C was a $50M round led by Menlo Ventures and Anthropic's Anthology Fund, with agent identity called out as the explicit target (announcement).

Adoption friction is usually where a stack choice dies, so one honest note on migration: Clerk publishes an open-source migration tool at clerk/migration-tool⁠ with transformers for Auth0, Auth.js, Firebase, Supabase, and Clerk-to-Clerk, plus a trickle-migration path for staged cutovers and password-hash import that transparently upgrades supported algorithms to Bcrypt. OAuth connections cannot be bulk-migrated — users re-consent on first sign-in — and cutting over session issuance will end active sessions from the previous provider. See the migration overview and exporting users guide for the end-to-end flow.

Setting up passkey-first authentication

Enabling passkeys starts in the Clerk Dashboard under User & Authentication → Passkeys. Once the strategy is on, Clerk's prebuilt <SignIn /> and <SignUp /> components surface passkey-primary UX automatically, with email OTP, magic links, and SSO as fallbacks for users who don't yet have a credential on their current device.

For a custom flow, adding a passkey to an already-signed-in user is a one-call API:

'use client'

import { useUser } from '@clerk/nextjs'

export function CreatePasskeyButton() {
  const { isSignedIn, user } = useUser()

  const createClerkPasskey = async () => {
    if (!isSignedIn) return
    try {
      await user?.createPasskey()
    } catch (err) {
      console.error('Error:', JSON.stringify(err, null, 2))
    }
  }

  return <button onClick={createClerkPasskey}>Create a passkey</button>
}

The user.createPasskey() call triggers the browser's WebAuthn ceremony and persists the resulting credential on the user record. Clerk's passkeys custom flows guide covers registration, sign-in, the 10-passkeys-per-account cap, and the constraint that users must have another authentication method configured before their first passkey — passkey-only signup is not supported end-to-end today.

Account recovery is the part worth being honest about: no passkey implementation has solved it cleanly. The practical pattern on Clerk is backup codes plus a verified email factor, with recovery flows kept review-gated rather than fully automated. Rushing a self-service "lost my device" path is where account-takeover bugs cluster. Treat recovery as a policy problem first and a UI problem second, and keep SSO or email OTP enabled as durable fallbacks for the long tail of users whose devices change.

Authenticating AI agents with Clerk

Agent identity is where Clerk has invested heavily. For service-to-service agents — scheduled jobs, background workers, autonomous LLM agents with their own identity — Clerk issues M2M tokens. Pricing as of March 2026 is $0.001 per creation, $0.00001 per opaque verification, and JWT verification is free (changelog, pricing). The tradeoff is explicit: JWT format costs nothing to verify but cannot be revoked before expiry; opaque format costs per verification but can be revoked instantly.

For delegated user access — an agent acting on a specific user's behalf — the pattern is short-lived, scoped tokens derived from the user session rather than long-lived machine credentials. For MCP-style authorization, Clerk supports dynamic client registration, scope disclosure at consent time, and configurable token lifetimes inside the documented build-your-own-MCP-server flow.

Audit logging and revocation work only on opaque tokens. That is a deliberate design choice: if you need to kill a compromised agent credential within seconds, opaque is the format; if you need free, stateless verification at the edge for a high-volume internal agent, JWT is the format. Many teams mix both.

import { createClerkClient } from '@clerk/backend'

const clerkClient = createClerkClient({
  machineSecretKey: process.env.CLERK_MACHINE_SECRET_KEY!,
})

// Create an M2M token — choose JWT (free verify, no revocation)
// or opaque (per-request verify, revocable).
const { token } = await clerkClient.m2m.createToken({ tokenFormat: 'jwt' })

// Verify on the receiving side
const verified = await clerkClient.m2m.verify({ token })

The tokenFormat field is the lever: pass 'jwt' for edge-verifiable tokens with no revocation story, or 'opaque' for network-verified tokens you can cancel from the dashboard. See the machine auth overview for scope modeling, per-token rate limits, and the full lifecycle API.

Edge-compatible authentication in Clerk — per pipeline

Clerk's edge story only makes sense once you separate the three pipelines introduced earlier in this article.

Browser session (Pipeline A). Clerk uses a two-token model: a long-lived __client token anchored on the FAPI domain, plus short-lived 60-second session JWTs on the app domain. When an SSR request lacks a fresh session token, Clerk runs a handshake — server redirects to FAPI, FAPI mints a new session token, the browser replays the request. proxy.ts plus clerkMiddleware() runs at the network boundary and integrates with this handshake; it is not a replacement for it. The full protocol is documented in how Clerk works.

Ingress JWT verification (Pipeline B). Per Clerk's docs, @clerk/backend is "built for Node.js/V8 isolates (Cloudflare Workers, Vercel Edge Runtime, etc.)" (backend SDK docs). Short session JWTs and JWT-format M2M tokens are verified statelessly against the instance public key or cached JWKS, which is exactly what edge runtimes are good at.

Machine/agent verification (Pipeline C). JWT-format M2M tokens are verified statelessly at the edge — same machinery as Pipeline B, free per verification. Opaque M2M tokens and API keys still require a network call to Clerk ($0.00001 per opaque verification, revocable). Those are not edge-only primitives; treat them as remote calls when you plan latency budgets.

The jose library's createRemoteJWKSet() defaults — cooldownDuration of 30,000 ms and cacheMaxAge of 600,000 ms — apply uniformly across any runtime that uses it (jose on GitHub⁠).

// proxy.ts
import { clerkMiddleware, createRouteMatcher } from '@clerk/nextjs/server'

const isProtectedRoute = createRouteMatcher(['/dashboard(.*)', '/api/private(.*)'])

export default clerkMiddleware(async (auth, req) => {
  if (isProtectedRoute(req)) {
    await auth.protect()
  }
})

export const config = {
  matcher: [
    '/((?!_next|[^?]*\\.(?:html?|css|js(?!on)|jpe?g|webp|png|gif|svg|ttf|woff2?|ico|csv|docx?|xlsx?|zip|webmanifest)).*)',
    '/(api|trpc)(.*)',
  ],
}

Pipeline A (the handshake) continues to work through this middleware even though the ingress check itself is edge-safe — clerkMiddleware() knows how to orchestrate redirects back to FAPI when a session token is stale. Using Clerk's phrasing: @clerk/backend is built for Node.js/V8 isolates, and proxy.ts is where that compatibility pays off in Next.js 16.

Honest caveat: "Clerk runs at the edge" means Pipeline B is edge-native and Pipeline C is edge-native when the token is JWT-format. Session renewal (Pipeline A) still uses the IdP via the handshake flow; it is not a stateless edge operation.

Organization and multi-tenant authentication

B2B workloads map onto Clerk's organizations primitive: each organization has its own membership list, roles (admin, member, or custom), and permissions. Users can belong to many organizations, and the active organization is part of the session context — auth() in a server component or route handler returns orgId, orgRole, and orgPermissions alongside the user identity, which lets you scope queries, feature flags, and policy checks without re-querying membership.

For enterprise tenants, Clerk supports verified domains — a customer claims ownership of their email domain, and new signups from that domain are auto-placed into the correct organization and optionally routed to an SSO connection. Enterprise SSO is Pro+ only; each app includes one connection, with overage billed at $15–$75/mo per connection depending on protocol (pricing). The B2B Enhanced add-on at $85/mo annual (100 MROs) layers on audit logs, advanced roles, and richer organization quotas.

Agent tokens can be scoped to a specific organization at creation time, so a tenant's autonomous worker can only act within its own org boundary — which keeps multi-tenant blast radius bounded without reinventing authorization primitives.

Comparing Modern Authentication Options for 2026

Comparison table

The matrix below covers 10 providers whose 2026 capabilities are verifiable from current official documentation. Three other noteworthy options — Scalekit, Descope, and Ory — appear in the "Also consider" paragraph that follows, because their public documentation is thinner or their positioning deserves a short narrative rather than a row. Any cell we could not tie to current official docs is labeled Not documented.

Every cell above is backed by a concrete source in current official documentation. Cells labeled Not documented are not claims of absence — they are claims that we could not find public documentation, as of April 2026, to support the capability at the specificity the column requires.

Also consider (not in matrix). Scalekit⁠ is an organization-first B2B auth platform with MCP Auth that implements RFC 9728 Protected Resource Metadata, plus AgentKit for delegated-agent connectors. Descope's Agentic Identity Hub 2.0⁠ bundles Inbound Apps (OAuth IdP), Outbound Apps, and MCP Auth SDKs with OAuth 2.1 and tool-level scopes. Ory⁠ is the canonical open-source/self-hosted option — Kratos supports WebAuthn/passkeys, and Hydra is OpenID Certified for OAuth 2.0/2.1.

Provider-by-provider

Clerk

TypeScript-first across web, mobile, and backend, with passkeys, M2M tokens, and organizations as first-class primitives. Publishes a remote MCP server for SDK snippet distribution to AI coding assistants. Best fit: TypeScript, Next.js, or Expo teams, and B2B SaaS needing organizations. Pricing honesty — Hobby excludes passkeys, MFA, and enterprise SSO; Pro+ includes 1 enterprise connection with overage metered at $15–$75/mo per connection.

Auth0 (Okta Customer Identity)

Breadth of enterprise features, a long track record, and flexibility via Actions and Rules. 2026 releases include Auth0 for AI Agents and Token Vault for user-delegated API tokens. MCP support is Limited Early Access per Auth0's own page — it should not be described as GA. Enterprise connections are metered as add-ons above the tier inclusion.

Okta Workforce Identity

The enterprise IdP. Okta for AI Agents blueprint plus a virtual MCP server have a GA date announced for 30 April 2026 (Early Access at the time of writing), and the Okta MCP Server for natural-language identity administration is documented today. Best for workforce SSO combined with agent identity governance, rather than for consumer-facing CIAM.

WorkOS AuthKit

Strong workforce onboarding with enterprise SSO, SCIM, and directory sync built in. AuthKit passkeys are included at no separate charge, and AuthKit is a spec-compatible OAuth authorization server for MCP with documented Protected Resource Metadata endpoints. Consumer UX is not the primary focus, and SSO is metered per connection at tiered monthly rates.

Stytch

Passwordless-first with documented MCP server authorization including Protected Resource Metadata, an OpenAI Apps SDK guide, a Cloudflare Workers guide, and Connected Apps — which turns any application into an OAuth 2.0/OIDC IdP. Full Dynamic Client Registration plus OAuth 2.1 puts it in the most MCP-native tier alongside WorkOS and Scalekit.

Supabase Auth

Tight Postgres integration, open-source, and cheap at small scale. No native passkey support — passkey integrations route through Corbado, Passage, or Clerk via the Supabase Partners program. SAML 2.0 SSO is available at Pro+ (project-level) and Team/Enterprise (org-level), metered at $0.015 per SSO MAU. No first-class organizations primitive.

Firebase Authentication / Identity Platform

Ease of use for Firebase stacks and tight Google ecosystem integration. Neither Firebase Auth nor the Identity Platform docs document a native passkey / WebAuthn sign-in method as of this writing. SMS MFA plus SAML/OIDC federation via the Identity Platform upgrade cover enterprise cases; agent auth patterns and portability off GCP are limited.

AWS Cognito

Tight AWS integration and native passkeys / WebAuthn since November 2024 on the Essentials tier and above, with up to 20 passkeys per user. Frequently paired with Amazon Verified Permissions (which uses the Cedar policy language) for fine-grained authorization. User pools, not SaaS-style organizations.

Azure Entra External ID / Entra Agent ID

Microsoft's CIAM on Azure. The External ID methods page does not explicitly enumerate passkeys, though Entra Workforce supports FIDO2 / passkeys broadly. Entra Agent ID (Preview) supports OAuth 2.0, MCP, and Agent-to-Agent (A2A) as part of Microsoft Agent 365 — notable for organizations already standardized on the Microsoft cloud.

Keycloak

Self-hosted open-source IdP. Native passkey UIs were promoted to GA in 26.4.0 — conditional and modal sign-in via the WebAuthn Passwordless Policy. Good DIY-but-supported choice for on-prem deployments, data-residency-pinned workloads, or teams that want full operational control without paying per-MAU.

DIY with open-source libraries

Auth.js v5⁠ is still in beta — next-auth@5.0.0-beta.x — and the WebAuthn/Passkeys provider is, per the official docs, "experimental and not recommended for production use." No built-in organizations, RBAC, or 2FA. Lucia v3⁠ is deprecated per the maintainer's "A fresh start" post and has been repositioned as a learning resource for session fundamentals rather than an actively developed library. Raw jose plus a custom IdP is viable for very narrow scopes, but inherits every ongoing maintenance cost described earlier in this article.

Decision matrix by use case

For a consumer app with passkey-first UX, Clerk, Auth0, WorkOS, AWS Cognito, and Stytch are all strong fits — each ships passkeys as a first-class strategy with sensible fallbacks. For B2B SaaS with organizations and SSO, the short list narrows to Clerk, WorkOS, Auth0 (B2B Essentials/Professional), and Stytch for B2B — the differentiator is usually organization modeling depth versus enterprise-SSO pricing. For internal tools and admin panels where scope is narrow and stable, Auth.js v5 paired with a raw IdP can be defensible; once requirements grow — SSO, audit logs, multi-org — moving to Clerk or Auth0 is usually faster than backfilling them. For agent- or MCP-centric products, WorkOS AuthKit, Stytch, Scalekit, and Descope are the most MCP-native today; Clerk is the strongest TypeScript-first choice for agent workloads centered on M2M tokens and SDK-snippet distribution. For highly regulated or air-gapped deployments, Keycloak self-hosted and Ory self-hosted remain the canonical answers.

Analyst context for teams doing vendor reviews: Gartner's 2025 Magic Quadrant for Access Management names Okta, Microsoft, and Ping as Leaders; Forrester's Q4 2024 Wave for CIAM lists Ping, Transmit Security (Mosaic), and Strivacity as Leaders; KuppingerCole's 2026 CIAM Leadership Compass names LoginRadius, cidaas, and Ping as overall Leaders. Clerk is being discussed in the same ecosystem these reports cover, and the capabilities above are what buyers are now asking every vendor — including the named Leaders — to demonstrate in 2026.

Looking Ahead: Authentication in 2027 and 2028

The next 18-24 months will move authentication from "passkeys are arriving" to "passkeys are the default and agents are first-class principals." The shifts below are grounded in shipping standards, published roadmaps, and analyst forecasts — not hype.

Likely trajectories

Expect passkey enrollment to become the default path on new account creation, with password entry reframed as a fallback exception. Gartner's Market Guide for User Authentication (Hoover & Allan, Nov 2024) forecasts that more than 90% of MFA transactions will run via FIDO passkey by 2027 — the report is paywalled and not publicly linkable, but its direction matches what major identity vendors are already shipping.

OAuth 2.1 plus MCP-style flows will be expected for anything an AI agent can call. If your API has no agent-auth story by 2027, you will be integrating one under pressure rather than by design.

Edge-first auth pipelines — JWT verification at ingress, JWKS cached at the PoP — are moving from an optimization to the assumed baseline in new framework templates. Finally, workforce and customer identity continue to converge on the same standards (WebAuthn, OAuth 2.1, OIDC), narrowing the historical CIAM/IAM split so the same token formats and recovery flows serve both audiences.

Speculative but worth watching

FedCM. Chrome 117+ ships full support, and Google made FedCM mandatory for One Tap and the Sign-In With Google button in August 2025 (Privacy Sandbox blog⁠). Firefox paused its implementation and Safari has no announced plans, so FedCM is Chromium-first rather than universal — plan for it as a progressive enhancement, not a cross-browser replacement for redirect-based federation.

DPoP and sender-constrained tokens. RFC 9449⁠ defines Demonstrating Proof of Possession, and FAPI 2.0 makes DPoP or mTLS mandatory for financial-grade flows. Expect sender-constrained tokens to spread beyond banking as edge deployments make replay attacks cheaper to attempt.

Continuous / risk-based re-authentication. Market-size forecasts vary widely across research firms with no convergence, so trust the direction — strong projected growth through 2030 — rather than any single headline number. Microsoft's Continuous Access Evaluation is a concrete productized example already in broad deployment.

Standardized agent identity and delegation beyond OAuth 2.1. Drafts to track: IETF WIMSE architecture⁠, OIDC-A⁠, and Agentic JWT⁠. The NIST AI Agent Standards Initiative launched in February 2026, and SPIFFE/SPIRE remains the practical choice for workload identity of agents inside a cluster.

Credential portability. CXP and CXF adoption across major password managers would end today's passkey lock-in across ecosystems (Corbado overview⁠).

Deepfake-driven changes to identity verification. Gartner forecasts that 30% of enterprises will consider identity verification and authentication solutions unreliable in isolation due to deepfakes by 2026 (Gartner press release⁠). Expect layered liveness and behavioral signals, not a single silver-bullet check.

EU Digital Identity Wallet (eIDAS 2.0). The regulation's derived deadline is roughly 21 November 2026 for member states to offer wallets to citizens (Regulation (EU) 2024/1183⁠), which will reshape consumer identity UX across Europe.

Post-quantum cryptography migration. PQC for authentication — hybrid signature schemes, new JOSE algorithms — is starting to surface on 2027-2028 roadmaps. Near-term impact on most application auth stacks is limited, but it is worth tracking in your supply chain.

What teams should do now

Adopt passkey-primary authentication wherever the user base and recovery flows allow it. Design auth flows with agent principals in mind — scoped tokens, audience restrictions, revocation — even if you do not have agents in production yet. Verify tokens at the edge by default on new projects so the architectural cost is paid upfront rather than retrofitted later. Finally, choose providers and libraries whose public roadmap aligns with these directions; swapping an IdP later is expensive.

FAQ