# Authentication Trends in 2026: Passkeys, AI Agents, and Edge - Part 4 > Part 4 of 4. Start with [Authentication Trends in 2026: Passkeys, AI Agents, and Edge](https://clerk.com/articles/authentication-trends-in-2026-passkeys-ai-agents-and-edge.md). # Authentication Trends in 2026: Passkeys, AI Agents, and Edge - Part 4 _This is the final part of a four-part series on 2026 authentication trends. After exploring passkeys, AI agent identity, and edge verification in previous installments, this part focuses on practical implementation using Clerk, compares modern authentication providers, and looks ahead to the trends shaping 2027 and 2028._ ## 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](https://clerk.com/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](https://clerk.com/docs/guides/development/machine-auth/m2m-tokens.md) in two formats: JWT (verified locally for free against the instance public key) and [opaque](https://clerk.com/glossary/opaque-token.md) (verified over the network, revocable). The February 2026 changelog entry introduced the JWT format explicitly for stateless verification at the edge ([changelog](https://clerk.com/changelog/2026-02-24-m2m-jwt-tokens.md)). For AI coding workflows, Clerk publishes a remote MCP server (in public beta) at `mcp.clerk.com/mcp` that serves SDK snippets to AI coding assistants ([changelog](https://clerk.com/changelog/2026-01-20-clerk-mcp-server.md), [docs](https://clerk.com/docs/guides/ai/mcp/clerk-mcp-server.md)). 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](https://clerk.com/docs/expressjs/guides/ai/mcp/build-mcp-server.md). The backend SDK is, in Clerk's own phrasing, _"built for Node.js/V8 isolates (Cloudflare Workers, Vercel Edge Runtime, etc.)"_ ([docs](https://clerk.com/docs/guides/development/sdk-development/backend-only.md)). Combined with `clerkMiddleware()` at the `proxy.ts` layer in [Next.js 16](https://nextjs.org/blog/next-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](https://clerk.com/blog/series-c.md)). 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](https://github.com/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](https://clerk.com/docs/guides/development/migrating/overview.md) and [exporting users guide](https://clerk.com/docs/deployments/exporting-users.md) for the end-to-end flow. ### Setting up passkey-first authentication Enabling passkeys starts in the Clerk Dashboard under [User & authentication → Passkeys](https://dashboard.clerk.com/~/user-authentication/user-and-authentication?user_auth_tab=passkeys). Once the strategy is on, Clerk's prebuilt `` and `` 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: ```tsx '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 } ``` 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](https://clerk.com/docs/guides/development/custom-flows/authentication/passkeys.md) covers registration and sign-in, while the [sign-up and sign-in options guide](https://clerk.com/docs/guides/configure/auth-strategies/sign-up-sign-in-options.md#passkeys) documents 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 took effect March 16, 2026: $0.001 per token creation and $0.00001 per opaque verification, with the first 2,500 creations and 100,000 verifications each month free; JWT verification is always free ([changelog](https://clerk.com/changelog/2026-02-24-m2m-jwt-tokens.md), [pricing](https://clerk.com/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. ```ts 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](https://clerk.com/docs/guides/development/machine-auth/overview.md) 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](https://clerk.com/docs/guides/how-clerk-works/overview.md). **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](https://clerk.com/docs/guides/development/sdk-development/backend-only.md)). 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](https://github.com/panva/jose)). ```ts // 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](https://clerk.com/docs/guides/organizations/overview.md) 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](https://clerk.com/glossary/single-sign-on-sso.md) connection. Enterprise SSO is Pro+ only; each app includes one connection, with additional connections metered on a volume-graduated scale from $75/mo down to $15/mo each ([pricing](https://clerk.com/pricing)). The B2B Authentication add-on (the Enhanced tier, $100/mo or $85/mo billed annually) includes 100 monthly-retained organizations and unlocks unlimited organization members, enterprise-connection-to-organization linking, custom roles and rolesets, and verified domains with automatic invitations. 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](https://clerk.com/glossary/multi-tenancy.md) 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`. | Provider | Passkeys | M2M / agent tokens | OAuth/OIDC for agent flows | Documented MCP-specific support | Edge runtime | B2B orgs | Enterprise SSO | TS SDKs | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------ | | Clerk | Yes (Pro+; Hobby excluded) | Yes — JWT (free verify) + opaque ($0.00001/verify) | Yes — OAuth/OIDC IdP configurable while building an MCP server | Remote MCP server at `mcp.clerk.com/mcp` for SDK snippets; general-purpose MCP authorization server with PRM endpoints for third-party clients: Not documented | Yes — `@clerk/backend` built for "Node.js/V8 isolates (Cloudflare Workers, Vercel Edge Runtime, etc.)"; `proxy.ts` + `clerkMiddleware()` | Yes — first-class organizations; B2B Authentication add-on $100/mo ($85/mo annual) | Pro+ only, 1 connection included, overage $75→$15/mo each by volume | Yes — TypeScript-first across Node, edge, mobile | | Auth0 (Okta CIC) | Yes — all tiers | [M2M quotas: 1K (Free/Essentials), 5K (Professional); add-ons $10–$30/mo](https://auth0.com/pricing) | Token Vault for user-delegated API tokens | GA — Auth for MCP (GA May 2026); Auth0 for AI Agents GA Nov 2025 | Not documented at URLs audited | B2B Essentials/Professional: unlimited orgs | [Metered: Essentials 3 included, Professional 5 included; add-on $100/mo per connection](https://auth0.com/pricing) | Yes — Node/TS SDKs documented | | Okta Workforce Identity | Yes — FIDO2/passkeys via Okta Identity Engine | Yes — OAuth 2.0 client credentials | Yes — OIDC/OAuth core | GA — Okta for AI Agents (GA 30 Apr 2026); Okta MCP Server for identity admin documented | Not a runtime provider (IdP) | Workforce-oriented; not a SaaS "orgs" primitive | Core product; pricing not public | Yes — Node/TS SDKs | | WorkOS AuthKit | Yes — included at no separate charge | Yes — M2M Applications | Yes — AuthKit issues OAuth 2.1 tokens | Yes — spec-compatible OAuth authorization server for MCP with documented `/.well-known/oauth-protected-resource` | Not documented for AuthKit specifically | Organizations + Organization Policies | [SSO metered per-connection $50–$125/mo tiered; first 1M MAU free then $2,500/M](https://workos.com/pricing) | Yes | | Stytch | Yes — passkeys documented | Yes — M2M documented for services | Yes — Connected Apps turns an app into OAuth 2.0/OIDC IdP | Yes — documented MCP server authorization with PRM; OpenAI Apps SDK guide; full DCR + OAuth 2.1; Cloudflare Workers guide | Cloudflare Workers guide | B2B product exists | Enterprise SSO + SCIM | Yes | | Supabase Auth | Native (WebAuthn) — beta since May 2026 (earlier partner route superseded) | No documented M2M token product | Generic OAuth 2.1 server doc | Not documented as MCP authz server | Edge Functions product exists; Auth edge support not explicitly documented | No first-class orgs primitive | [SAML 2.0 SSO: Pro+ project-level, Team/Enterprise org-level; metered $0.015/SSO MAU](https://supabase.com/docs/guides/platform/manage-your-usage/monthly-active-users-sso) | Yes | | Firebase Auth / Identity Platform | No native passkey in Firebase Auth or Identity Platform docs | Custom auth flows only | OAuth via federated IdPs | Not documented | GCP-managed | No first-class orgs primitive | SAML/OIDC via Identity Platform upgrade | JS/TS SDKs | | AWS Cognito | Yes — [native passkeys (WebAuthn/FIDO2) since Nov 2024; Essentials tier+](https://aws.amazon.com/blogs/security/how-to-implement-password-less-authentication-with-amazon-cognito-and-webauthn/) ([API](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_WebAuthnConfigurationType.html)) | OAuth 2.0 client credentials | Yes | Not documented as MCP authz server | Lambda-backed | User pools, not SaaS orgs | SAML/OIDC federation | Node/TS SDK | | Azure Entra External ID + Entra Agent ID | [External ID methods page does not explicitly enumerate passkeys](https://learn.microsoft.com/en-us/entra/external-id/customers/concept-authentication-methods-customers); Entra Workforce supports FIDO2/passkeys broadly | OAuth 2.0 | Yes | Entra Agent ID (Preview) supports OAuth 2.0, MCP, and A2A; part of Microsoft Agent 365 | Azure-native | Workforce tenant model | SAML/OIDC core | TS SDK (MSAL) | | Keycloak | Yes — [native passkeys GA in 26.4.0](https://www.keycloak.org/docs/latest/release_notes/index.html) (WebAuthn Passwordless Policy) | OAuth 2.0 client credentials | Yes | Not documented as MCP authz server in core | Self-hosted (JVM) | Realms, not SaaS "orgs" | SAML/OIDC core, self-hosted | JS/TS adapter available | 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](https://docs.scalekit.com/) 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](https://www.descope.com/press-release/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](https://www.ory.com/docs/welcome) 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 additional connections metered from $75/mo down to $15/mo each by volume. #### 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 (GA since November 2025) and Token Vault for user-delegated API tokens. Auth0's MCP support (Auth0 Auth for MCP) reached general availability in May 2026. Enterprise connections are metered as add-ons above the tier inclusion. #### Okta Workforce Identity The enterprise IdP. Okta for AI Agents reached general availability on 30 April 2026, 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. Supabase added native passkey (WebAuthn) support on 28 May 2026; it is in beta and requires an explicit opt-in when initializing the client ([docs](https://supabase.com/docs/guides/auth/passkeys)), which largely supersedes the earlier route through partners such as Corbado or Passage. 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](https://authjs.dev/getting-started/authentication/webauthn) 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](https://clerk.com/glossary/role-based-access-control-rbac.md), or 2FA. [Lucia v3](https://github.com/lucia-auth/lucia/discussions/1714) 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 ([Google Sign-In with FedCM docs](https://developers.google.com/identity/sign-in/web/gsi-with-fedcm)). 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](https://datatracker.ietf.org/doc/html/rfc9449) 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](https://datatracker.ietf.org/doc/draft-ietf-wimse-arch-07), [OIDC-A](https://arxiv.org/html/2509.25974v1), and [Agentic JWT](https://arxiv.org/html/2509.13597v1). 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](https://www.corbado.com/blog/credential-exchange-protocol-cxp-credential-exchange-format-cxf)). **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](https://www.gartner.com/en/newsroom/press-releases/2024-02-01-gartner-predicts-30-percent-of-enterprises-will-consider-identity-verification-and-authentication-solutions-unreliable-in-isolation-due-to-deepfakes-by-2026)). 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](https://eur-lex.europa.eu/eli/reg/2024/1183/oj/eng)), 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. ## Conclusion Authentication in 2026 demands a stack that can handle passkey-primary consumer flows, scoped machine-to-machine tokens for AI agents, and stateless edge verification out of the box. As the build-versus-buy calculus shifts heavily toward managed providers, choosing a platform like Clerk that natively supports these primitives ensures your application remains secure, performant, and ready for the continued evolution of identity standards in the years ahead. ## FAQ **Why is it harder to build your own authentication in 2026?**\ A modern DIY stack now requires implementing WebAuthn for passkeys, an OAuth 2.1 authorization server for agents, edge-compatible token verification, and complex account recovery flows. The maintenance burden of keeping up with these evolving standards makes managed providers more cost-effective for most teams. **Does Clerk support machine-to-machine (M2M) tokens?**\ Yes. Clerk issues both JWT-format M2M tokens (which can be verified statelessly at the edge for free) and opaque M2M tokens (which require a network check but can be revoked instantly). **What should I look for when evaluating an authentication provider today?**\ Key criteria include native passkey support with robust recovery options, first-class support for agent identity (such as token exchange and MCP compatibility), edge runtime compatibility, and deep integration with your chosen frontend framework. ## In this series 1. [Authentication Trends in 2026: Passkeys, AI Agents, and Edge](https://clerk.com/articles/authentication-trends-in-2026-passkeys-ai-agents-and-edge.md) 2. [Authentication Trends in 2026: Passkeys, AI Agents, and Edge - Part 2](https://clerk.com/articles/authentication-trends-in-2026-passkeys-ai-agents-and-edge-2.md) 3. [Authentication Trends in 2026: Passkeys, AI Agents, and Edge - Part 3](https://clerk.com/articles/authentication-trends-in-2026-passkeys-ai-agents-and-edge-3.md) 4. **Authentication Trends in 2026: Passkeys, AI Agents, and Edge - Part 4** (you are here)