llms.txt snapshot
Captured by Entropy on 9/6/2026. This is the content Entropy fetched at scan time — not a live view of descope.com’s file, which may have changed since.
llms.txt
fetched from https://descope.com/llms.txt
# Descope > Identity and access management (IAM) platform that helps organizations add authentication, access control, and identity management to their customer apps, partner apps, AI agents, and MCP servers. Descope provides a no / low code, developer-first CIAM platform that helps organizations implement frictionless, secure identity journeys. The platform supports all modern authentication methods including passkeys, magic links, social logins, single sign-on (SSO), authenticator apps, Google One Tap, one-time passcodes (OTP), and traditional passwords. Organizations choose Descope because its drag & drop user journey workflows and multi-tenant, augmentation-friendly architecture help them implement and modify authentication journeys quickly without touching their codebase. Descope offers SDKs for all major frameworks and programming languages, making integration seamless regardless of your tech stack. Key Descope use cases include: - B2C CIAM: Consumer apps can simplify onboarding, improve conversions, and enhance account security with capabilities like passwordless auth, anonymous user tracking, A/B testing, native mobile auth, adaptive MFA, step-up authentication, and integrations with ecommerce platforms like Shopify, WordPress, and WooCommerce. - B2B CIAM: Business apps can meet enterprise requirements around SSO, SCIM, delegated administration, fine-grained authorization, and audit trails. - Augmentation: Organizations can add MFA, SSO, and MCP / AI agent authentication without changing their existing identity infrastructure. - Identity federation: Organizations with fragmented, hierarchical identity systems can unify authentication across multiple applications and identity providers while catering to each business unit's unique branding, auth, and access control requirements. - Fraud / account takeover prevention: Organizations facing credential-based attacks can add risk-based, phishing-resistant MFA with a variety of native risk factors as well as integrations with third-party connectors like reCAPTCHA, Forter, and Fingerprint. - AI agent authentication: Organizations building AI agents can connect them with third-party tools while offloading token management and storage. - MCP server authorization: Organizations building MCP servers can secure them with OAuth, consent management, Dynamic Client Registration (DCR) hardening controls, scope-based access control, and policy-based governance. ## Key Pages - [Pricing | Descope](https://www.descope.com/pricing): Explore pricing options for the Descope authentication and user management service. Start with our Free Forever tier and scale as you go. - [Security and Compliance | Descope](https://www.descope.com/security-compliance): Your auth is secure with us. Learn about Descope’s product security controls. - [Our company | Descope](https://www.descope.com/about): We want to make customer identity an enabler for every business. Helping applications move past passwords is the first step. - [Descope Connectors and Integrations](https://www.descope.com/integrations): Explore Descope connectors and integrations. Enrich your user journeys with third-party services, augment existing logins with federated authentication, and more. - [Descope | No / low code CIAM platform](https://www.descope.com/product): Customer authentication and identity management delivered as a developer-friendly service. Create frictionless and secure user journeys using no-code workflows, SDKs, or APIs. ## Developer Resources - [Documentation Home](https://docs.descope.com): Complete developer guides, API references, and tutorials - [Quickstart](https://docs.descope.com/getting-started): Integrate Descope into your app using your chosen web, mobile, and backend frameworks - [Descope Flows](https://docs.descope.com/flows): Build secure, customizable authentication and user journeys without writing code - [API Reference](https://docs.descope.com/api): Implement user authentication for your app using the Descope REST API - [Changelog](https://docs.descope.com/changelog): Latest product updates, new features, and bug fixes - [Community](https://www.descope.com/community): Join the Descope developer community for support and discussions - [Tutorials](https://docs.descope.com/tutorials/): Step-by-step tutorials for common authentication scenarios - [Open Source](https://www.descope.com/open-source): Open source tools and libraries from Descope - [GitHub](https://github.com/descope): Official Descope SDKs and sample applications ## Use Cases - [Identity provider for AI Agents and MCP Servers | Descope Agentic Identity Hub](https://www.descope.com/use-cases/ai): Add auth, access control, credential management, policies, and SSO to your AI agents and MCP servers with the Descope Agentic Identity Hub. - [Drag & Drop Passwordless Authentication Platform | Descope](https://www.descope.com/use-cases/passwordless-authentication): A passwordless authentication solution without the complexity. Descope lets you deploy secure passkeys, magic links, and more for your customer apps using no-code workflows. - [B2B CIAM for SaaS Applications | Descope](https://www.descope.com/use-cases/b2b-apps): Simplify B2B CIAM with Descope. Add secure SSO, MFA, and RBAC in minutes using a no-code platform built for enterprise-ready B2B applications. - [OAuth social logins for your app | Descope](https://www.descope.com/use-cases/oauth-social-logins): Enable your app users to log in with familiar third-party identity providers. Use our no-code editor, SDKs, or API to add social logins for your app. - [Drag & Drop Passkey Provider | Descope](https://www.descope.com/use-cases/passkeys): Bring your auth to the 21st century with drag & drop passkey authentication. Choose Descope as your passkey provider for unmatched simplicity and security. - [Drag & Drop Magic Link Auth Provider | Descope](https://www.descope.com/use-cases/magic-links): Delight users with one-click signup and login over email or SMS. Use our no-code editor, SDKs or API to set up magic link authentication for your app. - [Drag & Drop Customer SSO Provider | Descope](https://www.descope.com/use-cases/sso): Get your app enterprise-ready with single sign-on (SSO) authentication, self-service setup & seamless migration. Easily add SSO for SaaS apps using our no-code editor, SDKs, or API. - [CIAM Platform for Healthcare | Descope](https://www.descope.com/use-cases/healthcare): Deliver frictionless & secure user journeys with the Descope CIAM platform. Add auth, access control, MFA & SSO for patients, clinicians, and PBMs with no-code workflows. - [Customer MFA Provider | Descope](https://www.descope.com/use-cases/mfa): Descope is the MFA provider that scales with your business. Deploy secure, adaptive MFA that balances user experience with enterprise-grade protection. - [CIAM Platform for Insurance | Descope](https://www.descope.com/use-cases/insurance): Deliver frictionless & secure user journeys with the Descope CIAM platform. Add authentication, access control, MFA & SSO for your customers and brokers with no-code workflows. - [CIAM Platform for Retail | Descope](https://www.descope.com/use-cases/retail): Simplify onboarding, reduce friction, and prevent fraud with the Descope CIAM platform. Add auth and user management to your retail / e-commerce store with no-code workflows. - [Identity Orchestration Platform | Descope](https://www.descope.com/use-cases/identity-orchestration): Create seamless customer journeys with the Descope identity orchestration platform. Decouple identity logic from your app's codebase to grow faster without sacrificing security. - [Google One Tap Authentication Provider | Descope](https://www.descope.com/use-cases/one-tap): Log users in to your app with one tap. Use the Descope SDK to add Google One Tap with a few lines of code. - [Fraud and ATO Prevention for Your App | Descope](https://www.descope.com/use-cases/fraud-prevention): Secure your user journeys with MFA, bot protection, and step-up authentication from Descope. Reduce fraud, account takeover, and identity attacks. - [React Authentication Provider | Descope](https://www.descope.com/use-cases/react): Reduce user friction, prevent account takeover, and save dev time with the Descope CIAM platform. Add authentication, authorization, and identity management to React with no-code workflows. - [Identity federation for all your apps | Descope](https://www.descope.com/use-cases/identity-federation): Unify user identities across custom apps, support portals, COTS apps, internal apps, and more. Break identity silos with Descope. - [CIAM Platform for B2C Applications | Descope](https://www.descope.com/use-cases/b2c-apps): Add authentication, authorization, and identity management to your B2C app with no-code workflows. Simplify user onboarding, improve conversions, and prevent fraud with Descope. - [Drag & Drop Password Authentication Provider | Descope](https://www.descope.com/use-cases/passwords): Add password auth with drag-and-drop workflows, SDKs, and APIs. Descope is a password authentication provider offering unmatched simplicity and security. - [TOTP authentication for your app | Descope](https://www.descope.com/use-cases/totp-authenticator-apps): Build secure and intuitive login experiences with authenticator apps. Use our no-code editor, SDKs, or API to add TOTP authentication for your app. - [SMS & Email OTP Provider | Descope](https://www.descope.com/use-cases/otp): Easily add OTP authentication to your app without coding. Sign up for Descope, a flexible, drag & drop OTP auth provider. - [Biometric Authentication Provider | Descope](https://www.descope.com/use-cases/biometrics): Add WebAuthn-based biometric authentication to your app with a few lines of code. Sign up to Descope – a drag-and-drop biometric authentication provider. - [OIDC federated authentication for your app | Descope](https://www.descope.com/use-cases/oidc): Integrate Descope with your app using OIDC federated authentication. Add passwordless auth to existing logins. Unify identity across internal apps with OIDC SSO. - [nOTP WhatsApp Authentication Provider | Descope](https://www.descope.com/use-cases/notp): Add single-click WhatsApp authentication to your app with nOTP. Speed up onboarding, get accurate user identities, and bring SMS costs down to zero. ## Learning Center - [Biometric Authentication: A Comprehensive Guide](https://www.descope.com/learn/post/biometric-authentication): Learn what biometric authentication is, how it works, and its types, from fingerprint and face to iris and voice. See the benefits, risks, and how to add it. | [Full Content](https://www.descope.com/learn/post/biometric-authentication.md) - [What Is a Non-Human Identity (NHI)?](https://www.descope.com/learn/post/nhi): Learn what non-human identities (NHIs) are, how they differ from machine identities and AI agents, and M2M flow used to authenticate them. | [Full Content](https://www.descope.com/learn/post/nhi.md) - [What Is Cross-App Access (XAA) and How It Works](https://www.descope.com/learn/post/id-jag-cross-app-access): Learn how Cross-App Access (XAA) extends enterprise SSO to APIs and MCP servers, using short-lived, IdP-mediated tokens instead of static keys. | [Full Content](https://www.descope.com/learn/post/id-jag-cross-app-access.md) - [SIM Swapping: How the Attack Works and How to Protect Your Users](https://www.descope.com/learn/post/sim-swapping): A developer guide to SIM swapping: how the attack works, why it defeats SMS codes, and how to protect users with passwordless and phishing resistant auth. | [Full Content](https://www.descope.com/learn/post/sim-swapping.md) - [What Is Passwordless Authentication and How It Works](https://www.descope.com/learn/post/passwordless-authentication): Learn what passwordless authentication is, how it works, and its main methods, from magic links to passkeys. See the benefits and how to implement it in 2026. | [Full Content](https://www.descope.com/learn/post/passwordless-authentication.md) - [What Is an Authenticator App & How Does It Work](https://www.descope.com/learn/post/authenticator-app): Learn what an authenticator app is, how it works with TOTP codes, and how to set one up. Compare the best authenticator apps for two-factor authentication. | [Full Content](https://www.descope.com/learn/post/authenticator-app.md) - [What Is FIDO2 & How Does FIDO Authentication Work?](https://www.descope.com/learn/post/fido2): Learn what FIDO2 is, how FIDO authentication works, and how it enables passwordless login. See how FIDO2 differs from FIDO, U2F, and UAF standards. | [Full Content](https://www.descope.com/learn/post/fido2.md) - [What Is Authentication? Types, Methods & Best Practices](https://www.descope.com/learn/post/authentication): Learn what authentication is, how it works, and its main types. Compare password, MFA, passwordless, and adaptive methods, plus best practices for 2026. | [Full Content](https://www.descope.com/learn/post/authentication.md) - [What Is the Model Context Protocol (MCP) and How It Works](https://www.descope.com/learn/post/mcp): Learn more about MCP, the open source protocol developed by Anthropic to provide LLMs and AI agents a standardized way to connect with external data sources and tools. | [Full Content](https://www.descope.com/learn/post/mcp.md) - [What Is the Universal Commerce Protocol (UCP)?](https://www.descope.com/learn/post/ucp): Learn how the Universal Commerce Protocol (UCP) standardizes agentic transactions, including merchant discovery, checkout, and OAuth identity linking. | [Full Content](https://www.descope.com/learn/post/ucp.md) - [OTP Meaning: One-Time Password Uses and Benefits](https://www.descope.com/learn/post/otp): OTPs are a common user authentication method for consumers and enterprises. But what does OTP mean? Find out in this comprehensive guide. | [Full Content](https://www.descope.com/learn/post/otp.md) - [What Is Workload Identity Federation for AI Agents?](https://www.descope.com/learn/post/workload-identity-federation-for-agents): Learn how workload identity federation (WIF) eliminates static secrets for AI agents by exchanging cloud OIDC tokens for scoped credentials. | [Full Content](https://www.descope.com/learn/post/workload-identity-federation-for-agents.md) - [Credential Stuffing Explained + How to Prevent It](https://www.descope.com/learn/post/credential-stuffing): Credential stuffing attacks are on the rise, and they can affect any individual or organization. Learn how to protect against credential stuffing in this guide. | [Full Content](https://www.descope.com/learn/post/credential-stuffing.md) - [SAML Explained: How the SAML Protocol Works & Why It Matters](https://www.descope.com/learn/post/saml): SAML is one of the standards that can power single sign-on (SSO). But how does SAML work? Find out in this SAML protocol guide. | [Full Content](https://www.descope.com/learn/post/saml.md) - [Multi-Tenant Meaning: What is Multi-Tenancy and How Does It Work?](https://www.descope.com/learn/post/multi-tenancy): Learn how multi-tenancy models shape the costs, security, and operational characteristics of software platforms with Descope’s multi-tenancy definition guide. | [Full Content](https://www.descope.com/learn/post/multi-tenancy.md) - [What Is RBAC: Your Simple Guide](https://www.descope.com/learn/post/rbac): Knowing the RBAC definition and how it differs from other access control models can help you choose the best protocol for your team’s security. | [Full Content](https://www.descope.com/learn/post/rbac.md) - [What Is OAuth Token Exchange?](https://www.descope.com/learn/post/oauth-token-exchange): OAuth Token Exchange lets services swap an existing security token for one with a different audience, narrower scope, or delegation context. | [Full Content](https://www.descope.com/learn/post/oauth-token-exchange.md) - [What Is the OAuth Client Credentials Flow?](https://www.descope.com/learn/post/client-credentials-flow): The Client Credentials Grant Flow is the OAuth flow for machine-to-machine auth. Learn how it works, when to use it, and how it applies to AI agents. | [Full Content](https://www.descope.com/learn/post/client-credentials-flow.md) - [What Is Agentic Identity?](https://www.descope.com/learn/post/agentic-identity): An agentic identity represents an AI agent acting on a user’s behalf. Learn what makes it distinct from traditional machine and non-human identities. | [Full Content](https://www.descope.com/learn/post/agentic-identity.md) - [What Is SPIFFE and How Does It Work?](https://www.descope.com/learn/post/spiffe): SPIFFE is the open standard for workload identity in dynamic, distributed environments. Learn how SPIFFE IDs, SVIDs, and the Workload API function. | [Full Content](https://www.descope.com/learn/post/spiffe.md) ## Blog - [XAA vs. ID-JAG vs. EMA: What's the Difference?](https://www.descope.com/blog/post/xaa-vs-idjag-vs-ema): XAA, ID-JAG, and EMA describe the same capability at three layers: a pattern, an IETF draft, and an MCP extension. Learn which term to use and when. | [Full Content](https://www.descope.com/blog/post/xaa-vs-idjag-vs-ema.md) - [Descope vs Auth0 for AI Agent and MCP Authentication](https://www.descope.com/blog/post/descope-vs-auth0-ai-agent-mcp-auth): Compare Descope vs Auth0 for AI agent and MCP authentication. Explore agent identity, MCP authorization, credential vaulting, consent, and human oversight. | [Full Content](https://www.descope.com/blog/post/descope-vs-auth0-ai-agent-mcp-auth.md) - [SSO For Your Agents: Cross-App Access Support in Agentic Identity Hub](https://www.descope.com/blog/post/xaa): Let your customers manage agent access to your MCP server using existing IdPs. Provide short-lived, scoped tokens for your AI agents to access any MCP server. | [Full Content](https://www.descope.com/blog/post/xaa.md) - [Biometric Authentication Methods: Types, Benefits, and Examples](https://www.descope.com/blog/post/biometric-auth-methods): From fingerprints to facial recognition, biometric authentication methods are common for devices and services. Discover five different available technologies. | [Full Content](https://www.descope.com/blog/post/biometric-auth-methods.md) - [Best Customer MFA Solutions in 2026: Top 7 Compared](https://www.descope.com/blog/post/customer-mfa-solutions): Explore the best multi-factor authentication services and top MFA solutions. Compare leading MFA providers for customer apps, SaaS, and secure login experiences. | [Full Content](https://www.descope.com/blog/post/customer-mfa-solutions.md) - [How to Secure an AI Agent With LlamaIndex + Descope](https://www.descope.com/blog/post/llamaindex-descope-agent): Build a secure LlamaIndex agent using Descope. Learn how to implement scoped MCP tools, runtime credential management, OAuth, DCR, and auditable agent identity. | [Full Content](https://www.descope.com/blog/post/llamaindex-descope-agent.md) - [Fraud Detection in Authentication: Using Identity Signals to Stop Fraud at Login](https://www.descope.com/blog/post/fraud-detection-at-login): Fraud increasingly starts at login. See the identity signals, from breached credentials to device fingerprinting, that stop account takeover before it costs you. | [Full Content](https://www.descope.com/blog/post/fraud-detection-at-login.md) - [How to Build an Auth-Ready MCP Server With Next.js and Descope](https://www.descope.com/blog/post/auth-mcp-nextjs): A practical walkthrough of building an auth-ready MCP server with Next.js and Descope, including tips to help you save time and avoid common pitfalls. | [Full Content](https://www.descope.com/blog/post/auth-mcp-nextjs.md) - [How to Secure an AI Agent With Claude Agent SDK + Descope](https://www.descope.com/blog/post/secure-ai-agent-claude-descope): Build a secure AI agent with the Claude Agent SDK and Descope: vault credentials, verify session tokens, and enforce per-tool scopes without hardcoded secrets. | [Full Content](https://www.descope.com/blog/post/secure-ai-agent-claude-descope.md) - [Passkeys vs. Passwords: What’s the Difference?](https://www.descope.com/blog/post/passkeys-vs-passwords): Discover the differences between passkeys and passwords in this comprehensive comparison guide. | [Full Content](https://www.descope.com/blog/post/passkeys-vs-passwords.md) - [Descope vs Stytch: Comparisons and Use Cases](https://www.descope.com/blog/post/descope-vs-stytch): Compare Descope and Stytch for customer and agentic identity. See why teams choose Descope for unified B2C/B2B auth, self-service SSO, and predictable pricing. | [Full Content](https://www.descope.com/blog/post/descope-vs-stytch.md) - [The Descope MCP Server Is Available On Claude and ChatGPT](https://www.descope.com/blog/post/descope-mcp-server-claude-chatgpt): The Descope MCP Server is now available as a Claude Connector and a ChatGPT Plugin. Learn how to build and manage identity through an AI agent. | [Full Content](https://www.descope.com/blog/post/descope-mcp-server-claude-chatgpt.md) - [Descope Named in the 2026 Gartner® Hype Cycle™ for Fraud and Financial Crime Prevention](https://www.descope.com/blog/post/2026-gartner-hype-cycle-fraud-financial-crime-prevention): Descope is a Sample Vendor in the 2026 Gartner Hype Cycle for Fraud and Financial Crime Prevention for CIAM for AI Agents and Journey-Time Orchestration. | [Full Content](https://www.descope.com/blog/post/2026-gartner-hype-cycle-fraud-financial-crime-prevention.md) - [Auth and Identity Tips for Pharmacy Benefit Managers](https://www.descope.com/blog/post/authentication-pharmacy-benefit-managers): Pharmacy benefit managers juggle members, pharmacies, employers, and brokers across scrutinized portals. Learn how modern auth cuts PBM fraud and friction | [Full Content](https://www.descope.com/blog/post/authentication-pharmacy-benefit-managers.md) - [Add External Tokens to Your iOS + Firebase App](https://www.descope.com/blog/post/external-tokens-ios-firebase): Keep Firebase as your iOS backend while adding passkeys and social login with Descope Flows and External Tokens. | [Full Content](https://www.descope.com/blog/post/external-tokens-ios-firebase.md) - [How to Add External Tokens to Your Android + Firebase App](https://www.descope.com/blog/post/android-firebase-external-token): Keep Firebase as your Android backend while adding passkeys and social login with Descope Flows and External Tokens. | [Full Content](https://www.descope.com/blog/post/android-firebase-external-token.md) - [What the July 2026 MCP Spec Revision Means for Identity](https://www.descope.com/blog/post/july-2026-mcp-revision): The July 2026 MCP spec revision removes sessions, hardens OAuth, and makes Enterprise-Managed Authorization official. Here’s what changes for MCP identity. | [Full Content](https://www.descope.com/blog/post/july-2026-mcp-revision.md) - [Diving Into the MCP Authorization Specification](https://www.descope.com/blog/post/mcp-auth-spec): Learn about the MCP spec adding authorization and how to add it to your MCP servers. Explore best practices to minimize security risks and maximize performance. | [Full Content](https://www.descope.com/blog/post/mcp-auth-spec.md) - [Best SSO Providers in 2026: How to Choose the Right One for Your App](https://www.descope.com/blog/post/customer-sso-solutions): Compare the best SSO providers for 2026: Descope, Auth0, Cognito, Entra, WorkOS, and more, ranked on multi-tenancy, pricing, and developer experience. | [Full Content](https://www.descope.com/blog/post/customer-sso-solutions.md) - [Best CIAM Solutions in 2026: How to Choose the Right Platform for Your App](https://www.descope.com/blog/post/ciam-solutions): Compare the best CIAM solutions for 2026. See how Descope, Auth0, Cognito, Stytch, and more stack up on multi-tenancy, agent identity, and developer experience. | [Full Content](https://www.descope.com/blog/post/ciam-solutions.md) ## Customer Stories - [Elementor Customer Story | Descope](https://www.descope.com/customers/elementor): Learn how Elementor, the world’s leading WordPress website builder, uses Descope to deliver managed authentication while preserving their pixel perfect design. | [Full Content](https://www.descope.com/customers/elementor.md) - [Token Security Customer Story | Descope](https://www.descope.com/customers/token-security): See why Token Security chose Descope for self-service SSO, rapid SCIM delivery, tenant-scoped RBAC, and MCP auth. | [Full Content](https://www.descope.com/customers/token-security.md) - [Octave Customer Story | Descope](https://www.descope.com/customers/octave): Octave needed auth that worked the same for users and its MCP server. See how Descope unified social login, SSO, and MCP auth for Octave’s agentic GTM brain. | [Full Content](https://www.descope.com/customers/octave.md) - [Linktree Customer Story | Descope](https://www.descope.com/customers/linktree): Learn why the category-leading link-in-bio platform chose Descope to modernize and scale authentication for over 70 million users. | [Full Content](https://www.descope.com/customers/linktree.md) - [You.com Customer Story | Descope](https://www.descope.com/customers/you-com): You.com needed a solution to simultaneously meet their B2C, B2B, and MCP authentication needs, and this is how Descope helped them build it. | [Full Content](https://www.descope.com/customers/you-com.md) - [GoFundMe Customer Story | Descope](https://www.descope.com/customers/gofundme): Learn why GoFundMe chose to switch out their home-grown authentication stack for Descope and migrate millions of users towards a more seamless and secure experience while saving developer time. | [Full Content](https://www.descope.com/customers/gofundme.md) - [6sense Customer Story | Descope](https://www.descope.com/customers/6sense): Learn why 6sense chose Descope to power enterprise-grade authentication, multi-tenant SSO, and self-service SSO onboarding. | [Full Content](https://www.descope.com/customers/6sense.md) - [Vega Customer Story | Descope](https://www.descope.com/customers/vega): Here’s how Descope helped Vega move upmarket with B2B auth, SSO / SCIM, RBAC, and M2M auth without pulling engineering focus away from their core product. | [Full Content](https://www.descope.com/customers/vega.md) - [Daylight Security Customer Story | Descope](https://www.descope.com/customers/daylight-security): Learn how Daylight Security uses Descope for both B2B auth and securing their customer-facing MCP server, letting customers maintain role-based access everywhere. | [Full Content](https://www.descope.com/customers/daylight-security.md) - [Cequence Security Customer Story | Descope](https://www.descope.com/customers/cequence-security): Cequence Security needed a customer and agentic authentication solution that wouldn’t divert valuable engineering resources away from their core product vision. Here’s how Descope helped. | [Full Content](https://www.descope.com/customers/cequence-security.md) - [Collabrios Health Customer Story | Descope](https://www.descope.com/customers/collabrios-health): Learn why Collabrios Health chose Descope to power tenant-aware B2B2C authentication, SSO, and secure access control for tens of thousands of EHR users. | [Full Content](https://www.descope.com/customers/collabrios-health.md) - [WisdomAI Customer Story | Descope](https://www.descope.com/customers/wisdomai): Learn why WisdomAI chose Descope to power authentication for their B2B customers, MCP server, and AI agents. | [Full Content](https://www.descope.com/customers/wisdomai.md) - [Echelon Customer Story | Descope](https://www.descope.com/customers/echelon): Learn why Echelon chose Descope to power B2B authentication, SSO, and ServiceNow token management for their enterprise customers. | [Full Content](https://www.descope.com/customers/echelon.md) - [Reco Customer Story | Descope](https://www.descope.com/customers/reco): Learn how Reco, a dynamic SaaS security platform, uses Descope to simplify authentication and deliver rapid customer onboarding without spending dev cycles. | [Full Content](https://www.descope.com/customers/reco.md) - [7AI Customer Story | Descope](https://www.descope.com/customers/7ai): Learn how agentic security provider 7AI leveraged Descope’s federated identity and self-service SSO to deliver enterprise-grade auth for upmarket customers. | [Full Content](https://www.descope.com/customers/7ai.md) - [GoodRx Customer Story | Descope](https://www.descope.com/customers/goodrx): Learn why GoodRx migrated tens of millions of users to Descope to modernize their CIAM stack, provide native mobile auth experiences, and save developer time. | [Full Content](https://www.descope.com/customers/goodrx.md) - [Databricks Customer Story | Descope](https://www.descope.com/customers/databricks): Learn why the Databricks identity team chose Descope to unify authentication flows across five user portals with zero engineering lift. | [Full Content](https://www.descope.com/customers/databricks.md) - [BalkanID Customer Story | Descope](https://www.descope.com/customers/balkanid): Learn how BalkanID completed a full migration from Ory to Descope in three weeks, gaining self-service SSO capabilities and powerful low-code authentication flows. | [Full Content](https://www.descope.com/customers/balkanid.md) - [Pieces Customer Story | Descope](https://www.descope.com/customers/pieces): Pieces needed an authentication provider that could scale effortlessly across every customer touchpoint without sapping developer time. Here's how Descope helped. | [Full Content](https://www.descope.com/customers/pieces.md) - [Owens & Minor Customer Story | Descope](https://www.descope.com/customers/owens-minor): Owens & Minor needed a flexible authentication solution to handle passwordless and enterprise SSO flows without sapping developer time. Here's how Descope helped. | [Full Content](https://www.descope.com/customers/owens-minor.md) - [Branch Customer Story | Descope](https://www.descope.com/customers/branch): Learn how Branch Insurance used Descope to augment their existing authentication with passkeys, reducing auth-related support ticket volumes by 50% in the process. | [Full Content](https://www.descope.com/customers/branch.md) - [Notch Customer Story | Descope](https://www.descope.com/customers/notch): Notch needed a customer identity solution that was quick to deploy and flexible enough to support startups and enterprises. Here’s why they chose Descope. | [Full Content](https://www.descope.com/customers/notch.md) - [SmithRx Customer Story | Descope](https://www.descope.com/customers/smithrx): Learn why SmithRx chose Descope to unify identities across multiple external-facing portals and implement fine-grained access control. | [Full Content](https://www.descope.com/customers/smithrx.md) - [Navan Customer Story | Descope](https://www.descope.com/customers/navan): Navan needed fast, frictionless, and flexible magic link based MFA to enhance user security. Here is how Descope helped them go to prod in 4 days. | [Full Content](https://www.descope.com/customers/navan.md) - [Descope Customer Story | Auth at Concert Scale](https://www.descope.com/customers/auth-at-concert-scale): Learn why one of the largest producers of live music events in the world chose Descope to implement email OTP authentication for two flagship UK concerts. | [Full Content](https://www.descope.com/customers/auth-at-concert-scale.md) - [GradRight Customer Story | Descope](https://www.descope.com/customers/gradright): Learn why GradRight chose Descope to stop bots attacks on login flows and implement personalized user journeys for students, banks, and universities. | [Full Content](https://www.descope.com/customers/gradright.md) - [CARS24 Customer Story | Descope](https://www.descope.com/customers/cars24): Learn why CARS24 chose Descope across five applications (and counting) to provide a secure, personalized login experience for internal users and partners. | [Full Content](https://www.descope.com/customers/cars24.md) ## Press Releases - [Descope Unveils Cross-App Access (XAA) Support, Letting Enterprises Manage AI Agent Access With Their Existing Identity Providers](https://www.descope.com/press-release/cross-app-access-xaa-support): Organizations can now use Descope to validate ID-JAG tokens from their customers' identity providers, issue ID-JAG tokens for their own internal agents, and provide self-service XAA setup to tenant admins. | [Full Content](https://www.descope.com/press-release/cross-app-access-xaa-support.md) - [Descope Unveils Agentic Identity Hub 2.5 With Enhanced Policy Controls and Flexible Ecosystem Integrations](https://www.descope.com/press-release/agentic-identity-hub-2.5): Organizations can now use Descope to support identity for autonomous agents, enable human-in-the-loop flows, secure backend APIs for agent use, and augment existing user authentication systems. | [Full Content](https://www.descope.com/press-release/agentic-identity-hub-2.5.md) - [Descope Announces No-Code User Journey Orchestration Using Third-Party Connectors](https://www.descope.com/press-release/connectors): Drag-and-drop actions from services such as Google reCAPTCHA Enterprise and Traceable in your user journeys for fraud prevention, risk-based MFA, localization, and more. | [Full Content](https://www.descope.com/press-release/connectors.md) - [Descope Named to Rising in Cyber 2026 List of Top Cybersecurity Startups](https://www.descope.com/press-release/rising-in-cyber-2026): CISO-Voted List Recognizes the 30 Private Cybersecurity Companies Shaping Enterprise Security in the Age of AI. | [Full Content](https://www.descope.com/press-release/rising-in-cyber-2026.md) - [Descope Unveils Agentic Identity Hub 2.0, the Most Comprehensive Identity Platform for AI Agents and MCP Servers](https://www.descope.com/press-release/agentic-identity-hub-2.0): Organizations can now use Descope as a dedicated auth and access control layer for AI agents and MCP servers with ephemeral credentials, tool-level access control, and enterprise-grade policy controls. | [Full Content](https://www.descope.com/press-release/agentic-identity-hub-2.0.md) - [Descope Survey Shows 82% of Organizations Experience Negative Business Impact Due to Customer Identity Issues](https://www.descope.com/press-release/2025-state-of-customer-identity): Third-party survey of 400+ decision makers finds CIAM in a state of transformation as organizations navigate password struggles, overworked developers, and agentic identity. | [Full Content](https://www.descope.com/press-release/2025-state-of-customer-identity.md) - [Descope Named a Leader in the 2025 Frost Radar™ for Non-Human Identity Solutions](https://www.descope.com/press-release/frost-radar-nhi-2025): Recognition as a Leader in the Frost Radar for NHI Solutions underscores Descope’s innovative approach to identity management for agentic AI and MCP ecosystems. | [Full Content](https://www.descope.com/press-release/frost-radar-nhi-2025.md) - [Descope Recognized as a CRN® 2025 Stellar Startup](https://www.descope.com/press-release/crn-stellar-startups-2025): Recognition as a Stellar Startup the Security category validates Descope’s vision to secure customer & agentic identity journeys for organizations of all sizes. | [Full Content](https://www.descope.com/press-release/crn-stellar-startups-2025.md) - [Descope Launches Developer-First Authentication and User Management Platform](https://www.descope.com/press-release/seed-funding): Descope today announced it has raised $53M in seed funding and emerged from stealth to launch a frictionless, secure, and developer-friendly passwordless authentication and user management platform. | [Full Content](https://www.descope.com/press-release/seed-funding.md) - [Descope Announces App Dev Partner Program to Expand Access to Customer and Agentic IAM](https://www.descope.com/press-release/app-dev-partner-program): Descope's App Dev Partner Program is designed to support application development service providers in delivering reduced user friction, ATO protection & secure agentic AI / MCP adoption for their customers. | [Full Content](https://www.descope.com/press-release/app-dev-partner-program.md) - [Descope Extends and Closes Seed Round With $88M Total Funding, Announces Advisory Board](https://www.descope.com/press-release/seed-funding-advisory-board): $35M in new funding from existing investors enables Descope to continue simplifying and securing customer, partner, and agentic identities for organizations of all sizes. | [Full Content](https://www.descope.com/press-release/seed-funding-advisory-board.md) - [Token Security and Descope Unite with Cybersecurity Leaders to Launch Security Guide for Agentic AI Adoption](https://www.descope.com/press-release/ai-security-guide): The comprehensive framework in the guide co-authored by Token Security, Descope, and the CISO community is designed to help organizations adopt agentic AI securely. | [Full Content](https://www.descope.com/press-release/ai-security-guide.md) - [Descope Enhances Agentic Identity Hub To Provide Policy-Based Security Guardrails for AI Agents](https://www.descope.com/press-release/agentic-identity-control-plane): The industry-first Agentic Identity Control Plane delivers scope-based access control, monitoring, and identity management across the AI agent lifecycle. | [Full Content](https://www.descope.com/press-release/agentic-identity-control-plane.md) - [Descope Achieves FedRAMP High Authorization](https://www.descope.com/press-release/fedramp): Descope's FedRAMP High Authorization enables government agencies and organizations requiring FedRAMP-authorized software to drive frictionless & secure IAM for external identities. | [Full Content](https://www.descope.com/press-release/fedramp.md) - [Descope Named to Redpoint’s InfraRed 100](https://www.descope.com/press-release/redpoint-infrared-100-2025): Descope, the drag & drop external IAM platform, proudly announces its recognition on the Redpoint InfraRed 100 for the second time. | [Full Content](https://www.descope.com/press-release/redpoint-infrared-100-2025.md) - [Descope Named to Rising in Cyber 2025 List of Top Cybersecurity Startups](https://www.descope.com/press-release/rising-in-cyber-2025): Selected by CISOs and leading investors, the Rising in Cyber list recognizes the 30 startups shaping the future of security. | [Full Content](https://www.descope.com/press-release/rising-in-cyber-2025.md) - [Descope Announces Agentic Identity Hub to Enable Secure, Standards-Based AI Agent Connectivity](https://www.descope.com/press-release/agentic-identity-hub): New capabilities help organizations make their apps and APIs agent-compatible, securely connect AI agents to external tools, and secure remote MCP servers with enterprise-grade authorization. | [Full Content](https://www.descope.com/press-release/agentic-identity-hub.md) - [Descope Announces New Capabilities to Help Ecommerce Companies Deliver Omnichannel User Experiences](https://www.descope.com/press-release/ecommerce-omnichannel): Anonymous user tracking, native mobile flows, and ecommerce platform integrations help ecommerce apps achieve 360 customer view without sacrificing security. | [Full Content](https://www.descope.com/press-release/ecommerce-omnichannel.md) - [Descope Named a 2025 KuppingerCole Rising Star in CIAM and Passwordless Authentication](https://www.descope.com/press-release/2025-kuppingercole-rising-star): Recognition in KuppingerCole's Rising Star Report underscores Descope’s rapid customer adoption across geos, industries, and use cases. | [Full Content](https://www.descope.com/press-release/2025-kuppingercole-rising-star.md) - [Descope Announces Partner Program to Expand Access to Flexible, Easy to Use CIAM](https://www.descope.com/press-release/partner-program): The Descope Partner Program is designed to support partners in delivering reduced user friction, ATO protection, and engineering time savings for their customers. | [Full Content](https://www.descope.com/press-release/partner-program.md)
llms-full.txt
fetched from https://descope.com/llms-full.txt · truncated at capture (file exceeded the snapshot size cap)
# Descope
> Identity and access management (IAM) platform that helps organizations add authentication, access control, and identity management to their customer apps, partner apps, AI agents, and MCP servers.
Descope provides a no / low code, developer-first CIAM platform that helps organizations implement frictionless, secure identity journeys. The platform supports all modern authentication methods including passkeys, magic links, social logins, single sign-on (SSO), authenticator apps, Google One Tap, one-time passcodes (OTP), and traditional passwords.
Organizations choose Descope because its drag & drop user journey workflows and multi-tenant, augmentation-friendly architecture help them implement and modify authentication journeys quickly without touching their codebase. Descope offers SDKs for all major frameworks and programming languages, making integration seamless regardless of your tech stack.
Key Descope use cases include:
- B2C CIAM: Consumer apps can simplify onboarding, improve conversions, and enhance account security with capabilities like passwordless auth, anonymous user tracking, A/B testing, native mobile auth, adaptive MFA, step-up authentication, and integrations with ecommerce platforms like Shopify, WordPress, and WooCommerce.
- B2B CIAM: Business apps can meet enterprise requirements around SSO, SCIM, delegated administration, fine-grained authorization, and audit trails.
- Augmentation: Organizations can add MFA, SSO, and MCP / AI agent authentication without changing their existing identity infrastructure.
- Identity federation: Organizations with fragmented, hierarchical identity systems can unify authentication across multiple applications and identity providers while catering to each business unit's unique branding, auth, and access control requirements.
- Fraud / account takeover prevention: Organizations facing credential-based attacks can add risk-based, phishing-resistant MFA with a variety of native risk factors as well as integrations with third-party connectors like reCAPTCHA, Forter, and Fingerprint.
- AI agent authentication: Organizations building AI agents can connect them with third-party tools while offloading token management and storage.
- MCP server authorization: Organizations building MCP servers can secure them with OAuth, consent management, Dynamic Client Registration (DCR) hardening controls, scope-based access control, and policy-based governance.
## Learning Center
### [Biometric Authentication: A Comprehensive Guide](https://www.descope.com/learn/post/biometric-authentication)
*Full content: [https://www.descope.com/learn/post/biometric-authentication.md](https://www.descope.com/learn/post/biometric-authentication.md)*
Biometric authentication validates a person’s identity using a unique physical or behavioral trait—such as a fingerprint, face, iris, or voice—instead of a password. It belongs to the “something you are” or “inherence” authentication factor, and it’s harder to guess, steal, or share than a password or PIN.
You can unlock your iPhone with your face. Your bank verifies million-dollar transfers with a thumb scan. Yet somehow, countless sensitive accounts still rely on traditional credentials, which can be as weak as “Password123!” According to the [2026 Verizon Data Breach Investigations Report](<https://www.descope.com/blog/post/verizon-dbir-2026>), credential abuse still appears at some point in 39% of breaches, more than any other technique the report tracks, highlighting an ongoing need to evolve beyond legacy [authentication techniques](<https://www.descope.com/learn/post/authentication-types>).
Enter biometric authentication, which identifies users based on *who* they are rather than *what* they know, and is quickly becoming the gold standard in user authentication. More than [50% of users](<https://www.aware.com/press-releases/new-consumer-report-from-aware-reveals-widespread-trust-in-biometrics/>) now authenticate with biometrics daily, and iProov’s 2026 research found that 55% of consumers say they’d be more likely to use government services online if a secure biometric login were available.
But what is biometric authentication, how does it work, and is it actually that safe? Let’s find out if it’s the right authentication method for your app, website, or software.
#### Main points
- **Biometric authentication shifts the paradigm.** Instead of relying on knowledge or possession, it verifies users by who they are, making it harder to fake, steal, or forget.
- **Users want convenience without compromise.** Adoption is soaring because biometrics offer fast, secure experiences that reduce friction and abandonment.
## At a glance
- Biometric authentication verifies identity using a unique physical or behavioral trait, such as a fingerprint, face, iris, or voice, rather than something the user has to remember.
- It belongs to the “something you are” or “inherence” authentication factor and is hard to guess, steal, or share, which makes it strong against phishing and password reuse.
- The main methods are fingerprint, facial, iris and retina, and voice recognition, with multimodal approaches that combine two or more for higher assurance.
- Good systems store biometrics as a mathematical template rather than the raw image. They also keep the trait on the user’s device, as passkeys do, so the biometric itself is never sent to a server.
- For apps, biometric login is delivered through passkeys and the WebAuthn standard, where a fingerprint or face unlocks a device-bound key.
## Quick facts about biometric authentication
| **What it is** | Verifying identity with a unique physical or behavioral trait instead of a password |
| **Which factor it belongs to** | “Something you are” or the “inherence” factor |
| **Main types** | Fingerprint, facial, iris and retina, and voice recognition, plus multimodal and emerging methods |
| **How it is stored** | As a mathematical template, not the raw image, ideally kept on the user’s device |
| **Key benefit** | Nothing to remember, phish, or reuse across sites |
| **Main risk** | A compromised trait can’t be reset like a password, so template protection and on-device storage matter |
## What is biometric authentication?
Biometric authentication is a type of inherence-based authentication that validates a person’s identity using their unique biological or behavioral characteristics. These characteristics make up “what” or “who” you are, often referred to as the inherence factor in authentication lingo. This shift from “what you know” (knowledge factor) or “what you have” (possession factor) represents a move from vulnerable, perishable credentials to intrinsic human traits that are virtually impossible to replicate.
The core principles of biometric authentication are as follows:
- **Uniqueness:** Every person’s biometric traits are distinct. Fingerprint patterns, facial geometry, iris structure, and vocal characteristics are as individual as DNA. Even identical twins have [different fingerprints and iris patterns](<https://www.cnn.com/2015/12/04/health/unique-body-parts>)!
- **Permanence (or immutability):** Unlike [passwords](<https://www.descope.com/learn/post/password-authentication>), biometric traits don’t change significantly over time. Barring serious injury, biometrics remain consistent throughout life, making them reliable long-term identifiers.
- **Measurability:** Advanced sensors can capture and digitize these characteristics into strings of data. While humans might compare fingerprints visually, machines verify biometrics against what are essentially long sets of numbers, which both protects biometric data from being copied, and ensures a highly precise comparison.
- **Universality:** Nearly everyone possesses the basic biometric traits (fingerprints, face, voice) necessary to authenticate, making the technology widely applicable across global populations.
- **Acceptability:** Ideally, the collection and use of biometric data doesn’t raise concerns or objections from users; it should be convenient and unintrusive (e.g., not a DNA swab).
Consider a real-world example of biometric authentication in action using Apple’s Face ID. When first set up, infrared sensors project over 30,000 invisible dots to form a depth map of the user’s unique face, measuring the precise distance between the eyes, the curve of the nose, and the contours of the cheekbones.
This creates a mathematical model stored in a dedicated part of the user’s device called the [Secure Enclave](<https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/web>). Each time the user looks at their phone to unlock it, the system captures a new scan, compares it to the original stored template, and grants access when everything matches.
## How does biometric authentication work?
Biometric authentication works by capturing a physical or behavioral trait with a sensor, converting it into a protected mathematical template, storing that template securely, and comparing it against a fresh reading each time the user tries to log in. Using biometrics for authentication this way means the system never needs to store or transmit anything a user has to remember, since the comparison happens entirely against a mathematical representation of the trait itself.
To understand how this secures a user’s digital identity, let’s follow the journey of a fingerprint scan on a smartphone, from the moment the user first sets it up to each daily unlock.
1. **Capture:** A sensor (e.g. capacitive fingerprint scanner, infrared camera, microphone) reads the user’s trait.
2. **Template creation:** The system extracts unique characteristics from that reading and converts them into a mathematical model, discarding the raw image.
3. **Storage:** The resulting template is stored securely, ideally within a secure enclave or trusted execution environment on the user’s own device.
4. **Matching at login:** Each future login captures a fresh reading and compares it against the stored template, granting access when the two match.
### Core components
Biometric systems rely on three essential components working in harmony:
- **Sensor:** Captures the user’s biological data (capacitive scanners for fingerprints, infrared cameras for faces, microphones for voice)
- **Storage:** Securely stores their biometric template locally on their device or in encrypted databases
- **Processor:** Compares new scans against stored templates using sophisticated matching algorithms
### Raw data vs. templates
When the user first registers their fingerprint, the system doesn’t store a raw image. Instead, it extracts unique characteristics: ridge patterns, minutiae points (where the ridge lines end or fork), and spatial relationships. These patterns are converted into a mathematical model, typically 1 to 2 kilobytes of encrypted data stored in a secure environment. Their actual biometric data (the high-resolution fingerprint image) is captured, processed, and immediately discarded. Only the mathematical representation, known as a template, is kept for later comparison.
The template creation process involves one-way transformations and feature extraction that result in significant information loss. While it’s not technically impossible to rebuild a fingerprint image from a template, the gaps in data make an attempt computationally difficult. Meanwhile, the pixel-level detail needed to reproduce actual ridge patterns simply isn’t there anymore.
### On-device vs. server-side storage
Once the biometric template is created, the next decision is where to store it. Modern implementations increasingly favor on-device storage, where the template stays within a secure enclave or trusted execution environment (TEE) on the user’s device. This setup keeps biometric data local to the hardware, which reduces the risk of interception or mass data breaches.
In contrast, server-side storage involves transmitting the biometric template to a centralized database for storage and matching. While this approach can simplify multi-device authentication or enterprise-wide management, it also creates a high-value target. A breach could expose many users’ biometric templates at once, data that, unlike passwords, cannot be changed.
Some enterprise and government systems still rely on server-side matching because it lets them authenticate the same person consistently across many devices and locations, but that convenience comes with the tradeoff of a single point of failure for every enrolled user’s biometric data.
On-device storage aligns more closely with privacy-by-design principles and is now the standard for consumer devices like smartphones and laptops. It supports faster authentication, reduces network dependencies, and makes spoofing attempts significantly harder by keeping matching operations local to the device. This is why technologies like Apple’s Touch ID and Face ID, as well as Android’s BiometricPrompt API, are built around on-device processing.
## Biometric authentication methods
There are [multiple types of biometric authentication](<https://www.descope.com/blog/post/biometric-auth-methods>) in use today, with ongoing research to develop new and more sophisticated approaches. The table below compares the most common methods:
| **Method** | **How it works** | **Accuracy** | **Common use** | **User friction** |
| --- | --- | --- | --- | --- |
| Fingerprint | Maps the ridges and patterns of a finger and compares them to a stored template | Very high on modern sensors | Unlocking devices, banking apps, payments | Low |
| Facial recognition | Maps roughly 80 facial nodal points into an encrypted digital model | Very high on leading systems, though accuracy can vary by demographic | Unlocking phones, quick app logins | Low |
| Iris/retina | Analyzes the colored rings of the iris or blood vessel patterns in the retina using infrared light | Extremely high, very low false match rate | Government and high-security facilities | Medium |
| Voice | Builds a profile of vocal tone, pitch, and accent | Moderate, sensitive to noise and impersonation | Call center verification, digital assistants | Low |
| Multimodal | Combines two or more biometric identifiers for a single decision | Higher than any single method alone | High-security enterprise and government systems | Medium |
### Fingerprints
[Fingerprint authentication](<https://www.descope.com/learn/post/fingerprint-authentication>) uses the unique ridges and patterns of a person’s fingerprint to validate their identity. The proliferation of electronic devices with fingerprint scanners has made this one of the most widely adopted biometric methods.
### Facial recognition
[Facial recognition](<https://www.descope.com/learn/post/facial-recognition>) systems analyze the unique characteristics and geometry of a person’s face to confirm their identity. Each human face has around 80 nodal points, including the distance between the eyes, the width of the nose, and the length of the jawline. Scanners convert these nodal points into a faceprint, an encrypted digital model, and advanced systems perform “liveness detection” to prevent spoofing attempts using static images.
### Iris/retina scans
Iris and retina scans involve the analysis of unique eye features for authentication. Retina scans analyze the distinctive pattern of blood vessels around the eye, while iris scans analyze the colored rings found within the iris. Eye scans are accurate but tricky to implement, since they need infrared light sources, compatible cameras, and controlled lighting conditions.
### Voice authentication
Voice recognition technologies analyze the unique tone, pitch, and accent of a person’s voice to validate their identity. Like facial recognition, voice authentication systems can use liveness tests for additional security to prevent spoofing attempts.
### Multimodal authentication
Similar to [multi-factor authentication](<https://www.descope.com/learn/post/mfa>) (MFA), multimodal biometric authentication combines two or more biometric identifiers, such as fingerprint, face, voice, or iris, to verify a user’s identity. This overcomes the limitations of any single method alone and is a strong fit for organizations that need heightened security.
### Emerging biometric authentication methods
Gait recognition, vein recognition, and keystroke dynamics are newer, less widely deployed approaches worth knowing about. Gait recognition analyzes a person’s stride and posture; vein recognition maps the blood vessels beneath the skin, most often in the palm; and keystroke dynamics tracks typing patterns as a supplemental signal rather than a standalone method. The [biometric authentication methods guide](<https://www.descope.com/blog/post/biometric-auth-methods>) covers each of these in more depth.
## The present and future of biometric authentication
Let’s shed some light on some key factors driving the rising prominence of biometric authentication approaches.
### Biometric scanners are everywhere
The global popularity of smartphones with built-in fingerprint and facial recognition has brought biometric authentication into the mainstream. As major tech companies like [Apple](<https://support.apple.com/en-us/HT204587#:~:text=Touch%20ID%20can%20read%20multiple,match%20and%20unlock%20your%20device.>), [Google](<https://www.zdnet.com/article/google-now-lets-you-sign-into-your-account-with-a-passkey-instead-of-a-password/>), and [Samsung](<https://www.samsung.com/us/support/answer/ANS00082563/>) continue to refine and expand their biometric offerings, adoption of these technologies is expected to keep climbing.
### Password challenges
The prevalence of passwords in online activities has introduced user friction and security challenges. Users often struggle to create and remember strong, unique passwords for multiple accounts. Forgotten passwords lead to user drop-off and complex reset procedures. Reusing passwords across accounts elevates the risk of [credential stuffing](<https://www.descope.com/learn/post/credential-stuffing>) and [account takeover](<https://www.descope.com/learn/post/account-takeover>). The [2026 Verizon DBIR](<https://www.descope.com/blog/post/verizon-dbir-2026>) found that users are more than four times as likely to be reusing a password that’s already been exposed in a prior breach than a merely weak one, which is exactly the kind of behavior biometrics sidestep entirely.
In contrast, biometric authentication provides a more secure and convenient alternative. Fingerprint or face recognition scans are quicker than typing passwords and eliminate the need for users to remember complex passwords, reducing user churn and drop-offs.
### The passkeys shift
Biometrics-enabled devices ignited biometric authentication, while the Web Authentication API ([WebAuthn](<https://www.descope.com/learn/post/webauthn>)), Fast Identity Online ([FIDO2](<https://www.descope.com/learn/post/fido2>)), and [passkeys](<https://www.descope.com/learn/post/passkeys>) are accelerating its adoption.
Here’s how it works: passkeys are an authentication method based on FIDO2, an open standard built on WebAuthn and the Client to Authenticator Protocol ([CTAP](<https://www.descope.com/learn/post/authentication-protocols>)). Passkeys offer a simple and reliable way to implement these different auth protocols in one package. Previously, web authentication with biometrics wasn’t as standardized, which made both implementation and educating new users difficult.
Passkeys have skyrocketed in adoption. According to the [FIDO Alliance’s State of Passkeys 2026 report](<https://fidoalliance.org/fido-alliance-reports-accelerating-global-passkey-adoption-on-world-passkey-day-2026/>), an estimated 5 billion passkeys are now in use worldwide, 90% of consumers are aware of passkeys, and 75% have enabled one on at least one account.
*Looking for a way to test your WebAuthn flows? Check out *[*Virtual WebAuthn*](<https://github.com/descope/virtualwebauthn>)*, a set of Go tools that help developers test WebAuthn flows without needing a browser or an actual authenticator.*
### Privacy considerations
Privacy concerns surrounding biometric authentication have led to a growing patchwork of state-level regulation. Illinois, Texas, and Washington have dedicated biometric privacy statutes, led by Illinois’s [Biometric Information Privacy Act](<https://www.ilga.gov/legislation/ilcs/ilcs3.asp?ActID=3004&ChapterID=57>) (BIPA), which includes a private right of action and damages for violations. Roughly twenty additional states now protect biometric data as sensitive information under broader consumer privacy laws, and Louisiana became the newest state to pass a broad privacy law covering biometric data in May 2026.
Given these fragmented and still-evolving rules, businesses should ensure their data practices align with the requirements in every state where they have users, particularly if they collect fingerprints, face scans, or voiceprints.
FIDO Certified biometric authentication solutions prioritize privacy even further. They ensure that biometric information is never stored on servers; instead, it is encrypted and locally stored on the user’s device.
**Also read:** [Passwordless Authentication 101](<https://www.descope.com/learn/post/passwordless-authentication>)
## Pros and cons of biometric authentication
Biometric authentication is the key to enhanced security and user convenience, but like any technology, it comes with its own set of advantages and considerations.
### Advantages
- **Enhanced security.** Biometric authentication, rooted in “who users are,” is significantly more resistant to theft and misuse than passwords, PIN codes, and other knowledge-based authentication methods. Using biometric authentication based on WebAuthn also ensures that user secrets remain secure, reducing the potential attack surface.
- **Improved user experience.** Utilizing a fingerprint scanner or glancing at a camera for biometric authentication is considerably faster than manually entering credentials. Additionally, biometric authentication doesn’t require users to create and memorize passwords, reducing churn and drop-off rates.
- **Widespread adoption.** Biometrics are built into everyday electronic devices and used by a wide range of applications, and multiple surveys have found that users prefer them over passwords for the convenience alone. Nearly every modern smartphone, laptop, and tablet now ships with a fingerprint sensor, front-facing camera, or both, so most users already have the hardware needed to authenticate biometrically without buying anything new.
### Considerations and risks
- **Failed authentication in edge cases.** Despite the immutability of an individual’s biometrics, certain conditions can result in failed authentication. For instance, fingerprint sensors may not function well with wet or dirty hands, or voice recognition may fail if the user has a sore throat. Good implementations always include a fallback method, such as a PIN or passkey, so a temporary sensor failure never locks a legitimate user out entirely.
- **Potential training data bias.** Facial recognition training data has historically underrepresented some demographic groups, leading to identification inaccuracies. Recent research suggests the picture is more complex than demographics alone: factors like image quality, lighting, and even facial hair or hairstyle can influence accuracy as much as, or more than, race or gender. While the [most accurate systems show much smaller gaps](<https://www.biometricupdate.com/202508/fairness-in-facial-recognition-hinges-on-mix-of-factors-including-cultural-norms>) than older benchmarks found, vendors are actively working to close the remaining gap. Independent benchmarks such as NIST’s Face Recognition Vendor Test give buyers a way to compare how different systems perform across demographic groups before choosing one.
- **Inability to reset biometrics.** Unlike passwords, which can be changed if compromised, biometric data cannot be altered if stolen. Thus, it is vital to store user biometric data locally rather than on centralized servers.
## Biometric authentication use cases
Biometrics authentication now touches far more than device unlocks. Here are some examples of how different biometric methods are used today, and how biometrically authenticated flows show up across industries.
| **Use case** | **Fingerprints** | **Facial recognition** | **Retina/iris** | **Voice recognition** |
| --- | --- | --- | --- | --- |
| Identity verification | Yes | Yes | Yes | Yes |
| Financial transactions | Yes | Yes | | Yes |
| Computer security | Yes | Yes | | Yes |
| Law enforcement | Yes | Yes | | Yes |
| Smartphone unlocking | Yes | Yes | | Yes |
| Passport/visa verification | Yes | Yes | Yes | |
| Airport security | Yes | Yes | Yes | |
| Ecommerce security | Yes | Yes | | |
| Healthcare patient ID | Yes | Yes | Yes | |
| Ecommerce payments | Yes | Yes | | |
| Attendance tracking | Yes | Yes | | |
| Access control | Yes | Yes | | |
| Mobile payments | Yes | Yes | | Yes |
| Vehicle unlocking | Yes | Yes | | |
| Safes and locks | Yes | | | |
| Social media tagging | | Yes | | |
## How to add biometric auth to your app
Biometric login in a web or mobile app is delivered through passkeys and the WebAuthn standard, where a fingerprint or face scan unlocks a device-bound key rather than sending the biometric itself anywhere. Adding it typically follows a few steps:
1. **Register a credential at signup**, confirmed with a fingerprint, face scan, or device PIN.
2. **Store the resulting key** on the user’s device rather than on a server.
3. **Verify the credential at each login**, checking a fresh biometric reading against the same device-bound key.
4. **Fall back gracefully** for devices or browsers that don’t support the method.
Most teams don’t build this from scratch, since handling registration ceremonies, attestation, and cross-device fallbacks correctly is a meaningful engineering lift. Descope adds biometric login to a React, [Next.js](<https://docs.descope.com/getting-started/nextjs>), or any other customer-facing app through its SDKs and drag-and-drop flows, alongside its passkeys and FIDO2 support. Using Descope’s abstraction layers ensure that a fingerprint or face scan can replace a password for your app’s login without your team building the underlying protocol work.
**Learn More: **[**Developers’ Guide to Passkey Implementation**](<https://www.descope.com/blog/post/developer-guide-passkeys>)
## No / low code biometric auth with Descope
Descope lets teams [add biometrics](<https://www.descope.com/use-cases/biometrics>) to their apps through visual workflows rather than building WebAuthn by hand. You can use biometrics for strong MFA, add [passkey authentication](<https://www.descope.com/use-cases/passkeys>) with autofill and backup, or layer biometrics on as a second factor after registration, all without custom implementation work. Whether you need standalone biometric authentication or biometrics as part of a broader MFA flow, the same no-code workflows cover both.
[Sign up for a Free Forever account](<https://www.descope.com/sign-up>) to start using Descope today, or [book time with our auth experts](<https://www.descope.com/demo>) if you have questions first.
## Frequently asked questions about biometric authentication
---
### [What Is Cross-App Access (XAA) and How It Works](https://www.descope.com/learn/post/id-jag-cross-app-access)
*Full content: [https://www.descope.com/learn/post/id-jag-cross-app-access.md](https://www.descope.com/learn/post/id-jag-cross-app-access.md)*
To do their jobs properly, enterprise applications need to talk to each other: project management tools pull data from CRMs, a CI/CD pipeline pushes to a code repository, an analytics dashboard queries multiple SaaS APIs.
These connections have traditionally relied on one of two approaches:
- Long-lived API keys that never expire, or
- OAuth flows that require manual user approval for every integration
Both scale poorly, which is why Cross-App Access (XAA) is gaining traction, particularly for agentic AI use cases.
In simplest terms, XAA extends enterprise SSO to APIs. Just as your identity provider (IdP) manages who can log in to which applications, XAA lets that same IdP manage which applications can reach other applications' APIs on behalf of users.
You'll also see the underlying specification called the Identity Assertion JWT Authorization Grant, or ID-JAG. The two terms sit at different layers: ID-JAG is the IETF document that defines the token exchange, and Cross-App Access is what the industry calls the pattern that document enables. The [specification itself draws the same line](<https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/>), noting that the pattern it describes is informally referred to as Cross-App Access.
In the following post, we'll walk through the problem XAA solves, how it works, where the standard currently stands, and what it changes for AI agents.
## The problem with API keys and OAuth consent flows
The two traditional approaches for app-to-app access struggle at scale, though each has its own specific challenges.
### API keys
**API keys **are essentially a password that an application uses to authenticate with an API, or Application Programming Interface. This is a layer that enables different apps to communicate even if they’re written in different languages.
When App A needs to access App B’s API, App B generates a key (usually a quite long random string) that App A includes with every API request. That API validates the key and grants access.
The problem is how these keys are managed in actual practice. Most API keys are:
- Long-lived (meaning they don’t expire unless manually revoked)
- Over-scoped (they have broad access rather than permissions for only what’s essential)
- Decentralized (spread out across config files, environment variables, local machines, etc.)
This is why when an API key leaks (and they often do), enterprises face huge security liabilities. With no centralized inventory of which systems hold keys to what resources, and no automatic expiration or rotation, revocation usually requires coordination across teams to limit damage. Meanwhile, keys are often stored across multiple services, making selective revocation impossible without potentially breaking production.
While you *can* implement key rotation, scoping, and centralized management of API keys, most organizations struggle to do this consistently across their many, many applications. And most simply choose not to, because it isn’t built-in, and they have other priorities.
### OAuth consent flows
**OAuth consent flows**, which are a core part of the [Open Authorization (OAuth) specification](<https://www.descope.com/learn/post/oauth>), address some of the API key issues by introducing time-limited access tokens and user-controlled permissions. Instead of App A holding a permanent key to App B, the flow works like this:
- App A redirects the user to App B’s authorization server
- User logs in and sees a consent screen: “App A wants to access your calendar data”
- The user approves, and App B issues an [access token](<https://www.descope.com/learn/post/access-token>) with specific scopes and an expiration for App A
- App A uses this token to make API calls
This is obviously much more secure than API keys: It handles the long-lived access problem, tackles the trouble with over-scoping (assuming the app doesn’t request outlandish scopes), and adds some user-facing elements for some (but limited) visibility into what’s going on.
The real challenge arises at enterprise scale, when you’re dealing with hundreds of apps, thousands of users, and the need to enforce non-negotiable security policy across all of it. Below are just a few of the struggles organizations face when using OAuth consent flows for app-to-app API access at scale:
- **User experience friction:** Because each integration takes a separate OAuth flow, a new employee connecting Slack, Trello, Google Calendar, Salesforce, HubSpot, and GitHub might click through a dozen consent screens before they can even start working. Multiply this across every employee and every app integration.
- **IT visibility is limited: **These OAuth connections happen directly between the user and the apps, meaning IT is out of the loop by default. When an employee authorizes “Generic Marketing Analytics Tool #43” to access sensitive customer data in Salesforce, IT/InfoSec has no centralized view of that happening. The authorization lives in the Salesforce settings for that user.
- **Fragmented access management: **While not buried as deep (or in such varied places) as API keys, revocation still requires security teams to log into each resource app individually, find the authorized connections, and disable them. There’s no built-in visibility that shows “which apps can access what data across our organization.”
- **Policy gaps:** IT/InfoSec can’t pre-approve safe integrations or block risky ones. Every authorization decision happens at the user level, in the moment, without organizational policy enforcement until after the fact.
For enterprise use cases, the recurring issue between both of these approaches is that there’s no unified governance layer to revoke access, observe connections, and enforce policy.
What enterprises need is:
- Centralized visibility into all app-to-app connections
- Policy-based access control managed by security teams, not individual users
- Short-lived credentials that expire automatically
- Audit trails that show which app access what data, and when
- The ability to revoke access instantly from a single point of control
These are the problems that ID-JAG/XAA was designed to solve.
## How Cross-App Access (XAA) works
In a nutshell, XAA extends enterprise SSO patterns to app APIs. It lets IdPs govern which applications can access other applications' APIs, with enforcement that supersedes the user level.
It may sound quite similar to the OAuth consent flow, but with observability and policy baked in, and there's a good reason for that: it's based on the same underlying standards. The key difference is that instead of apps establishing direct trust with each other, the enterprise IdP mediates every connection. IT/InfoSec can pre-approve (or pre-deny) which integrations are allowed, and the IdP issues short-lived, scoped tokens only when policy permits.
### OIDC and keys
XAA invokes the IdP's existing private key that it uses to sign JWTs, or JSON Web Tokens. The IdP publishes its public key so other entities, like resource apps, can verify that its signature on a JWT is legitimate. This is the same signing mechanism used in standard [OpenID Connect (OIDC)](<https://www.descope.com/learn/post/oidc>) ID tokens. The resource app already trusts the IdP for SSO, fetching its public keys to validate ID tokens, and XAA builds directly on that relationship.
### The XAA flow
The protocol involves three parties: the **requesting app** (the one that needs API access), the **resource app** (the one that owns the API or [MCP server](<https://www.descope.com/learn/post/mcp>)), and the **enterprise IdP** (which governs and mediates the connection).
Here's how the token exchange works:
- **The user authenticates with the IdP via SSO**, receiving an ID token (as in a standard OIDC flow).
- **The requesting app requests exchange of the ID token for an ID-JAG** at the IdP's token endpoint as per [RFC 8693](<https://datatracker.ietf.org/doc/html/rfc8693>) token exchange.
- **The IdP validates the request against company policy**: Is the requesting app allowed to access this resource app? Are these scopes permitted for this user?
- **If approved, the IdP issues an ID-JAG** (a signed JWT) back to the requesting application.
- **The requesting app presents the ID-JAG to the resource app's authorization server** using the JWT bearer grant type ([RFC 7523](<https://datatracker.ietf.org/doc/html/rfc7523>)).
- **The resource app validates the ID-JAG signature** using the IdP's public keys (the same JWKS, or JSON Web Key Set, used for OIDC), then issues a short-lived access token.
- **The requesting app makes API calls** with the access token until it expires (typically within 10-15 minutes).
One quick note on what the resource app actually keeps: the spec very intentionally leaves the resource authorization server as the issuer of access tokens for its own protected resources. The IdP vouches for the user, but it doesn't mint credentials on the resource app's behalf.
## The difference between XAA and ID-JAG
The terms "XAA" and "ID-JAG" have often been used interchangeably, and in most conversations that's fine. Everyone generally understands what you mean if you say one or the other. The terms sit at different layers, though, and the distinction has become increasingly meaningful.
The division of ID-JAG vs. XAA is similar to how the industry talks about single sign-on (SSO). SSO is the broader pattern, while OIDC and SAML are the specifications underneath. In a similar vein, XAA is the "what," and "ID-JAG" is the "how."
- **ID-JAG: **The [Identity Assertion JWT Authorization Grant](<https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/>) is an OAuth extension moving through the IETF Web Authorization Protocol working group on the standards track. It defines exactly how an identity provider issues an assertion that an application can exchange for an access token. It's worth remembering that's the name of the token itself, too: an IdP issues an ID-JAG.
- **XAA:** The published ID-JAG draft notes that the pattern it defines is informally referred to as Cross-App Access. While the spec's authors come from several different identity vendors, the XAA name has decoupled from any single product or service.
In June 2026, the Model Context Protocol (MCP) officially adopted the grant as its [Enterprise-Managed Authorization (EMA) extension](<https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/>), and it's since seen adoption by Anthropic, Microsoft, and a growing number of MCP builders.
However, this inserts a third name for roughly the same mechanics, though it's bound to the MCP ecosystem. The simplest explanation goes like this: the MCP extension is EMA, XAA is the broader term for the pattern EMA uses, and ID-JAG is the spec that underlies both.
## Why AI is driving XAA adoption
While XAA solves long-standing enterprise problems in app-to-app connections, AI agents are what made a solution urgent rather than a luxury.
An agent that needs to check your calendar, create a Zoom meeting, update a project tracker like Trello, and send a Slack notification faces constraints that traditional applications simply don't. The agent can't pause its workflow to complete OAuth consent screens, and it can't safely hold semi-permanent API keys to every system it might need to access.
The industry best practice is treating agents like first-class identities. They should have their own discrete, ephemeral credentials bound to a specific user and task, which die when the task is done. But organizations are slow to keep up with agentic identity demands. [2026 research from Gravitee](<https://www.gravitee.io/blog/state-of-ai-agent-security-2026-report-when-adoption-outpaces-control>) found that only 22% of teams treat agents as independent identities, with most still relying on shared API keys.
XAA (or more specifically for MCP, EMA) provides a standards-defined way for enterprises to centralize agent governance at scale. While the MCP extension is far from a "plug and play" experience, it's much more closely aligned with industry consensus than hand-rolled scaffolding.
**Read more:** [AI Agent Credential Management Best Practices](<https://www.descope.com/blog/post/ai-agent-credential-management>)
### Traditional approaches to agentic app-to-app access
We’ve seen several approaches to resolving this issue for agents:
- **API keys**, as previously mentioned, can’t be trusted with agents. Agents are still too unpredictable for them to hold these typically overscoped credentials.
- **OAuth consent flows** are a step up, but aren’t viable for workflows where agents might need to talk with dozens of applications: “I need you to approve Slack…now Zoom… now Asana…” defeats the value of many agentic scenarios.
- **Service accounts with broad access **have seen use by some organizations, giving dedicated access rights to the agent. Except this invites a new problem: The agent operates with its own fixed identity that isn’t tied to the user making requests. This is obviously less than ideal for visibility.
### How ID-JAG/XAA helps AI agents connect with apps
With XAA, an AI agent requests tokens through the enterprise IdP on demand, rather than holding a persistent set of credentials. When the agent needs to access Salesforce, for example, it exchanges its ID token (from when the user authenticated with SSO) for a scoped, short-lived token that permits *only* the specific capabilities needed for the task at hand.
The token expires automatically, the request is logged and traceable back to both the user and the agent, and IT/InfoSec maintains policy control over which agents can access which resources. This dovetails neatly with how enterprises actually think about agentic security: agents should act on *behalf* of users, with permissions derived from those users' access rights, not operate as independent, un-monitorable entities with overly broad scopes.
IT/InfoSec can define policies covering which types of agents reach which types of apps and what their permissions are within those environments: reading calendars but not writing to them, adding meetings for Zoom but not Google, and so on. These policies are enforced at the IdP level rather than requiring each application to implement its own agent auth logic for every possible interaction.
### Where MCP fits in with XAA
Most of this now plays out through MCP servers. When a B2B company exposes an [MCP server](<https://www.descope.com/learn/post/mcp>) to its customers, those customers' security teams want to govern agent access with the identity provider they already run. Enterprise-Managed Authorization is the MCP extension that makes that possible, and XAA is how it works underneath: the customer's IdP mints an assertion, the MCP server's authorization server redeems it for an access token, and no one clicks a second consent screen.
## Securing and simplifying app-to-app access
Cross-App Access extends enterprise SSO to API access, replacing unscalable static credentials and fragmented OAuth flows with IdP-mediated, short-lived tokens. The problem it addresses predates agentic AI by years across SaaS integrations of every kind, but AI agents are what turned the problem from a tolerable annoyance into an urgent need.
Descope [supports both sides of the exchange](<https://www.descope.com/blog/post/xaa>) in the [Agentic Identity Hub](<https://www.descope.ai/>):
- A company selling an MCP server can register a trusted issuer for each tenant, so an assertion minted for one customer cannot be redeemed against another. Per-organization scope policies determine what level of agent access each customer receives, and the MCP server itself never has to implement ID-JAG.
- An organization running its own agents can register each downstream MCP server or API as a Resource and writes a token exchange policy that is evaluated on every request rather than baked into a long-lived credential.
Cross-App Access also lives in the [SSO Setup Suite](<https://docs.descope.com/auth-methods/sso/sso-setup-suite#cross-app-access-xaa-configuration>) alongside SSO, SCIM, and JIT provisioning, so your tenant admins can configure it themselves without needing hands-on support.
If you're building AI agents, or apps that need to talk with them, the [Cross-App Access developer playground](<https://www.crossappaccess.guru/#sign-in>) walks through a full exchange end to end. You can also join [AuthTown](<https://www.descope.com/community>), our dev community, or [sign up](<https://www.descope.com/sign-up>) for a Free Forever Descope account to try the flow in your own project.
---
### [What Is a Non-Human Identity (NHI)?](https://www.descope.com/learn/post/nhi)
*Full content: [https://www.descope.com/learn/post/nhi.md](https://www.descope.com/learn/post/nhi.md)*
A non-human identity (NHI) is any digital identity that isn’t tied to a human user. The term covers:
- Devices (IoT sensors, mobile endpoints, desktops)
- Software workloads (microservices, containers, serverless functions)
- AI agents (autonomous or semi-autonomous software entities)
[Gartner’s IAM taxonomy of NHIs](<https://www.gartner.com/en/documents/6178123>) places NHI at the top of a hierarchy that includes everything from RFID-tagged animals in agriculture to organizational legal entities. But in the systems most developers work with day to day, non-human identity translates to things like API keys, [OAuth](<https://www.descope.com/learn/post/oauth>) clients, X.509 certificates, SSH keys, and bot accounts.
This post examines what non-human identity means for the majority of developers: how NHIs relate to machine identities, where AI agents break the traditional model, and the [authentication](<https://www.descope.com/learn/post/authentication>) flows used to secure machine-to-machine communication.
## NHI vs. machine identity
The terms “non-human identity” and “machine identity” are often used interchangeably, but they describe different tiers of the same idea. Gartner’s taxonomy places NHI at the top, with machine identity as a subset covering devices and workloads. Other NHI branches include non-machine NHIs (like the aforementioned animals and legal entities), but these are edge cases outside the scope of most software teams.
The distinction between NHI and machine identity matters because the market has muddied it. Gartner observed that the term “NHI” is often used as a buzzword by vendors offering workload IAM capabilities, broadening the label beyond its functional meaning. This is worth bearing in mind when evaluating vendor claims: “NHI” can refer to a comprehensive non-human identity framework, a certificate lifecycle management tool with ambitious branding, or something in between.
This post uses “NHI” as the operative term throughout, with the understanding that the NHIs most software teams actually deal with fall into three practical categories: devices, workloads, and AI agents.
## NHI types and risk surface
The NHIs most developers encounter break down along two dimensions: what they are and how they handle authentication.
**Device identities **cover physical hardware: desktops, mobile endpoints, IoT sensors, and operational technology (OT) equipment. These NHIs are simpler in practice and typically rely on certificate lifecycle management. The credential surface is simpler and narrow, and the solutions for controlling it are well-established.
**Workload identities **cover the software side: applications, bots, virtual machines, containers, serverless functions, and service accounts. Workload NHIs use a much wider range of credentials, including OAuth tokens, JWTs, API keys, personal access tokens (PATs), encryption keys, and SSH keys. This diversity makes them more complex and harder to govern.
Security teams need to manage identities for both humans and non-humans, but the NHI side is where the most urgent risk surface is concentrated. According to a Cloud Security Alliance study, non-human identities outnumber human identities by [roughly 20 to 1](<https://www.descope.com/blog/post/agentic-identity>) in most cloud-native organizations. Only 15% of organizations expressed high confidence in their ability to secure NHIs, and nearly 1 in 5 organizations reported having a security incident related to them.
NHIs exist with good reason, mostly in service of automating workflows and enabling system-to-system communication. But they’re frequently a target for credential-based attacks due to several recurring patterns:
- Excessive permissioning
- Inconsistent lifecycle management
- Lack of centralized governance
- Fragmented creation by different teams using different tools
The credential diversity of workload NHIs leads to cascading challenges: a single microservice might rely on [OAuth client credentials](<https://docs.descope.com/getting-started/oidc-endpoints#client-credentials-flow>) for service-to-service calls, APIs for third-party integrations, and certificates for mTLS between internal services. Each credential type has its own rotation parameters, storage requirements, and revocation mechanisms. Without a unified approach, gaps are inevitable.
**AI agents **are the newest addition to the NHI landscape. Unlike devices and workloads, agents are dynamic and can move across multiple systems with minimal or (zero) human direction. They’re technically workload NHIs in the Gartner taxonomy, but their behavior diverges enough from traditional workloads that they warrant their own identity treatment in our view.
## Where AI agents break the traditional NHI model
The NHI categories above (devices and workloads) were designed for a world where the entity requesting access is a deterministic process following a fixed set of instructions. AI agents break that assumption because they are non-deterministic. An AI agent operates autonomously or semi-autonomously, making decisions and taking actions across multiple systems without step-by-step human direction.
Traditional, static NHIs (for example) call the same API with the same credentials in the same predictable pattern. Agents are dynamic and decide what to call, when, and why, based on their current context and objectives. This creates the need for a fundamentally different identity approach.
| | **Human identities** | **Traditional NHIs (devices, workload)** | **Agent NHIs** |
| --- | --- | --- | --- |
| **Behavior** | Interactive, UI-driven | Static and deterministic | Dynamic and non-deterministic |
| **Auth patterns** | Knowledge, possession, and inherence-based auth; MFA | OAuth tokens, API keys, M2M flows, certificates | Delegated access, consent flows, MCP |
| **Scale** | Bounded by headcount | Bounded by infrastructure | Autonomous or semi-autonomous at scale |
| **Access model** | Role and group-based | Static scopes and permissions | Function and tool-level access |
The challenge is that neither human identity patterns nor traditional NHI patterns fit agents particularly well:
- **Human-centric credentials** (SSO sessions, passwords) can give agents dangerously broad permissions with limited revocability
- **Static workload credentials** (long-lived API keys, service account tokens) lack the granularity and auditability that autonomous systems need
This gap between traditional models and emerging agentic identity requirements has driven a shift toward treating AI agents as a distinct NHI category. AI agents treated as first-class identities have their own lifecycle, credential model, and [access control](<https://www.descope.com/learn/post/access-control>) approach.
In real-world scenarios, this means scoped, short-lived, and auditable credentials issued per-action and per-session rather than long-lived keys shared across workflows. Case in point: the [auth spec for the Model Context Protocol (MCP)](<https://www.descope.com/blog/post/mcp-auth-spec>) provides a framework for this pattern by mandating OAuth 2.1, and supporting per-tool scopes and user consent flows for interactive authorization.
**For a deeper look at how agentic identity protocols are shaping how agents interact with tools and each other, see our beginner-friendly guides on **[**MCP**](<https://www.descope.com/learn/post/mcp>)** and the **[**Agent2Agent Protocol**](<https://www.descope.com/learn/post/a2a>)**. **
## Machine-to-machine (M2M) authentication flows
Regardless of whether an NHI is a traditional workload or an AI agent, it needs to authenticate before it can access resources. OAuth provides the standard mechanisms for this, with two flows emerging as particularly relevant to NHI security: client credentials and OAuth token exchange.
### Client credentials flow
The client credentials flow is the baseline for machine-to-machine authentication. It’s designed for scenarios where no human user is involved.
The flow is relatively simple:
1. The client (Service A) sends its client ID and client secret to the authorization server.
2. The authorization server validates the credentials.
3. If valid, the authorization server returns a [JWT](<https://www.descope.com/learn/post/jwt>) (access token) signed with its private key.
4. Service A uses the JWT to authenticate with Service B (the downstream resource).
One key security advantage is that the client secret is only stored and managed in one place (Service A) and is never transmitted to downstream services. The downstream service validates the JWT’s signature against the authorization server’s public key ([JWKS](<https://www.descope.com/learn/post/jwks>) endpoint), verifies the [token claims](<https://www.descope.com/learn/post/jwt-claims>), and grants or denies access based on the scopes present in the token.
Client credentials is the right pattern when both services are known and trusted, the scope of access is well-defined, and there’s no user context to propagate. It’s the flow most organizations start with for internal service-to-service communication.
### OAuth token exchange
Token exchange addresses a more complex scenario: what happens when a service needs to act on behalf of a user or another service, potentially across trust boundaries?
OAuth token exchange allows a client to present an existing token (the “subject token”) to an authorization server and receive a new token with different scopes, audiences, or identity context. Optionally, a second “actor token” can be included to represent the party performing the exchange.
Use cases include:
- **Delegation chains:** A frontend service receives a user’s access token and exchanges it for a narrower token scoped to a specific backend API, preserving the user’s identity while reducing permissions at each hop.
- **Cross-domain federation:** A token issued by one authorization server is exchanged for a token valid in a different trust domain.
- **Scope reduction:** A service with broad access exchanges its token for one with minimal permissions before calling a sensitive downstream resource.
Token exchange is especially relevant for agentic workflows because scopes can be narrowed at each hop. When an AI agent acts on behalf of a user, the delegation chain needs to be explicit and auditable: who authorized the agent, what scope was granted, and which specific downstream resource the token is valid for. Each hop through an exchange produces a token that is more constrained, bound to a specific audience, and narrowed in scope.
### Other related auth patterns
Beyond these two core flows, several adjacent modalities appear in NHI and agentic identity contexts, in particular:
- [**Authorization Code Flow with PKCE**](<https://www.descope.com/learn/post/pkce>)**: **The standard OAuth flow for any scenario where a user grants consent. MCP specifies this flow because it needs user-delegated authorization.
- [**CIBA (Client-Initiated Backchannel Authentication)**](<https://www.descope.com/learn/post/ciba>)**:** A decoupled flow where the authentication device is separate from the consumption device. CIBA is relevant for AI agents because it enables human-in-the-loop approval without requiring the agent to pause its workflow for a browser redirect.
- [**Dynamic Client Registration (DCR)**](<https://www.descope.com/learn/post/dynamic-client-registration>)**:** Allows new clients (including agents) to register with an authorization server programmatically at runtime, which is essential for scaling agentic systems where new agents spin up dynamically.
- [**Client ID Metadata Documents (CIMD)**](<https://www.descope.com/learn/post/cimd>)**: **An alternative to DCR (and new default) for scenarios where traditional registration creates overhead and security risks at scale. The client ID is an HTTPS URL that points to a JSON document containing the client’s metadata.
- [**Cross-App Access (XAA)**](<https://www.descope.com/learn/post/id-jag-cross-app-access>)**:** The common name for IdP-mediated app-to-app access, defined by the Identity Assertion JWT Authorization Grant (ID-JAG). An identity provider both applications already trust mints a short-lived, scoped assertion per request, so an agent reaches another application's API or MCP server without a consent screen for each integration.
## Handling non-human identity in the agentic era
NHI is the fastest-growing (and riskiest) segment of the modern identity surface. The sheer scope (workloads, devices, AI agents) is stretching traditional IAM models in ways that demand fundamental shifts in how organizations handle credential lifecycles, delegation patterns, and policy enforcement. Getting M2M authentication right starts with understanding which flows apply to your architecture, which credential types your NHIs actually need, and how the bigger picture fits together.
To see how Descope solves [M2M authentication](<https://docs.descope.com/security-best-practices/m2m-security>), agentic identity, and non-human identity management, sign up for a [Free Forever account](<https://www.descope.com/sign-up>), join our [AuthTown dev community](<https://www.descope.com/community>), or explore the [Agentic Identity Hub](<https://www.descope.ai/>).
## FAQs about non-human identity
---
### [SIM Swapping: How the Attack Works and How to Protect Your Users](https://www.descope.com/learn/post/sim-swapping)
*Full content: [https://www.descope.com/learn/post/sim-swapping.md](https://www.descope.com/learn/post/sim-swapping.md)*
Most teams already know SMS codes are weak authentication factors. They still leave SMS as the account recovery path, and that's where SIM swapping rears its head. The attack moves a victim's phone number to a SIM the attacker controls, so the calls, texts, and one-time codes intended for that person arrive on the attacker's device instead.
Calling your carrier helps individuals after the fact but the damage has already been done. If you build an app, the fix for SIM swapping is to stop treating SMS codes as identity. Remove SMS as a recovery path first, then as a login factor, and replace it with phishing-resistant methods like passkeys, email magic links, or device biometrics.
## At a glance
- SIM swapping moves a victim's phone number to an attacker-controlled SIM, so the attacker receives their calls and texts.
- The attack intercepts SMS one-time codes, which lets an attacker bypass SMS-based MFA and take over accounts.
- Carrier-side controls protect the individuals who enable them, not your users as a group, so the durable defense for SIM swapping has to sit at the authentication layer.
- Passwordless and phishing-resistant methods like passkeys and email magic links remove the SMS dependency the attack exploits.
## What is SIM swapping?
SIM swapping is an attack that moves a victim's phone number to a SIM card the attacker controls. The attacker doesn't break into a phone or a network. They instead persuade the carrier to reassign the number, and from that moment every call and text intended for the victim arrives on the attacker's device.
The phone matters only as a delivery channel. Password reset links, account recovery codes, and one-time passcodes all route to whoever holds the number, which turns a single carrier decision into access across dozens of unrelated accounts.
The attack works because of an assumption authentication design has relied on for years: a phone number reliably identifies a person. This is a dangerous assumption. In reality, a phone number identifies a billing relationship with a carrier, and that relationship transfers to anyone persuasive enough on a phone call.
The attack is also called a SIM swap scam or a SIM swap attack, and occasionally SIM hijacking or port-out fraud. The mechanics are the same in each case: control the number, then collect what's sent to it.
## How does a SIM swap attack work?
An attacker gathers enough personal detail to pass a carrier's identity check, contacts the carrier while impersonating the victim, has the number ported to a SIM they control, and then intercepts everything sent to it.
The reconnaissance step rarely involves anything exotic. Names, birthdates, addresses, and the last four digits of a payment card circulate in breach dumps and are often enough to begin the attack. Where they're not enough, a phishing message aimed at the victim fills the gaps.
Once recon is complete, the attacker calls the carrier (or walks into a retail store) and asks to move the number to a new SIM. Sometimes the request succeeds through social engineering alone. Sometimes it succeeds because an insider processes it. The FBI's Internet Crime Complaint Center [describes the same sequence](<https://www.ic3.gov/PSA/2022/PSA220208>): once the SIM is swapped, calls and texts divert to the criminal's device, which lets them send password reset and account recovery requests to the victim's other accounts and use the intercepted codes to log in.
The victim's phone loses service at the moment of the port, which is the one visible signal that anything has happened. By then, the attacker is already midway through their account takeover attempts.
## Why is SIM swapping so dangerous for your users?
SIM swapping is dangerous because it defeats SMS-based MFA and phone-based account recovery at the same time, and turns one intercepted code into a full account takeover.
The damage comes from the authentication decisions built on top of the phone number. If your login flow sends a one-time code by SMS, an attacker holding the number receives it. If your account recovery flow lets a user prove ownership by receiving a text, an attacker holding the number can reset the password outright and lock the real user out.
Recovery is usually the weaker of the two, and it's where most defenses fail. Teams harden the login path with an authenticator app or a passkey, then leave account recovery as a plain phone-number check. That gap lets the attacker skip the front door entirely and walk in through the side.
The exposure compounds across accounts. A phone number used to recover credentials for an email inbox reveals everything that the inbox contains. [Account takeover prevention](<https://www.descope.com/use-cases/fraud-prevention>) has to start with the factors themselves, not with detecting the takeover after it's already happened.
> In December 2024, CISA published its [Mobile Communications Best Practice Guidance](<https://www.cisa.gov/resources-tools/resources/mobile-communications-best-practice-guidance>), directing organizations not to use SMS as a second factor for authentication, and pointing to FIDO authentication and passkeys instead.
## Which authentication methods resist SIM swapping?
Not every factor is equally exposed once an attacker holds the phone number. The table below breaks down which methods still hold up.
| **Authentication method** | **SIM swap resistant** | **Why** |
| --- | --- | --- |
| SMS one-time code | No | Delivered to the phone number the attacker now controls |
| Authenticator app (TOTP) | Yes | Generated on device, not sent over the mobile network |
| Push notification | Mostly | Tied to an app instance, though exposed to fatigue attacks |
| Email magic links | Mostly | Tied to email inbox ownership, though using SMS as a recovery path for email inboxes leave them open to compromise as well |
| Passkeys / FIDO2 | Yes | Bound to the device and origin, nothing to intercept |
| Biometrics (device) | Yes | Verified on the device, not tied to the phone number |
### How does passwordless authentication stop SIM swapping?
[Passwordless authentication](<https://www.descope.com/learn/post/passwordless-authentication>) verifies a user without a password, using methods such as passkeys, device biometrics, magic links, and authenticator apps. Instead of recalling and typing a secret, the user proves possession of a registered device.
While SMS OTPs are also technically “passwordless”, the codes are still shared secrets that can be phished (via SIM swapping) or coerced from users. More phishing-resistant passwordless methods, including Descope's [passkey](<https://www.descope.com/use-cases/passkeys>) and [magic links](<https://www.descope.com/use-cases/magic-links>) options, send nothing to a phone number, so there's nothing for the attacker to catch.
[Passwordless methods](<https://www.descope.com/use-cases/passwordless-authentication>) also remove the two most attacked factors–passwords and SMS codes–while reducing friction at sign-in. Credential stuffing has nothing to stuff, because there's no reusable password to replay from a breach dump. SIM swapping has nothing to intercept. Phishing pages can't harvest a passkey, because the credential is bound to the origin it was created on and won't release to a lookalike domain.
Adoption stats back up the preference for phishing-resistant passwordless methods. Descope's [State of Customer Identity 2025 report](<https://www.descope.com/blog/post/passwordless-authentication-trends>) found that 45% of organizations have already deployed passkeys in one or more apps, and another 27% plan to within two years.
### How does biometric authentication protect against SIM swapping?
[Biometric authentication](<https://www.descope.com/learn/post/biometric-authentication>) verifies a user with a physical characteristic such as a fingerprint or a face scan, checked on the device itself. [Device biometrics](<https://www.descope.com/use-cases/biometrics>), if implemented thoughtfully, never transmit biometric data. The scan unlocks a private key stored in the device's secure hardware, and it’s that private key paired with your app’s public key that authenticates users (not their fingerprints).
That design is what makes biometrics resistant to SIM swapping. Nothing is tied to the phone number, and nothing crosses the mobile network.
Using biometric authentication needs thoughtful design of fallback or recovery options. There are still users with devices that are not WebAuthn-compatible, which is the protocol that runs passkeys. If developers end up putting SMS codes as the fallback for those users, they remain vulnerable to SIM swapping.
### How do you choose phishing-resistant MFA?
Phishing-resistant MFA uses factors that can't be relayed to an attacker (or they at least make it much harder for the attacker to access credentials).
SMS fails the phishing-resistant test multiple times. SMS OTP codes can be intercepted through a SIM swap, and they can also be phished directly (e.g. a user being socially engineered to share the code with the attacker or typing it into a phishing lookalike page). Authenticator app codes are better, because they never traverse the mobile network, but they remain relayable through social engineering.
When evaluating an authentication stack that resists SIM swapping, some criteria to consider are:
- First-class support for methods like passkeys and biometrics
- Breadth and depth of authentication methods in general (to offer alternatives and fallbacks)
- The ability to change auth methods and logic without an application redeploy or custom code
- Flexibility in handling recovery flows
## How can you protect your users from SIM swapping?
You can't control your users' carriers, but you can control what your application accepts as proof of identity. Here are some tactics that reduce / remove reliance on phone numbers as identities and that provide defense-in-depth:
1. Remove SMS one-time codes as a primary login factor.
2. Remove the phone number as an account recovery path. This is where SMS most often survives a modernization effort, and it's the path attackers prefer.
3. Adopt passkeys as a primary auth method. A [passkey](<https://www.descope.com/use-cases/passkeys>) is bound to the device and the origin, so there's no code in transit for anyone to intercept.
4. Offer device biometrics where hardware supports it. Verification happens on the device and never touches the mobile network.
5. Add [adaptive authentication](<https://www.descope.com/learn/post/adaptive-authentication>) checks. A takeover attempt usually arrives from a new device in a new location within minutes of a password reset, and [adaptive MFA](<https://www.descope.com/use-cases/mfa>) can require a stronger factor exactly there while staying out of the way otherwise.
6. Add [silent network authentication](<https://www.twilio.com/en-us/blog/silent-network-authentication-sna-overview>) (SNA) where your user base makes it worthwhile. SNA verifies the phone number against the carrier's live records at the network layer, so a fresh SIM swap can be detected before a recovery code is sent.
7. If you can't remove SMS immediately, demote it. Keep it as a last-resort fallback behind stronger methods, and require re-verification through another channel before it can change account settings.
## How are regulations phasing out SMS as an authentication factor?
Regulators have shifted from tolerating SMS-based MFA to actively discouraging it, and in some markets to banning it outright.
In its December 2024 [Mobile Communications Best Practice Guidance](<https://www.cisa.gov/resources-tools/resources/mobile-communications-best-practice-guidance>), CISA states plainly: “Do not use SMS as a second factor for authentication.” The same guidance directs readers toward FIDO authentication and names passkeys as an acceptable alternative.
The Central Bank of the UAE's [Notice 2025/3057](<https://www.descope.com/blog/post/cbuae-notice-3057>) banned SMS and email one-time passwords as standalone authentication for licensed financial institutions from March 2026, and shifted liability for 3D Secure fraud involving SMS OTP onto those institutions from July 2025, ahead of the ban.
In New York, [NYDFS Part 500](<https://www.descope.com/blog/post/nydfs-compliance-auth-mfa>) requires multi-factor authentication across covered financial services entities, with a stronger definition of what qualifies following the 2023 amendment. SMS is not banned outright, but the guidance around it is narrowing, and the safer read for a covered entity is to move toward phishing-resistant factors ahead of the next revision.
In the EU, [DORA](<https://www.descope.com/blog/post/dora-auth-mfa>) requires financial entities to protect authentication with strong, documented, testable controls. It doesn't prohibit a specific factor, but every SMS auth deployment is still something you have to justify in an audit.
The pattern is consistent: SMS is being demoted from acceptable factor to residual, and in some jurisdictions to prohibited. Applications built to allow authentication factor changes without custom engineering work absorb these transitions cheaply. Applications built around an overreliance on SMS authentication absorb them expensively or risk being out of compliance.
## What are the most common mistakes when defending against SIM swapping?
1. Keeping SMS as a primary factor by using wide coverage as rationale (i.e. “every phone number receives texts”). Coverage is exactly what the attacker is exploiting as well.
2. Leaving the phone number as a recovery path. This is the most common residue of a partial modernization effort, and the path attackers reach for first.
3. Treating SIM swapping solely as a carrier problem. Carrier-side controls like port-out PINs help the individuals who enable them, but you can't enable them for your users, and you shouldn't build a security model that assumes they did.
4. Rolling out passkeys without a considered fallback. If the fallback is SMS, the attacker simply requests it. CISA's guidance flags the related failure directly: enrolling a user in authenticator-based MFA doesn't automatically unenroll SMS, which leaves it in place as “a weak, exploitable fallback mechanism” long after it should have been retired.
5. Not watching for takeover signals. A recovery request from an unrecognized device, in a new location, minutes after a failed login, is the shape of a SIM swapping attack in progress, and it's also the moment a [step-up authentication](<https://www.descope.com/learn/post/step-up-authentication>) challenge is worth the friction.
## How does Descope help protect against SIM swapping?
Descope is a customer and agentic identity platform that treats phishing-resistant methods as first-class: passkeys, biometrics, and magic links are configured as primary factors, so there's no code in transit for a SIM swap to intercept.
Where SMS has to stay for a transition period, [adaptive MFA](<https://docs.descope.com/mfa-and-step-up/mfa/adaptive-mfa>) governs when it's used, and risk signals like impossible traveler and new-device detection can require a stronger factor for a recovery attempt from an unfamiliar device while a routine login stays untouched. [Descope Flows](<https://www.descope.com/flows>), Descope’s visual workflow builder, lets you make changes like moving SMS from primary factor to last-resort fallback as a tweak to the login journey rather than a change to your codebase.
Branch, a home and auto insurance provider serving more than 12,000 independent agents, augmented its existing authentication with Descope passkeys as a phishing-resistant primary method. The rollout reached 25% passkey adoption, exceeding Branch's internal goals, and cut authentication-related support tickets in half. [Read the Branch case study.](<https://www.descope.com/customers/branch>)
Start with a [Free Forever account](<https://www.descope.com/sign-up>) to build the flow yourself, or [book time with the team](<https://www.descope.com/demo>) to talk through a migration off SMS.
## FAQs about SIM swapping
---
### [What Is Passwordless Authentication and How It Works](https://www.descope.com/learn/post/passwordless-authentication)
*Full content: [https://www.descope.com/learn/post/passwordless-authentication.md](https://www.descope.com/learn/post/passwordless-authentication.md)*
Passwordless authentication lets users sign in without a password, using “something they have” or “something they are” instead. It prevents attacks that depend on stealing or guessing passwords–including phishing, credential stuffing, and password spraying–while making login faster for the user.
More passwords have led to more problems for everyone on the Internet. While they are useful for securing information in theory, passwords often create hurdles for users, developers, and admins alike. Using passwords leads to forgotten credentials, frustrating user experience, and (paradoxically), a plethora of security threats.
Enter the era of passwordless authentication, a new approach that precludes the need for passwords and embraces secure, low-friction user journeys.
Let’s dive in and see why passwordless authentication is reshaping the experience of users and developers alike. We’ll discuss why it’s needed, cover common passwordless authentication methods in use today, and share how app builders can get started on their passwordless journey.
## At a glance
- Passwordless authentication lets users sign in without a password, using a possession or inherence factor such as a passkey, magic link, one-time passcode, or authenticator app code.
- Passwordless auth methods remove the password entirely, which reduces the likelihood of common attacks such as phishing, credential stuffing, and password spraying.
- The main benefits are stronger security, a faster and simpler login, lower support costs from fewer password resets, and higher conversion at signup.
- Passwordless is often paired with adaptive checks so that higher-risk logins prompt an extra step, a process that’s sometimes called passwordless MFA.
- When choosing a [passwordless authentication solution](<https://www.descope.com/blog/post/passwordless-authentication-solutions>), teams weigh the supported methods, developer experience, compliance needs, and whether flows can be changed without an application rebuild or custom code.
## Quick facts
| **What passwordless authentication is** | Authentication methods that eliminate passwords and enable signing in with a possession (something you have) or inherence (something you are) factor, such as a passkey or magic link |
| **How it works** | Verifies a possession factor (a device, key, or code) or an inherence factor (a biometric), rather than a shared secret |
| **Main methods** | Magic links, one-time passcodes, authenticator apps, biometric authentication, and passkeys |
| **Key benefit** | Greatly reduces the effectiveness of phishing, credential stuffing, and password spraying by removing the password from the equation |
| **Who uses it** | Consumer apps, developer platforms, and regulated industries like healthcare and fintech that need phishing-resistant login |
## What is passwordless authentication?
Passwordless authentication is the collective name given to various user identity validation methods that do not use passwords. Instead of relying on traditional [password-based authentication](<https://www.descope.com/learn/post/password-authentication>), it utilizes alternative forms of validation such as biometrics, magic links, authenticator apps, passkeys, or similar methods that we’ll explain shortly.
If implemented thoughtfully, this approach not only simplifies the login process but also helps applications get to market faster, adopt and delight more users, and reduce their risk surface against credential-based attacks.
By removing passwords, which are often weak, reused across services, or susceptible to [phishing attacks](<https://www.descope.com/learn/post/credential-phishing>), passwordless authentication reduces the risk of account breaches and identity theft. It represents a paradigm shift in how online accounts are secured without negatively impacting the user experience.
### What is passwordless MFA?
Passwordless and [multi-factor authentication](<https://www.descope.com/learn/post/mfa>) (MFA) are sometimes mentioned in similar contexts. Therefore, it’s worth defining the terms separately and understanding where they differ. While passwordless auth replaces password-based authentication with other factors, MFA refers to using two or more authentication factors to validate user identities.
While common MFA implementation involves augmenting passwords with a second (passwordless) authentication factor, MFA can also be completely passwordless. Passwordless MFA combines a passwordless factor with an additional check, so a login is both password-free and multi-factor at the same time. For example, an app can use a fingerprint scan as the first authentication factor and an email magic link as the second authentication factor.
## How does passwordless authentication work?
Before getting into the details, it’s worth noting the three generally accepted authentication factors:
- Knowledge: Something only the user “knows” (e.g. passwords, security questions).
- Possession: Something only the user “has”.
- Inherence: Something only the user “is”.
Passwordless authentication works by confirming the identity of a user through alternative means to passwords, focusing on something the user has and something the user is, rather than something the user knows. Here’s an overview of the underlying principles and mechanisms:
- **Something the user has:** This could be a mobile device, a security token, or a security key. [Authentication](<https://www.descope.com/learn/post/authentication>) is achieved through a unique code or signal generated by the device. For example, a user might receive an email with a one-time passcode which they could use to log in.
- **Something the user is:** [Biometric authentication](<https://www.descope.com/learn/post/biometric-authentication>) checks unique physical characteristics of the user, such as fingerprints, facial recognition, or retinal scans. For instance, many smartphones now allow users to unlock their devices and access applications securely using their fingerprint or face scans.
#### Drag & drop passwordless authentication with Descope
[Going passwordless](<https://www.descope.com/use-cases/passwordless-authentication>) improves user experience and security for any app. However, setting up these authentication systems can be time-consuming. Descope abstracts away the complexity of authentication with a no-code workflow builder, ensuring that developers can spend more time building their core product.
[Sign up for Descope's passwordless authentication solution](<https://www.descope.com/sign-up>) to start your app's passwordless journey.
## Password-imposed problems
It’s a “shared secret” that passwords can be a hassle. Whether you’re trying to remember the right combination of letters and characters, coding them into an app, or working to keep them safe, passwords add a layer of complication to our online lives.
Passwordless authentication methods are the modern answer to this old problem, paving the way toward a smoother and safer digital experience. Here are some reasons why passwords have fallen out of favor and how passwordless authentication addresses these shortcomings.
### User friction
There’s no password fan club. The typical Internet user dislikes passwords and the friction they cause from login to checkout. Whether having to create and remember hundreds of unique passwords, going through laborious password reset flows, or constantly updating passwords for security reasons (that aren’t really secure), passwords offer no redeeming value to the average person online. The average person now manages [301 passwords](<https://www.descope.com/blog/post/auth-stats-2026#:~:text=301%20average%20passwords%20managed%20per%20person>), which is an enormous amount to keep straight without resorting to reuse or weak variations.
Let’s consider two equivalent applications vying for the same user: One app asks users to create a strong and unique password, while the other authenticates them with a fingerprint on their phone.
Which app is the user more likely to have a good first experience with? More importantly, which app is the user more likely to return to?
The statistics don’t lie. According to the [FIDO Alliance’s State of Passkeys 2026 report](<https://www.descope.com/blog/post/2026-fido-report>), 47% of consumers say they’re likely to abandon a purchase or sign-in when they can’t remember a password, and 17% say they’re highly likely to do so.
### Security headaches
Passwords are the “keys to the kingdom” most attackers seek and easily find. According to the [2026 Verizon Data Breach Investigations Report](<https://www.descope.com/blog/post/verizon-dbir-2026>), credential abuse still appears at some point in 39% of breaches (more than any other technique the report tracks), and credentials showed up as compromised data in 28% of breaches overall. Why does this keep happening?
Firstly, it’s because there’s no shortage of leaked passwords at the attackers’ fingertips. A June 2026 discovery of an exposed database found [24 billion username and password combinations](<https://tech-insider.org/24-billion-credentials-leaked-2026/>) compiled from dozens of prior breaches, sitting in the open for anyone to find.
Secondly, users often adopt bad behaviors when dealing with passwords. Since no one can realistically keep track of hundreds of unique passwords, users resort to “boilerplate” weak passwords or reuse the same password across multiple online applications. The 2026 DBIR found that users are more than four times as likely to be running a password that’s already been exposed in a prior breach than one that’s simply weak. A data breach on one application gives attackers the ammunition to try that same password elsewhere through [credential stuffing](<https://www.descope.com/learn/post/credential-stuffing>).
Thirdly, and most importantly, passwords are not a reliable indicator of a user’s identity. Initially designed for individuals to memorize, passwords become a vulnerability the moment they are compromised, allowing anyone who acquires them to masquerade as a legitimate user.
## High cost
Implementing passwords compels product owners and app developers to spend time and effort on non-core initiatives, like:
- Managing password infrastructure and storage
- Creating and updating password reset flows
- Adding security controls that protect against password-based attacks
- Allotting the help desk’s time to deal with password reset and locked account requests
The list of “password-related labor” is long. Considering these user frustrations and security issues, it’s clear this is not work that’s greeted with enthusiasm. Time and resources devoted to maintaining password systems come with significant trade-offs, diverting attention from potentially more valuable initiatives.
## Benefits of passwordless authentication
Passwordless authentication systems help apps get to market faster, shut down most credential-based attacks at their source, and delight end users. Here are some advantages of going passwordless:
- **Reduce fraud and account takeover:** Eliminating passwords prevents attackers from breaking authentication through credential stuffing, [brute force attacks](<https://www.descope.com/learn/post/brute-force-attack>), and phishing.
- **Onboard and engage more users:** Apps that do not require creating and remembering passwords will likely onboard users faster, keep them coming back, and generate a positive brand perception.
- **Focus resources on core initiatives:** Going passwordless eliminates password management and storage, password reset flows, and security investments to protect app servers against password-based attacks.
- **Cut support costs tied to password resets:** Fewer forgotten passwords means fewer help desk tickets and account lockout requests, freeing up support teams for higher-value work.
## Passwordless authentication methods
Passwordless methods verify users through a combination of possession and inherence factors. These factors are typically harder to spoof and more reliable indicators of a user’s identity than knowledge factors.
Before we explain the different methods, it’s worth noting that while often considered passwordless, [social logins](<https://www.descope.com/learn/post/social-login>) and [single sign-on](<https://www.descope.com/learn/post/sso>) technically are not that. Instead, they delegate authentication to identity providers where users have already created passwords.
| **Method** | **How it works** | **Security** | **Best for** |
| --- | --- | --- | --- |
| Magic links | An emailed or texted URL with an embedded token logs the user in when clicked | Good; depends on the security of the user’s inbox or phone | Low-friction consumer signup and login |
| One-time passcodes (OTP) | A dynamically generated code, delivered via SMS, email, or an app, grants one-time access | Moderate; SMS delivery is vulnerable to SIM swapping | Apps needing a familiar, universal fallback method |
| Authenticator apps | A TOTP code is generated on-device from a shared secret and the current time | Strong; resistant to interception, doesn’t rely on network delivery | Users already comfortable with a dedicated authenticator app |
| Biometric authentication | A fingerprint, face, or retinal scan verifies identity locally on the device | Strong; the biometric data never leaves the device | Mobile-first apps with modern device support |
| Passkeys | A device-bound cryptographic key pair replaces the password entirely, confirmed with a biometric or PIN | Strongest; phishing-resistant and unique to each site | Any app looking for the most secure, most modern default |
### Magic links
[Magic links](<https://www.descope.com/learn/post/magic-links>) are URLs with embedded tokens that, when clicked, enable users to log in without a password. These links are usually delivered to the user’s email account but can also be sent via SMS and other messaging services like WhatsApp.
Magic links indicate a user’s identity by verifying “something the user has.” This can be the user’s email address (for magic links delivered as an email) or their phone (for magic links delivered via SMS or other phone-based messaging apps).
> Did you know? In addition to authentication, you can use magic links in many other scenarios to activate users and grow adoption. For example, if users have items in their shopping carts but do not complete the purchase, a passwordless auth solution like Descope can send [embedded links](<https://docs.descope.com/flows/use-cases/email-verification>) that take users directly to those carts.
### One-time passwords or passcodes (OTP)
[One-time passwords](<https://www.descope.com/learn/post/otp>) or passcodes are dynamically generated numbers or letters that grant users one-time access to an application. Unlike passwords, an OTP is not static and changes every time the user attempts to log in.
OTPs can be delivered via SMS, email, messaging apps, and dedicated authenticator apps. Users like one-time passwords because they don’t need to remember them, they usually don’t require new hardware, and they’re already familiar with standard OTP delivery methods.
That said, OTPs can be phished. SMS authentication, in particular, can be vulnerable to [SIM swapping](<https://www.descope.com/learn/post/sim-swapping>) and [man-in-the-middle attacks](<https://www.descope.com/learn/post/mitm-attack>). In 2016, [NIST proposed](<https://www.nist.gov/blogs/cybersecurity-insights/questionsand-buzz-surrounding-draft-nist-special-publication-800-63-3>) that SMS be deprecated as an out-of-band second authentication factor, and organizations like the [Central Bank of UAE](<https://www.descope.com/blog/post/cbuae-notice-3057>) have followed suit. This guidance still shapes how security-conscious teams treat SMS OTP today: as a fallback rather than a primary method.
### Authenticator apps
[Authenticator apps](<https://www.descope.com/learn/post/authenticator-app>) operate based on time-based one-time passwords ([TOTP](<https://www.descope.com/learn/post/totp>)). A TOTP code is generated with an algorithm that uses a shared secret and the current time as inputs. This means the code changes at set intervals, usually between 30 to 90 seconds.
Hardware tokens like physical fobs or security keys can also generate TOTP codes. However, authenticator apps (software tokens) are the more widely adopted implementation since they don’t require users to carry hardware other than their mobile phone.
Authenticator apps are considered to be more secure and user-friendly than SMS authentication. It’s very tough for attackers to intercept TOTP codes and gain fraudulent account access.
Additionally, authenticator apps don’t depend on internet connectivity, mobile carriers, or delivery rates, making them usable in a broader range of scenarios than SMS OTP.
### Biometric authentication
Biometrics are physical or behavioral traits unique to an individual. Biometric authentication checks these traits to grant users application access. Popular [biometric authentication methods](<https://www.descope.com/blog/post/biometric-auth-methods>) in use today include [fingerprint scanning](<https://www.descope.com/learn/post/fingerprint-authentication>) and [facial recognition](<https://www.descope.com/learn/post/facial-recognition>).
Biometric authentication adoption has soared due to Apple, Google, Microsoft, and Samsung launching devices with built-in fingerprint scanning and facial recognition capabilities. Cross-device support with methods like [passkeys](<https://www.descope.com/learn/post/passkeys>) have further accelerated this trend.
Since biometric authentication is based on “who users are,” these traits are much more challenging to steal and repurpose than passwords, PIN codes, and other forms of knowledge-based authentication.
> Did you know? Biometric authentication implemented with the [FIDO standard](<https://www.descope.com/learn/post/fido2>) and [WebAuthn](<https://www.descope.com/learn/post/webauthn>) ensures that the biometric characteristics are securely stored and verified locally on the user’s device. This addresses privacy concerns associated with reading users’ biometric data. Since the data never leaves the device, there is nothing for attackers to compromise.
**Read More: **[**6 Top Benefits of Biometric Authentication**](<https://www.descope.com/blog/post/biometric-auth-benefits>)
### Passkeys
[Passkeys](<https://www.descope.com/learn/post/passkeys>) are a device-bound cryptographic key pair that replace passwords outright. A user registers a passkey once–typically confirmed with a fingerprint, face scan, or device PIN–and that same key is checked at every future login without ever being transmitted or stored on a server.
Passkeys have quickly become the passwordless method with the most momentum. The [FIDO Alliance’s State of Passkeys 2026](<https://www.descope.com/blog/post/2026-fido-report>) report estimates 5 billion passkeys are now in use worldwide, with 90% of consumers aware of them and 75% having enabled one on at least one account.
Because a passkey is unique to each site and cannot be reused, guessed, or phished, it addresses the weaknesses of magic links, OTPs, and even authenticator apps at the root. Built on the [FIDO2](<https://www.descope.com/learn/post/fido2>) and [WebAuthn](<https://www.descope.com/learn/post/webauthn>) standards, passkeys also sync across a user’s devices through their chosen platform (such as Apple’s iCloud Keychain or Google Password Manager), so signing in on a new device doesn’t require starting over.
## How to choose a passwordless authentication solution
Not every passwordless solution is built the same way, and the right fit depends on your users, your team, and your industry. A few factors matter most when evaluating options:
- **Supported methods:** Look for a solution that covers magic links, OTPs, authenticator apps, biometrics, and passkeys, so you can match the method to the use case instead of committing to just one.
- **Developer experience:** Time to integrate matters as much as the feature list. Strong SDKs, prebuilt UI components, and the ability to change a login flow without a full redeploy save real engineering time. Descope’s [no-code and low-code workflows](<https://docs.descope.com/flows>) and React and Next.js SDKs are built for this.
- **Flexibility to change without a rebuild:** Requirements shift as your user base grows. A platform that lets you adjust or add authentication methods through configuration, rather than new code, keeps pace with that change.
- **Compliance and data handling:** Regulated industries, such as healthcare and finance, need an auditable trail and data handling practices that meet the relevant compliance requirements.
- **Support for both customers and AI agents:** As more traffic to modern apps comes from AI agents rather than only humans, a forward-looking solution should be able to authenticate both.
| **If your priority is** | **Look for** | **Why** |
| --- | --- | --- |
| Developer experience | Strong SDKs, prebuilt UI, and flows that update without a redeploy | Cuts the engineering time needed to add and maintain passwordless login |
| Healthcare or another regulated industry | Passkey support, adaptive checks, and an auditable, compliant data trail | Meets compliance requirements while keeping login phishing-resistant |
| Fastest path to production | A no-code or low-code workflow builder | Avoids building authentication logic from scratch |
| Long-term flexibility | A platform that supports multiple methods side by side | Lets you add or swap methods as your user base and threat model evolve |
## Tips to implement passwordless authentication
Adopting a passwordless approach can seem like a daunting project to take on at first glance. Here are some tips to help app builders prioritize and phase out passwordless initiatives.
### Choose the right method(s) for your users
Not all passwordless experiences are created equal. Above all, the success of a particular authentication method depends on user fit. Consider the following questions before choosing a preferred authentication method:
- Are users likely to be aware of the method? Have they used similar techniques on other apps?
- Are users accessing the app mainly through desktop or mobile?
- How discerning are users about parting with their personal information (even if it’s just their email ID or phone number)?
- How security-conscious is the average user? Is security a deciding factor in choosing between two otherwise equivalent apps?
For example, consider a fintech app that users mainly access on their mobile phones. Since the app directly impacts users’ wallets, security is essential.
Considering all these points, this app might consider using WebAuthn-based fingerprint scans or passkeys to authenticate users. This option is convenient for users (since they are on their mobile devices anyway) and is one of the most secure authentication methods available.
Biometric authentication using WebAuthn uses both a possession factor (the user’s phone) and an inherence factor (the user’s fingerprint), but without the perceived inconvenience that sometimes comes with other MFA implementations.
**Also Read: **[**Should You Use Email Or Phone For Customer Authentication?**](<https://www.descope.com/blog/post/email-vs-phone-customer-authentication>)
### Pilot, then scale
For apps with plenty of users, it’s prudent to ask some users to test a passwordless technology pilot before rolling it out to the rest of the user base. Lessons learned from the pilot can be applied to the broader rollout.
Moreover, if the pilot’s results are encouraging, product owners can share positive user stories to speed up adoption from subsequent user sets.
### Invest in user education and messaging
While going passwordless improves user experience, implementing it without proper user education and messaging can have the opposite effect. This is especially true for apps that already have password-based authentication that users are familiar with.
Ensure that users receive communication about the upcoming change to their login flow, why the new way is better, and where they can reach out for any clarification.
## Go passwordless with Descope
Descope lets teams [add passwordless login](<https://www.descope.com/use-cases/passwordless-authentication>), including magic links, OTPs, passkeys, and biometrics, through [visual workflows](<https://www.descope.com/flows>) rather than building it from scratch. You can mix and match methods to create phishing-resistant flows, gradually migrate existing users, and adjust or add methods as your app grows, all without a rebuild.
[Sign up for a Free Forever account](<https://www.descope.com/sign-up>) to start your passwordless journey today, or [book time with our auth experts](<https://www.descope.com/demo>) if you have questions first.
[Sign up for a Free Forever account](<https://www.descope.com/sign-up>) to start your passwordless journey today. Have questions about our product or an active company project? [Book time with our auth experts](<https://www.descope.com/demo>).
## Frequently asked questions about passwordless authentication
---
## Blog
### [XAA vs. ID-JAG vs. EMA: What's the Difference?](https://www.descope.com/blog/post/xaa-vs-idjag-vs-ema)
XAA, ID-JAG, and EMA describe the same capability at three layers: a pattern, an IETF draft, and an MCP extension. Learn which term to use and when.
*Full content: [https://www.descope.com/blog/post/xaa-vs-idjag-vs-ema.md](https://www.descope.com/blog/post/xaa-vs-idjag-vs-ema.md)*
If you have been reading about how AI agents reach enterprise applications, you have probably seen three acronyms used in close quarters: XAA, ID-JAG, and EMA. They turn up in the same paragraph—sometimes the same sentence—and rarely with an explanation of how they relate.
They are three names for one capability, drawn from three different places: the name the ecosystem uses for the pattern, the IETF specification that defines the mechanism, and an extension to the Model Context Protocol that applies it. Knowing which of the three a term belongs to makes the rest of the conversation easier to follow, whether you are evaluating vendors, reading a specification, or deciding what to call the feature you are shipping.
## What is Cross-App Access (XAA)?
[Cross-App Access (XAA)](<https://www.descope.com/learn/post/id-jag-cross-app-access>) is the common name for a pattern: one application reaches another application's APIs or MCP server on a user's behalf, brokered by the enterprise identity provider that both applications already trust.
The relationship between the pattern and its specification mirrors one already familiar in auth terminology: SSO and OIDC. [Single sign-on (SSO)](<https://www.descope.com/learn/post/sso>) is what the capability is called, and [OpenID Connect (OIDC)](<https://www.descope.com/learn/post/oidc>) is one of the protocols that defines how it works. Cross-App Access is the capability, and the grant described in the next section (ID-JAG) is the underlying draft specification.
XAA reuses that SSO relationship so the [identity provider (IdP)](<https://www.descope.com/learn/post/identity-provider>) can also broker access between applications, rather than each pair of applications establishing its own connection through API keys or individual OAuth consent.
Two properties define it:
- The identity provider decides whether a given requesting application may reach a given resource application, and with which scopes, based on policy the enterprise controls centrally.
- The resource application's authorization server still issues its own access tokens and applies its own local policy, so the identity provider brokers the relationship without taking over authorization.
### How Cross-App Access (XAA) works
Three parties take part in a standard XAA flow: the requesting app (an AI agent or MCP client), the enterprise identity provider, and the resource app that owns the API or MCP server. On the resource app's side of the exchange, the work is handled by its authorization server (the same component that already issues its access tokens).
1. The user authenticates with the IdP through SSO and receives an ID token.
2. The requesting app exchanges that ID token at the IdP's token endpoint, asking for access to a specific resource app.
3. The IdP evaluates the request against enterprise policy, checking whether this requesting app may reach that resource app with the scopes requested.
4. If the request is allowed, the IdP returns a signed assertion scoped to that resource app.
5. The requesting app presents the assertion to the resource app's authorization server.
6. The resource app validates the signature against the IdP's public keys and issues a short-lived access token.
7. The requesting app calls the API with that access token until it expires.
## What is ID-JAG?
ID-JAG stands for Identity Assertion JWT Authorization Grant. It is the [IETF draft specification](<https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/>) that defines the token exchange in step 2 above, and the assertion that comes back in step 4. It also names the assertion itself, which is why you will see the term used for both the document and the token.
It is an Internet-Draft on the IETF standards track, at draft 04 as of May 2026, rather than a published RFC. The specification profiles Identity Chaining Across Trust Domains, which in turn combines two established standards:
- [OAuth 2.0 Token Exchange](<https://www.descope.com/learn/post/oauth-token-exchange>) governs how the requesting app trades its ID token for an assertion at the IdP.
- The [JWT Bearer grant](<https://datatracker.ietf.org/doc/html/rfc7523>) governs how the requesting app redeems that assertion for an access token at the resource app.
### What's inside an ID-JAG
An ID-JAG is a signed [JSON Web Token (JWT)](<https://www.descope.com/learn/post/jwt>) with a short lifetime, issued for one specific downstream authorization server. Its `typ` header (the token type declaration) must be `oauth-id-jag+jwt`, which lets a resource authorization server reject anything that was minted for a different purpose.
Here is a (non-runnable) example payload:
~~~javascript
{
"typ": "oauth-id-jag+jwt"
}
.
{
"jti": "9e43f81b64a33f20116179",
"iss": "https://idp.example.com/",
"sub": "user_8f2c41",
"aud": "https://auth.resourceapp.example/",
"client_id": "agent_a91b7",
"iat": 1789012045,
"exp": 1789012345,
"resource": "https://mcp.resourceapp.example/mcp",
"scope": "read:tickets write:comments",
"auth_time": 1311280970,
"amr": [
"mfa",
"phrh",
"hwk",
"user"
]
}
.
signature
~~~
There are many claims here, but the ones that matter most from a security standpoint are `aud`, `resource`, `client_id`, `scope`, and `sub`.
Of these, the claim implementers most often get wrong is `aud` (the audience claim). It names the issuer identifier of the resource authorization server, not the API or MCP server being reached. The protected resource is named separately by `resource` (the resource indicator). It's an important distinction because, as soon as one authorization server governs several resources (the typical trajectory for a SaaS product), audience and resource claims can't meaningfully be treated as the same thing:
- `aud` identifies the authorization server that should process the ID-JAG.
- `resource` identifies the particular resource for which authorization is being requested.
Think of the audience claim as a boundary where the identity provider's authority ends. It can say "this client is allowed to deal with that authorization server on this user's behalf within these specific parameters." That user is the `sub` (the subject claim) and the parameters are the `scope` (the permissions the IdP is willing to vouch for), which means they shape requests inside the boundary that the vendor then narrows or refuses. And, crucially, because `aud` names a single authorization server, an assertion minted for one destination cannot be presented at another; the draft specification calls this out as preventing "audience injection."
An ID-JAG is not an [access token](<https://www.descope.com/learn/post/access-token>). It is an input to the resource application's authorization decision. The resource authorization server validates it and then issues its own token, which is the credential that actually reaches the API. The assertion says who the user is and what the identity provider is prepared to authorize; the resource authorization server decides what it will actually grant.
## What is Enterprise-Managed Authorization (EMA)?
Enterprise-Managed Authorization (EMA) is an extension to the [Model Context Protocol (MCP)](<https://www.descope.com/learn/post/mcp>) that lets an administrator centrally authorize which MCP clients may reach which MCP servers, so users find those servers connected at first sign-in rather than authorizing each one themselves. The [MCP maintainers announced the extension as stable](<https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/>) in June 2026.
Under the hood, EMA uses the XAA pattern and the ID-JAG grant to do it. The MCP client obtains an assertion from the enterprise identity provider during sign-in and exchanges it for an access token at the MCP server's authorization server, which is the same sequence described earlier.
### How EMA fits into the MCP specification
MCP already had an [authorization specification](<https://www.descope.com/blog/post/mcp-auth-spec>) covering OAuth 2.1, [Client ID Metadata Document (CIMD)](<https://www.descope.com/learn/post/cimd>) and [Dynamic Client Registration (DCR)](<https://www.descope.com/learn/post/dynamic-client-registration>), and [Protected Resource Metadata (PRM)](<https://www.descope.com/learn/post/prm>). EMA covers the case where an enterprise, rather than an individual user, decides what an MCP client may reach.
It does that as an extension rather than as part of the core protocol. The [2026-07-28](<https://blog.modelcontextprotocol.io/posts/2026-07-28/>) specification introduced a formal extensions framework, and capabilities that ship there are additive and opt-in: an MCP server advertises support as a capability and the client negotiates it at connection time. Per-user OAuth remains the default for servers that have not adopted it.
### What EMA does not cover
EMA is a connection-level control. It settles whether a given user's client may reach a given server, and at what scope, at the moment the token is issued. It does not follow the session after that.
The identity provider evaluates policy once, when it mints the grant, and issues nothing afterward. What the MCP server sees on each subsequent request is the access token from its own authorization server, so enforcement of what an agent does inside an approved connection belongs to the resource server and the scopes it honors. Seeing "the enterprise authorized this connection" and thinking "this session is properly governed" is the reason EMA belongs alongside per-tool scoping (not in place of it).
## XAA vs. ID-JAG vs. EMA: key differences
| | **Cross-App Access (XAA)** | **ID-JAG** | **Enterprise-Managed Authorization (EMA)** |
| --- | --- | --- | --- |
| **What it is** | The common name for the pattern in which an identity provider brokers app-to-app access | The IETF draft specification defining the grant, and the name of the assertion it mints | An extension to the Model Context Protocol, and the administrator capability it delivers |
| **Where it is defined** | Named in the IETF draft as the informal name for the pattern | Within the Identity Assertion JWT Authorization Grant draft specification | The MCP extensions framework |
| **Who maintains it** | No single vendor; used broadly across the identity ecosystem | The IETF OAuth working group | The Model Context Protocol maintainers |
| **How the term is used** | "Our MCP server supports Cross-App Access." | "The IdP issues an ID-JAG scoped to that authorization server." | "Admins can centrally authorize MCP clients for their users." |
### Why the three terms get used interchangeably
Each name entered the conversation from a different direction. XAA names the pattern, and spread because the industry needed a word for it. ID-JAG arrived through the IETF as the specification that made the pattern concrete and interoperable. EMA came from the MCP community, which needed a name for the capability inside the context of the protocol.
The three also arrived close together. ID-JAG became an IETF OAuth working group document in 2025 and EMA reached stable status in June 2026, and a single announcement often touches all three at once, so writers reach for whichever name fits the sentence.
That is usually harmless. It becomes a problem when a reader concludes they need to choose among them, or when a security review asks which one a product supports and gets an answer at the wrong layer.
## How the three fit together
Consider an AI assistant that needs to read a user's tickets from a vendor's MCP server. A single request touches all three terms:
- The enterprise administrator has approved this assistant to reach that MCP server, and users find it already connected when they sign in. That is Enterprise-Managed Authorization: the capability, from the administrator's point of view.
- The assistant obtains authorization from the enterprise identity provider rather than from a separate consent screen at the vendor, and the vendor's authorization server still decides what to grant. That is Cross-App Access: the pattern.
- The assistant exchanges its ID token for a signed assertion audienced to the vendor's authorization server, and redeems it there for an access token. That is ID-JAG: the mechanism.
Each name is accurate for the part of the picture it describes. The confusion comes from using one where another belongs, and the terms are not interchangeable: a product can implement the grant without adopting the MCP extension.
### Which term to use when
Follow these rules of thumb to cover most situations:
- Use Enterprise-Managed Authorization when the audience is an administrator or a buyer and the subject is what the enterprise can control inside MCP. It is also the correct term for the extension itself.
- Use Cross-App Access when the subject is how applications establish trust with each other through an identity provider, particularly outside an MCP context. The pattern applies to any case where one application acts for a user in another application, not only to AI agents.
- Use ID-JAG when the subject is the exchange itself: token endpoints, claims, signatures, and validation. This is the term for engineering conversations and implementation work, and the correct name for the assertion.
Atlassian has published [an account of implementing EMA for Rovo MCP](<https://www.atlassian.com/blog/development/enterprise-managed-authorization-rovo-mcp-xaa-id-jag>) that walks through the same distinctions from an implementer's side.
## Cross-App Access with Descope
Both halves of the exchange need an implementation before any of this works in production. The identity provider has to mint assertions, and the resource authorization server has to validate them and issue its own tokens. The [Descope Agentic Identity Hub](<https://www.descope.com/use-cases/ai>) supports both.
- Validating ID-JAG assertions, so a company selling an MCP server can register each enterprise customer's identity provider as a trusted issuer scoped to that customer's tenant. Descope validates the assertion and issues a standard access token, so the MCP server itself needs no ID-JAG handling.
- Issuing ID-JAG assertions, so an organization's own agents can reach any other MCP server or API under policies evaluated on each request.
- [Self-service Cross-App Access](<https://docs.descope.com/auth-methods/sso/sso-setup-suite#cross-app-access-xaa-configuration>) setup in the SSO Setup Suite, where a customer's administrators configure it themselves alongside SSO, SCIM, and JIT provisioning rather than filing a ticket with your team.
Descope also covers the surrounding MCP authorization work these assertions plug into, including [OAuth 2.1](<https://www.descope.com/blog/post/oauth-2-0-vs-oauth-2-1>) and [PKCE](<https://www.descope.com/learn/post/pkce>), [CIMD](<https://www.descope.com/learn/post/cimd>) and [DCR](<https://www.descope.com/learn/post/dynamic-client-registration>), consent management, and per-agent and per-tool scopes.
## Getting started with XAA, EMA, and ID-JAG
The three terms will keep appearing together, because the capability they describe is being adopted in three places at once: a specification moving through the IETF, a protocol extension stabilizing in MCP, and products shipping the pattern to enterprise buyers. Knowing which name belongs where is what keeps a vendor evaluation, a specification review, and a roadmap conversation from talking past each other.
[Sign up for a Free Forever account with Descope](<https://www.descope.com/sign-up>) and start building secure, scalable auth flows for your agents and MCP servers. Have questions about Cross-App Access, ID-JAG, or EMA? [Book time with our experts](<https://www.descope.com/demo>).
## FAQs about XAA, ID-JAG, and EMA
---
### [Descope vs Auth0 for AI Agent and MCP Authentication](https://www.descope.com/blog/post/descope-vs-auth0-ai-agent-mcp-auth)
Compare Descope vs Auth0 for AI agent and MCP authentication. Explore agent identity, MCP authorization, credential vaulting, consent, and human oversight.
*Full content: [https://www.descope.com/blog/post/descope-vs-auth0-ai-agent-mcp-auth.md](https://www.descope.com/blog/post/descope-vs-auth0-ai-agent-mcp-auth.md)*
AI agents are giving a new meaning to the concept of authentication and identity.
Traditional identity platforms work simply: the user logs in, verifies their identity, and gains access to the app. Auth0 has spent over ten years improving this method and remains one of the most trusted platforms for application authentication and authorization.
Autonomous AI agents challenge this model in ways most identity platforms were not designed to handle. These agents act on behalf of users, sometimes without any human involvement. Instead of using others' credentials, they need their own identities. They connect to MCP servers that must be secured and control which clients can register. Instead of broad and continuous access, they request specific, limited permissions with delegated consent. The third-party credentials they use must be stored securely and not appear in prompts or logs. Their access should be verified by context-aware policies, not just fixed roles. For the most sensitive actions, a human must still be able to intervene and approve.
To secure agentic applications, identity must extend beyond simple human user authentication. The Descope [Agentic Identity Hub](<https://www.descope.com/use-cases/ai>) offers a unified identity layer designed for agents, MCP servers, credentials, policies, and users.
This blog post compares how Descope and Auth0 handle authentication of AI agents and MCPs to help you choose the right platform for your next project.
**Also Read: **[**A Complete Comparison of Descope and Auth0**](<https://www.descope.com/descope-vs-auth0>)
## AI agent and MCP authentication requirements
[Agentic identity](<https://www.descope.com/learn/post/agentic-identity>) is not just about adding OAuth to an AI agent. It is about building an identity layer that scales with how agents actually operate.
- **First-class agent identities **- Every AI agent needs an identity of its own instead of a shared service account or a borrowed user token. Agents that act independently, retrieve their own credentials, and get revoked individually require a dedicated identity model built for non-human actors.
- **Secure **[**MCP server authentication**](<https://www.descope.com/mcp-auth>) - Each MCP server should have its own authorization boundary so that only registered agents and clients can connect and access can be controlled separately from the rest of the application.
- [**OAuth**](<https://www.descope.com/learn/post/oauth>)**-based delegated authorization** - Agents should act with permission delegated by a user or an organization rather than having universal access. The agentic identity system should link each action an agent takes to the specific scope granted to it, ensuring access can be audited and revoked.
- **Granular scopes and delegated consent** - Agents should receive only the narrow, task-specific scopes that a job demands, and users should have a clear opportunity to consent to that level of access. Broad, standing scopes turn one compromised agent into a much greater exposure surface.
- **Secure credential storage and retrieval **- Agents frequently need third-party credentials, such as OAuth tokens or API keys, to complete a task. Those credentials must stay vaulted and scoped, retrieved only at the moment of use rather than embedded in prompts, code, or logs.
- **Context-aware authorization policies** - Static roles are not enough once agents start chaining tool calls together. Authorization needs to evaluate context–such as which MCP server, which credential, and which user relationship is involved–before granting access.
- **Human-in-the-loop approval **- Some agent actions carry enough risk that a human should confirm them before execution. Sensitive actions need a built-in approval step that uses authentication methods people already use and trust.
- **Support for emerging agent identity standards** - The agent identity ecosystem is still being developed, with specifications such as [MCP](<https://www.descope.com/learn/post/mcp>), OAuth, [CIMD](<https://www.descope.com/learn/post/cimd>), [Dynamic Client Registration](<https://www.descope.com/learn/post/dynamic-client-registration>), and Enterprise-Managed Authorization/[Cross-App Access](<https://www.descope.com/blog/post/xaa>) changing rapidly. Platforms must keep up with these standards so agentic applications remain interoperable as they develop.
When these capabilities are foundational, agentic expansion becomes predictable. Without them, every new agent, MCP server, or credential becomes a manual security review instead of a repeatable pattern.
## Agent identity: First-class agent identities vs emerging agent principals
### Descope
Descope is built around [first-class agent identities](<https://docs.descope.com/agentic-identity-hub/agents>), not service accounts layered on top of a human user record. Each authorization an agent receives creates its own agentic identity record, so agents can be discovered, governed, and revoked independently.
- Creates a distinct agentic identity record for each authorization an agent receives
- Maintains internal and external agents in a single agent directory
- Supports filtering, tagging, and management of agents at scale
- Revokes individual or multiple agentic identities without removing the underlying agent
- Bulk-revokes filtered agent identities across multiple users at once
Descope treats every agent as a governable identity in its own right, making agent lifecycle management operationally predictable.
### Auth0
Auth0's agent identity model is still developing. The Agent as Principal capability is available by invitation only, while agentic identities are offered separately from Okta for AI Agents.
- Does not provide an agent-specific directory
- Agentic identities exist alongside a broader, separately positioned Okta for AI Agents offering
- Supports revoking individual or all grants for a given user
- Has no equivalent to filtered, bulk revocation across many agents at once
Auth0 can support agent scenarios today, but its purpose-built agent identity model is not yet broadly available.
**Bottom Line: **Descope treats agents as identities that can be independently discovered, governed, and revoked throughout their lifecycle, while Auth0's agent-specific identity model is still in early access.
## MCP server protection: First-class MCP resources vs standard APIs
### Descope
Descope models each [MCP server as a first-class identity resource](<https://docs.descope.com/agentic-identity-hub/mcp-servers>). Every server gets its own OAuth authorization server, so scopes, registered clients, and connection policies can be managed at the server level.
- Gives each MCP server its own OAuth authorization server
- Defines scopes and registered clients on a per-server basis
- Controls which agents can connect to individual MCP servers
- Uses wildcard domain allowlists to streamline client registration across many servers
- Maps scopes declaratively to roles and connection tokens per server
Descope makes the MCP server itself a unique OAuth resource server with many MCP-specific features instead of another API sitting inside the tenant.
### Auth0
Auth0 treats MCP servers as regular APIs within the tenant. Since there is no separate identity object for MCP servers, client registration, scopes, and roles are managed at the API or tenant level.
- Registers MCP servers as standard APIs within the tenant
- Configures client registration tenant-wide rather than per server
- Defines scopes on the API object rather than the server itself
- Keeps roles and permissions managed at the tenant level regardless of how many MCP servers you add
Auth0 can protect the traffic to an MCP server, but the server itself is not treated as its own identity resource.
**Bottom Line:** Descope makes the MCP server itself a governable identity resource rather than treating it as another API sitting inside the tenant.
## Scopes and consent: Orchestrated authorization vs application-driven logic
### Descope
Descope maps MCP scopes to[ connection tokens](<https://docs.descope.com/mcp>), and then matches those tokens to the scopes needed by downstream providers. Authentication, MCP consent, and provider consent are all handled together in one[ configurable Flow](<https://www.descope.com/flows>).
- Maps MCP scopes directly to connection tokens
- Maps connection tokens to the downstream provider scopes they require
- Collects consent before execution or dynamically at tool-call time
- Adds MFA and step-up authentication into the same consent journey
- Lets non-technical teams adjust consent logic without redeploying code
Descope brings authentication, delegated consent, and downstream authorization into one orchestrated identity journey.
### Auth0
Auth0 sets scopes for API resources and manages provider-scope mappings within the application code. MCP consent is gathered at login, while advanced consent or step-up logic is handled using Actions code.
- Defines scopes on API resources
- Provider-scope mappings are handled in application code
- MCP consent is collected during login
- Advanced consent and step-up logic uses Actions code
Auth0 supports the same building blocks, but assembling them into one consent journey is left to application code.
**Bottom Line:** Descope brings authentication, delegated consent, and downstream authorization into a single orchestrated identity journey, while Auth0 assembles the same outcome from API scopes and application code.
## Credential vaulting: Unified agent credentials vs OAuth token storage
### Descope
Agentic applications frequently need more than OAuth tokens. Descope [vaults OAuth tokens and API keys together,](<https://docs.descope.com/identity-federation/outbound-apps/connect>) scoping credentials to individual users or tenants and refreshing them automatically.
- Scopes credentials to individual users or tenants
- Automatically refreshes and rotates credentials
- Connects to 50+ prebuilt providers out of the box
- Extends to generic OAuth and custom OIDC providers for anything not prebuilt
- Collects credentials through Flows, backend APIs, embeddable widgets, or [hosted admin portal](<https://docs.descope.com/widgets/admin-portal>)
Descope gives agents one place to retrieve any credential they need, instead of separate systems for tokens and keys.
### Auth0
Auth0's vault stores OAuth tokens for individual users and refreshes them automatically, but API keys require separate credential management outside the vault.
- Stores OAuth tokens for individual users
- Automatically refreshes stored OAuth tokens
- Supports 30+ prebuilt providers
- Extends to additional providers through Custom OAuth2 connections
Auth0 covers OAuth token storage well, but teams still need a separate system for API keys and other credential types.
**Bottom Line: **Descope provides one unified vault for both OAuth credentials and API keys, while Auth0's vault is scoped to OAuth tokens.
## Agent authorization: Context-aware policies vs scopes, roles, and Actions
### Descope
Descope enforces [authorization policies](<https://docs.descope.com/policies>) at both token issuance and token exchange, applying least-privilege access by default. Policies can be built around users, tenants, permissions, claims, agent tags, and more.
- Enforces policies during token issuance and token exchange
- Uses least-privilege access as the default setting
- Scopes authorization policies to individual MCP servers
- Controls which agents can access certain stored credentials
Descope extends one policy model across MCP servers, tokens, and credentials instead of treating each as a separate concern.
### Auth0
Auth0 builds authorization from API scopes, tenant roles, and Actions, applied at token issuance. There is no dedicated per-MCP-server policy engine or independent layer governing credential access.
- Configures scope and role logic separately for each API and tenant
- Provides no dedicated per-MCP-server policy engine
- Provides no independent policy layer governing credential access
Auth0 can reach similar coverage, but it requires combining several separately configured and priced capabilities.
**Bottom Line:** Descope extends authorization across the agent's full chain of access, from MCP servers to tokens to downstream credentials, while Auth0 assembles equivalent coverage from several separately configured and priced pieces.
## Human oversight: Flexible step-up vs CIBA-based approval
### Descope
Descope supports human-in-the-loop approval through email, step-up authentication and [CIBA](<https://www.descope.com/learn/post/ciba>), delivered through the Descope Agent Auth SDK. Teams can reuse [MFA](<https://www.descope.com/use-cases/mfa>), [passkeys](<https://www.descope.com/use-cases/passkeys>), [biometrics](<https://www.descope.com/use-cases/biometrics>), SSO, or device checks to apply stronger verification before a sensitive agent action.
- Human-in-the-loop approval through step-up authentication and CIBA
- Both mechanisms are supported through the Descope Agent Auth SDK
- Uses MFA, passkeys, biometrics, SSO, or device checks
- Applies stronger verification before sensitive agent actions
Descope turns existing authentication methods into an approval step for agent workflows, without a separate approval channel.
### Auth0
Auth0 lets you use human-in-the-loop approval with CIBA, sending approvals through Guardian push notifications. If you want to use email-based approvals, you will need a paid add-on.
- Supports human-in-the-loop approval through CIBA
- Approvals can be delivered through Guardian push
- Email approvals require a paid add-on
Auth0 covers push-based approval well, but reaching email approval adds cost.
**Bottom Line: **Descope lets teams use the authentication methods they already have to add human approval to sensitive agent workflows, rather than standing up a separate approval channel.
## Standards and interoperability: Building around the evolving agent identity ecosystem
### Descope
Descope tracks the standards agent and MCP identity depend on as they emerge, including OAuth 2.1, [PKCE](<https://www.descope.com/learn/post/pkce>), [CIMD](<https://www.descope.com/learn/post/cimd>), and [Dynamic Client Registration](<https://www.descope.com/learn/post/dynamic-client-registration>). It also supports both sides of [Cross-App Access](<https://www.descope.com/blog/post/xaa>), issuing and validating the ID-JAG assertions that carry enterprise-managed authorization between agents and MCP servers.
- Supports OAuth 2.1 and PKCE for MCP authentication
- Supports CIMD and Dynamic Client Registration
- Supports protected resource metadata
- Validates ID-JAG assertions, so enterprise customers govern agent access to your MCP server through the identity provider they already run
- Issues ID-JAG assertions, so agents you run reach any MCP server that accepts them
- Adds Cross-App Access to the [SSO Setup Suite](<https://docs.descope.com/auth-methods/sso/sso-setup-suite#cross-app-access-xaa-configuration>), so tenant admins configure it without a support ticket
Descope brings these standards into one platform rather than requiring teams to track them across separate products.
### Auth0
Auth0 supports the same core standards. Its Cross App Access feature covers both sides of the exchange: resource-side validation of ID-JAG assertions, and client-app capabilities brokered through Token Vault, which is in Early Access as of September 2026.
- Supports OAuth 2.1, PKCE, CIMD, DCR, and protected resource metadata
- Cross App Access validates ID-JAG assertions on the resource side
- Client-app capabilities broker the exchange through Token Vault
- Cross App Access capabilities are in early access rather than general availability
**Bottom Line:** Both platforms support both sides of the Cross-App Access exchange. The differences are maturity and who does the setup: Descope's support is generally available and configurable by tenant admins in the SSO Setup Suite, while Auth0's is in early access and configured by the application vendor.
## Developer experience: Purpose-built Agent Auth SDK vs distributed agent tooling
### Descope
Descope provides a dedicated [Agent Auth SDK](<https://docs.descope.com/agentic-identity-hub/agent-auth-sdk>) for Python and TypeScript, with integrations across major AI agent and MCP libraries. Authentication, consent, credentials, and human approval are managed together, using the same tooling as user and B2B identity.
- Dedicated Agent Auth SDK for Python and TypeScript
- Integrates with leading AI agent and MCP libraries
- Handles authentication, consent, credential management, and human approval
- Provides unified tools for user, B2B, MCP, and agentic identity management
Descope gives developers one SDK to reach across every layer of agentic identity.
### Auth0
Auth0 provides SDKs and integrations that support agentic use cases, but agent capabilities are distributed across multiple libraries, and agent and MCP functionality can span separate Auth0 and Okta capabilities.
- Offers SDKs and integrations designed for agent-based applications
- Agent features are spread out over several libraries
- Agent and MCP features may use different Auth0 and Okta tools
Auth0 developers often need to combine several libraries and products to cover the same ground.
**Bottom Line:** Descope provides a specialized Agent Auth SDK designed specifically around agent and MCP identity workflows.
## Descope vs Auth0 for AI agents and MCP: At-a-glance
| **Capability** | **Descope** | **Auth0** |
| --- | --- | --- |
| Agent identity | First-class agent identities with centralized directory and granular revocation | Agent as Principal in invite-only early access |
| MCP server identity | First-class MCP resources with per-server clients, scopes, and policies | MCP servers represented as standard APIs |
| Scopes and consent | Declarative scope mapping with orchestrated consent and step-up | API scopes with provider mappings and advanced logic in application code |
| Credential vault | OAuth tokens and API keys with user or tenant scoping | User-scoped OAuth tokens; API keys managed separately |
| Authorization | RBAC, ABAC, ReBAC, agent policies, MCP policies, and credential policies | API scopes, roles, Actions, plus separately priced FGA |
| Human oversight | CIBA and step-up with multiple verification methods | CIBA with Guardian push and paid email approval |
| Standards | OAuth 2.1, PKCE, CIMD, DCR, protected resource metadata; Cross-App Access issuance and validation, generally available | OAuth 2.1, PKCE, CIMD, DCR, protected resource metadata; Cross App Access issuance and validation, in early access |
| Developer experience | Dedicated Python and TypeScript Agent Auth SDK | Agent functionality distributed across multiple libraries |
## Customer story: Cequence Security secures its AI Gateway with Descope
Enterprise identity requirements do not stop at human users, and Cequence Security is a clear example of why.
Cequence protects enterprise applications and data in the AI era, processing roughly 10 billion API transactions a day and safeguarding more than $10 trillion in digital assets across 4 billion user accounts. Cequence originally adopted Descope to solve for true multi-tenancy and self-service SSO, replacing custom claims and workarounds their previous provider required. The results were immediate: SSO-related support tickets dropped by more than 90%, new customer onboarding now takes minutes, and Cequence has fielded no SSO support calls in the last 18 months.
As Cequence extended its platform into agentic AI, that same identity foundation carried over. Descope now provides MCP authentication and authorization for the Cequence AI Gateway, giving Cequence a way to secure agent and MCP interactions without standing up a separate identity system for AI use cases.
Read more: [Cequence Security: Flexible Auth & AI-Ready Infrastructure](<https://www.descope.com/customers/cequence-security>)
## Migrating or extending Auth0 for agentic applications
Adding agent and MCP support does not have to mean ripping out an existing Auth0 deployment or forcing a disruptive cutover. A well-planned transition focuses on securing new agentic surface area first, consolidation second.
Descope supports both full replacement and phased augmentation. You can migrate user authentication off Auth0 entirely, or introduce Descope specifically for agent identity, MCP protection, and credential vaulting while keeping your existing Auth0 integrations intact.
- Replace Auth0 fully or augment selectively based on your roadmap
- Use the dedicated [Auth0 Migration Guide](<https://docs.descope.com/migrate/auth0?_gl=1*ozhzzr*_gcl_au*MjAwMjYyMDMzLjE3ODIxNDY3MTEuMTQzNTk1OTAxMC4xNzgyMzE1NTY4LjE3ODIzMTU1Njg.*_ga*NTYwNDQ1NDI2LjE3NjMxNDgxNDM.*_ga_5W6KZKEKFX*czE3ODcyNjgwMjkkbzI3MCRnMSR0MTc4NzI2OTY2MCRqNTckbDAkaDIwODkzMDQ3MzY.#auth0-migration-guide>) for full and hybrid migration walkthroughs
- Use [Session Migration](<https://www.descope.com/blog/post/session-migration>) to switch from Auth0 without disrupting logged-in users
- Use the [Auth0 AI agent migration skill](<https://www.youtube.com/watch?v=KQZC7FO--aU>) to give your AI agent the expertise to plan a start-to-finsh migration that maps your current Auth0 setup to Descope equivalents.
- Use [Bring Your Own Auth](<https://docs.descope.com/mcp/bring-your-own-auth>) to protect new MCP servers and agentic applications with Descope while existing user authentication stays on Auth0
By using standards-based federation and controlled cutovers, you can introduce agent and MCP identity without forcing changes on existing users or breaking current integrations.
## Conclusion: Authentication for applications vs identity for agentic systems
Auth0 offers well-established authentication and authorization capabilities and is now extending them to applications involving AI agents. However, deploying production-grade agentic systems brings a broader identity challenge than simply adding a login screen for a bot.
Descope approaches these questions as a connected identity system with first-class agent identities, MCP server protection, credential vaulting, context-aware authorization, consent orchestration, and built-in human oversight.
When people are developing AI agents and MCP systems, the difference lies not so much in adding authentication to an agent as it does in setting up an identity and authorization layer that is designed from the beginning for autonomous software.
If you want to see how Descope's agentic identity layer fits into what you're building, [meet with our auth experts](<https://www.descope.com/demo>). Or [sign up](<https://www.descope.com/sign-up>) for a Free Forever Account and start securing your AI agents and MCP servers today.
## FAQs about Descope vs Auth0 for AI Agent and MCP Auth
---
### [SSO For Your Agents: Cross-App Access Support in Agentic Identity Hub](https://www.descope.com/blog/post/xaa)
Let your customers manage agent access to your MCP server using existing IdPs. Provide short-lived, scoped tokens for your AI agents to access any MCP server.
*Full content: [https://www.descope.com/blog/post/xaa.md](https://www.descope.com/blog/post/xaa.md)*
Hello Descopers! We're delighted to share that Cross-App Access (XAA) support is generally available as a part of the [Agentic Identity Hub](<https://www.descope.com/use-cases/ai>). XAA is a standards-based way of letting every enterprise customer manage and control AI agent access through the identity provider they already trust.
Descope is among the first identity providers to support both:
- **ID-JAG token validation**, which enables SSO-like login for any AI agent accessing your MCP server.
- **ID-JAG token issuance**, which enables SSO-like login for your AI agents accessing any MCP server.
You can read the[ Enterprise-Managed Authorization documentation](<https://docs.descope.com/agentic-identity-hub/enterprise-managed-authorization>) to see how issuance and validation are configured in Descope, or try the flow yourself in the[ Cross-App Access developer playground](<https://www.crossappaccess.guru/#sign-in>). To learn more about the Why, What, and How of XAA support, keep on reading.
## The identity gap between AI agents and enterprise buyers
AI agents are becoming the primary consumers of enterprise APIs, and B2B companies are building MCP servers so those agents can reach intended services and data. The identity patterns those servers inherit, though, were designed for humans and static services rather than for autonomous and “unpredictable” software like AI agents.
### What API keys and consent screens leave behind
Most MCP servers in production today rely on one of two mechanisms, with both of them running into limits at enterprise scale.
API keys are the default path. [2026 research from Gravitee](<https://www.gravitee.io/blog/state-of-ai-agent-security-2026-report-when-adoption-outpaces-control>) found that only 22% of teams treat agents as independent identities, with most relying on shared API keys.However, API keys are often:
- Long-lived, since they do not expire unless somebody manually revokes them.
- Over-scoped, granting broad access rather than permissions for the task at hand.
- Decentralized, since they are spread across config files, environment variables, and local machines.
OAuth consent flows improve on this with expiring tokens and explicit user permission, but they introduce a different set of problems once an organization connects more than a handful of applications.
- Users click through repeated consent prompts.
- IT has no single view of which applications can reach which data.
- Access management stays fragmented across each resource application.
- Security teams cannot approve safe integrations or block risky ones ahead of time, because every authorization decision happens at the level of an individual user.
Neither mechanism suits an enterprise agent. What does suit enterprise agents is **using their existing identity providers**.
When a B2B company exposes an MCP server, its enterprise customers now ask whether their own security team can control which agents reach the MCP server, using the identity provider they already run.
Answering this request per customer means building token exchange, per-tenant issuer trust, claim mapping, and audience validation, then maintaining all of it as the MCP authorization specification changes.
## Cross-App Access 101
Cross-App Access is an open protocol that standardizes how an AI agent gets access to another application's APIs or MCP server. It is built on the[ Identity Assertion JWT Authorization Grant](<https://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-authz-grant-01.html>) (ID-JAG) and was adopted as the Enterprise-Managed Authorization extension to the Model Context Protocol.
Rather than a static API key or a consent screen, the identity provider that both applications already trust mints a short-lived, scoped assertion for each request. An agent signed in to one application reaches another application's API or MCP server with no second login.
### How it works
Three parties take part in an XAA flow: the requesting app (the agent or MCP client), the enterprise IdP, and the resource app that owns the API or MCP server.
1. The user authenticates with the IdP through SSO and receives an ID token.
2. The requesting app exchanges that ID token for an ID-JAG at the IdP's token endpoint.
3. The IdP validates the request against company policy, checking whether the requesting app is allowed to reach the resource app with the scopes it asked for.
4. If the request is approved, the IdP issues a signed ID-JAG assertion back to the requesting app.
5. The requesting app presents the assertion to the resource app's authorization server.
6. The resource app validates the signature against the IdP's public keys and issues a short-lived access token.
7. The requesting app calls the API with that token until it expires.
**Also Read:**[ What Is Cross-App Access (XAA) and How It Works](<https://www.descope.com/learn/post/id-jag-cross-app-access>)
## Cross-App Access in the Agentic Identity Hub
Descope supports both sides of the XAA exchange as an issuer and validator of ID-JAG tokens.
### Validating ID-JAG tokens
Validation is for companies that sell an MCP server to enterprises. You can:
- Register a trusted issuer for each tenant so an assertion minted for one customer cannot be used against another.
- Accept assertions from Okta, Ping, and other standards-compliant providers.
- Apply per-organization scope policies based on user roles, tenant membership, and claims carried over from the customer's identity provider, so two customers on the same MCP server can receive different levels of agent access.
Your MCP server does not need to understand ID-JAG. Descope validates the incoming assertion, matches its subject to the user provisioned through that customer's SSO connection, and issues a standard access token that your server validates the way it validates any other request.
### Issuing ID-JAG tokens
Issuance is for organizations that run their own AI agents and want those agents to reach MCP servers and APIs. You can:
- Register the downstream target as an MCP Server or API Resource and mirror the scopes it expects.
- Point the MCP client at Descope as its identity provider.
- Write a token exchange policy that governs which agents and users can obtain an assertion for that resource, and with which scopes.
Because the exchange happens per request, policies are evaluated in the request path rather than baked into a long-lived credential.
The difference in user experience with and without XAA is stark. Once XAA is enabled, your agent can automatically connect to all authorized MCP servers and APIs without repeated consent prompts or re-authentication.
### Self-service XAA setup for tenant admins
Cross-App Access now also sits in the Descope [SSO Setup Suite](<https://docs.descope.com/auth-methods/sso/sso-setup-suite>) alongside SSO, SCIM, and JIT provisioning. Your customers' IT admins can choose their identity provider, establish trusted issuers, register their AI agents, and map user attributes through a guided flow… all without a support ticket or manual back-and-forth with your team.
## Cross-App Access use cases
### Enterprise-ready MCP servers
Consider a B2B analytics company, Arclight Analytics, that has shipped a customer-facing MCP server so their users can query dashboards and pull reports from Claude or ChatGPT.
Arclight uses the Agentic Identity Hub for the full auth layer on that server. Even without XAA, they could:
- Securely connect the MCP server to agents with OAuth 2.1 and PKCE.
- Support spec-compliant client registration ([CIMD](<https://www.descope.com/blog/post/cimd-support>) and DCR) with risk assessment flows applied at registration time.
- Expose per-agent and per-tool scopes, so an agent that reads dashboards cannot export the underlying dataset.
With XAA, each enterprise customer can connect their own IdP as a trusted issuer and their security team can decide which agents reach Arclight's data.
When a prospect's security team asks whether agent access can be managed from their Okta tenant, Arclight's answer is a configuration step their customer completes themselves rather than an engineering commitment on the deal timeline.
### Managing internal AI agents
Now consider Sundial Logistics, a fictional shipping company running internal agents that pull ticket history, check inventory systems, and file updates across several third-party MCP servers.
Before XAA with Descope, each agent held a static API key per service. Sundial had no way to tell which agent used which key, no way to narrow an agent's access without re-issuing credentials, and no way to revoke access without hunting down every key.
With ID-JAG issuance, Descope becomes the identity provider for those agents:
- Each downstream MCP server and API is registered as a Resource with the scopes it expects.
- A token exchange policy decides which agents, users, and tenants can reach each resource, which is evaluated on every request.
- Agents receive a short-lived, scoped assertion rather than a credential that works everywhere indefinitely.
- Every exchange is logged against the agent identity, the delegating user, and the resource, and streams to Sundial's SIEM alongside the rest of their audit data.
## Toward agent access without the second login
Enterprise buyers already know what good access management looks like for their employees, and they are asking for the same thing for the agents acting on their behalf. Cross-App Access gives the industry a standards-based way to deliver it, and supporting both issuance and validation means a Descope customer can be on either side of that exchange, or both.
[Sign up for Descope](<https://www.descope.com/sign-up>) to start using Cross-App Access today, or[ book a demo with our auth experts](<https://www.descope.com/demo>) to learn more.
## Frequently asked questions about Cross-App Access
---
### [Biometric Authentication Methods: Types, Benefits, and Examples](https://www.descope.com/blog/post/biometric-auth-methods)
Learn what biometric authentication is, its main types, and how it works, from fingerprint & face to iris & voice. See the benefits and how to add it to apps.
*Full content: [https://www.descope.com/blog/post/biometric-auth-methods.md](https://www.descope.com/blog/post/biometric-auth-methods.md)*
Biometric authentication verifies a person’s identity using a unique physical or behavioral trait, such as a fingerprint, face, iris, or voice, instead of something they have to remember or carry. It falls under the “something you are” authentication factor, and is most often paired with another factor as part of multi-factor or passwordless login.
The use of biometrics has surged in recent years, with [more than half of all users authenticating with the technology daily](<https://www.aware.com/press-releases/new-consumer-report-from-aware-reveals-widespread-trust-in-biometrics/>). As user adoption increases, so do the available [biometric authentication](<https://www.descope.com/learn/post/biometric-authentication>) methods.
From your digits to your DNA, there’s not much that modern technology can’t scan. Using biometrics for authentication isn’t new, but the range of options has expanded fast, so if you’re thinking about implementing biometric authentication for your app, organization, or digital service, you have plenty to choose from.
## At a glance
- Biometric authentication verifies identity using a unique physical or behavioral trait, such as a fingerprint, face, iris, voice, or the way a person walks.
- The main methods split into physiological types (facial recognition, fingerprint scanning, iris and retina recognition, voice recognition, and hand geometry), and behavioral types (gait and vein recognition).
- Biometrics belong to the “something you are” authentication factor and are hard to guess, steal, or share, which makes them strong against phishing and account takeover.
- Because a trait can’t be reset like a password, biometric systems store a mathematical template rather than the raw image, and are usually paired with another factor.
- For apps, biometric login methods are most often delivered through passkeys and the WebAuthn standard, where the fingerprint or face unlocks a device-bound key rather than being sent to the server.
## Quick facts
| **What biometric authentication is** | Validating identity with a unique physical or behavioral trait instead of a password |
| **Which factor it belongs to** | “Something you are,” or the inherence factor |
| **Main types** | Facial recognition, fingerprint scanning, iris/retina recognition, voice recognition, hand geometry, plus emerging gait and vein recognition |
| **How it’s stored** | As a mathematical template (not the raw image) ideally kept on the user’s device |
| **Key benefit** | Nothing to remember, phish, or reuse across sites |
## What is biometric authentication?
Biometric authentication is a way of confirming identity using a measurable physical or behavioral trait rather than a password or PIN. Instead of asking a user to remember something, it checks something about them: a fingerprint, a face, an iris pattern, a voice, or even the way they walk.
This maps to the “something you are” factor in authentication, distinct from “something you know” (like a password) and “something you have” (like a phone or security key). Because a biometric trait is hard to guess, forget, or hand off to someone else, it tends to reduce the friction that passwords create while also improving security.
Most systems store a mathematical template of the biometric trait rather than the raw image. They also pair the biometric check with another factor, such as a device-bound key, for stronger assurance. This is how passkeys and other passwordless methods work today: a fingerprint or face scan unlocks a cryptographic key on the device, rather than being sent anywhere as a password substitute.
## Types of biometric authentication compared
The table below lines up the most common biometric authentication techniques side by side, so you can compare accuracy and friction at a glance.
| **Method** | **How it works** | **Accuracy** | **Common use** | **User friction** |
| --- | --- | --- | --- | --- |
| Facial recognition | Maps facial features and checks them against stored data | Very high on leading systems, but can vary by demographic and lighting | Unlocking phones, quick app logins | Low |
| Fingerprint scanning | Maps the ridges of a finger and compares them to a stored template | Very high on modern sensors | Unlocking devices, banking apps, payments | Low |
| Iris/retina recognition | Uses infrared light to scan and map the eye | Extremely high, very low false match rate | Government and military facilities | Medium |
| Voice recognition | Builds a profile of vocal characteristics | Moderate, sensitive to noise and impersonation | Digital assistants, call center verification | Low |
| Hand geometry | Maps the shape and proportions of the hand | High, but drops on mobile scans | Physical access at large venues | Medium |
| Gait recognition | Analyzes stride, step, and posture from video | Approaching high accuracy in controlled settings | Law enforcement, missing persons cases | None (passive) |
| Vein recognition | Uses infrared light to map veins beneath the skin | Extremely high | High-security exam centers and facilities | Medium |
Now, let’s take a closer look at each of these methods.
## Physiological biometric authentication methods
Modern authentication methods will test at least one of [three possible variables](<https://www.pearsonitcertification.com/articles/article.aspx?p=1718488>) when verifying a user’s identity:
- Something the user *knows*
- Something the user *has*
- Something the user *is*
Consider the following examples of biometric authentication methods to determine which suits your purposes:
- Facial recognition
- Fingerprint scanning
- Iris/retina recognition
- Voice recognition
- Hand geometry
### Facial recognition
[Facial recognition](<https://www.descope.com/learn/post/facial-recognition>) verifies identity by mapping a user’s facial features and checking them against a stored template. Then, when the user makes an authentication request, their face is checked against the biometric data saved in the repository to verify their identity.
Employing facial recognition technology to authenticate users offers a quick, effortless user experience (UX), which is why some of the most popular devices prefer it. It’s also highly secure: [Apple’s Face ID](<https://support.apple.com/en-us/HT208108>) has complex mapping procedures and depth-perceiving technology that make the chance of misreads less than one in one million.
That said, facial recognition may not work equally well for everyone. A [2020 Harvard analysis](<https://sitn.hms.harvard.edu/flash/2020/racial-discrimination-in-face-recognition-technology/>) found that age, race, and gender could affect the accuracy of popular facial recognition software, and [more recent research](<https://www.biometricupdate.com/202508/fairness-in-facial-recognition-hinges-on-mix-of-factors-including-cultural-norms>) suggests the gap has narrowed on the most accurate systems, though it points to a more complex picture: factors like image quality, lighting, and even facial hair or hairstyle can influence results as much as demographics alone.
Thus, facial recognition is best used where it’s seen most often: to unlock phones and complete other less critical authentication tasks. If you’re using it for more complex functions, consider backing it up with a secondary authentication method to avoid misreads.
### Fingerprint scanning
[Fingerprint scans](<https://www.descope.com/learn/post/fingerprint-authentication>) work by mapping the [unique ridges of the user’s digit](<https://www.sciencedirect.com/topics/computer-science/fingerprint-recognition>) then checking it against stored data. The technology has only gotten more accurate over time: in a [2026 NIST benchmark evaluation](<https://www.nist.gov/programs-projects/fingerprint-recognition>), the leading fingerprint identification system achieved a 0.02% error rate on two-finger matching against a database of 1.6 million people, and most modern devices now ship with fingerprint-compatible sensors.
Some individuals’ fingerprints, however, may not be as clearly defined as others. In such cases, users may have to scan multiple times or use another authentication method.
Nonetheless, fingerprint scanners have numerous applications. You can trust them for simple functions like unlocking devices and critical tasks like verifying identities for money transfers. Hence, you can find fingerprint-scanning technology everywhere, from banking apps to [theme parks](<https://www.gearbrain.com/ticket-fingerprint-disney-sea-world-universal-studios-1856485597.html>).
### Iris and retina recognition
Iris recognition scans [use infrared light to illuminate the user’s eye](<https://www.ncsc.gov.uk/collection/biometrics/iris>). A complex recognition algorithm takes a detailed scan of the iris, saves it in its database, and checks it against future authentication attempts.
Retina recognition, on the other hand, uses near-infrared irradiation to illuminate the blood vessels at the back of the eye and map out their unique pattern.
Both methods have extremely low false match rates, as ocular qualities are hard to duplicate. Thus, they’re cornerstones of authentication in high-security facilities, such as government and military compounds.
While ocular scanners are impressive and secure, their costs make them prohibitive for consumer purposes. So, while iris and retina scans may have a home in government entities and organizations, they’re still beyond the price point of the average app developer to be practical.
### Voice recognition
Voice recognition verifies identity by building a profile of a user’s unique vocal characteristics and matching it against stored data. If you’ve ever used a digital assistant to send a text or play a song, you’re familiar with the power of voice recognition technology. [Speaker identification software](<https://cloud.google.com/speaker-id>) creates these profiles for smooth and speedy verification.
Of course, voice recognition has its downsides, as anyone who has tried to use their digital assistant in a noisy environment (or with a sore throat) will tell you. These limitations haven’t stopped the technology from becoming mainstream. Since the [roughly 4 billion voice assistants in use in 2022](<https://www.statista.com/statistics/973815/worldwide-digital-voice-assistant-in-use/>), that number has continued to climb as smart speakers and in-app assistants have spread.
From Alexa to Siri, voice recognition is best used for completing minor tasks on personal devices, as research has found that even sophisticated vocal recognition technologies [can be fooled by agentic AI and impersonators](<https://www.researchgate.net/publication/354310641_Benchmarking_and_challenges_in_security_and_privacy_for_voice_biometrics>). So, if sensitive information is involved, vocal cords are not necessarily the safest authentication tool on their own.
### Hand geometry
Hand geometry verifies identity by mapping the unique size and shape of a user’s hand and comparing it to a stored profile. Like other biometric identification methods, hand scans function by checking these characteristics against stored profiles.
Accurate hand geometry scans require specialized equipment, and [scans taken on mobile devices](<https://iopscience.iop.org/article/10.1088/1742-6596/1804/1/012144/pdf>) yield less accurate results than other biometric authentication methods. Thus, [from the Olympics to Disney World Resorts](<https://www.fbi.gov/file-repository/about-us-cjis-fingerprints_biometrics-biometric-center-of-excellences-hand-geometry.pdf/view>), the technology is primarily used by massive entities with significant security concerns.
In fact, with starting prices ranging in the thousands of dollars, palm scanners have limited consumer application. Other authentication methods are likely a better fit for the job unless you protect a sizable physical location or valuable goods.
## Up-and-coming biometric authentication methods
While DNA-based identity verification may seem like science fiction, it already exists and [is becoming more affordable and accurate](<https://news.columbia.edu/news/new-software-can-verify-someones-identity-their-dna-minutes>). Soon, a drop of blood may be one of the quickest and most effective ways to authenticate a user.
For now, however, other similarly futuristic authentication methods, such as gait and vein recognition, are worth knowing about.
### Gait recognition
Gait recognition identifies a person by the unique way they walk, rather than a physical feature. Identifying walking patterns has niche uses for law enforcement and related organizations. Generally, such software analyzes video footage to locate individuals based on the length of their [strides, steps, and footprints](<https://www.ncbi.nlm.nih.gov/books/NBK557684/>). While some [gait recognition software](<https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8528623/>) has results approaching 95% accuracy, it can easily be thrown off by individuals intentionally manipulating their walk.
For identification and authentication purposes, gait recognition helps search for missing persons or pursue criminals.
### Vein recognition
Vein recognition maps the unique pattern of veins beneath the skin, most often in the palm, using infrared light. Infrared palm scans penetrate the skin to map the unique web of veins beneath the palm’s surface. Vein scans can be highly accurate, [with some technologies boasting correct recognition ratings of over 99.9%](<https://ietresearch.onlinelibrary.wiley.com/doi/pdfdirect/10.1049/iet-bmt.2019.0034>).
Due to its high accuracy, palm vein scans are the preferred authentication method of the national certification exam administrator, [Pearson VUE](<https://home.pearsonvue.com/documents/deliver-your-exam/palm-vein.aspx>). Like other methods that require expensive hardware, however, vein recognition as a whole is more suited to organizational applications rather than consumer use.
## Benefits of biometric authentication
Biometric authentication offers a few clear, quotable advantages over passwords and other knowledge-based methods:
- **Stronger security:** A biometric trait can’t be guessed, phished, or reused across sites the way a password can, which closes off some of the most common attack paths.
- **Faster, simpler login:** There’s nothing to remember, type, or reset, so users get past the login screen with a glance, a touch, or a word.
- **Resistance to credential-based attacks:** Since there’s no shared secret to steal, biometrics sidestep credential stuffing and password-reuse attacks entirely.
- **A smoother experience overall:** Removing password friction can lift conversion at sign-up and cut down on password-reset support load.
These benefits come with honest tradeoffs too, covered in the section below. Not every method fits every use case, and biometrics work best as part of a broader authentication strategy.
## Factors to consider when choosing a biometric authentication method
When determining which biometric authentication method fits your needs, there are several considerations to keep in mind, including:
### Security
Using secure biometric technology is paramount if you’re safeguarding extremely sensitive data, such as users’ banking information or trade secrets. Fingerprint scans, for instance, have a lower chance of being falsified than other widely accessible methods, like signatures.
Look closely at how a vendor stores biometric templates: on-device storage, as passkeys use, generally beats a centralized database, since there’s no single repository for an attacker to target. Biometrics should be part of an MFA process that employs additional identification approaches rather than serving as the sole gatekeeper.
### Accuracy
If your service has a large volume of users, you’ll want to pick a method that can quickly and accurately differentiate between biometric markers without potentially confusing similar credentials.
False accept and false reject rates matter here. A method with a low false accept rate keeps impostors out, while a low false reject rate keeps legitimate users from getting locked out over a minor scan issue. Methods like iris and vein recognition tend to score well on both counts, while voice recognition trails behind.
### User experience
If a quick and effortless experience is paramount, easy-to-use and familiar technologies such as fingerprint and face scans present optimal choices.
Consider, too, how a method performs in the conditions your users are actually in. For example, a face scan is awkward in the dark and a voice check is unreliable in a noisy room. The best fit often depends on where and how people will use your app day to day.
### Cost
For commercial and consumer-oriented apps, any solution requiring hardware beyond a standard mobile device may make the method cost-prohibitive for many users.
Fingerprint and face recognition win out here largely because the hardware already ships in most phones and laptops. Iris, vein, and hand geometry scanning require dedicated readers and scanners that only make financial sense at organizational scale.
## A note on FIDO authentication
Open standards such as [FIDO2](<https://www.descope.com/learn/post/fido2>) and [WebAuthn](<https://www.descope.com/learn/post/webauthn>) have rapidly gained adoption in the past few years. [Passkeys](<https://www.descope.com/use-cases/passkeys>), a consumer-friendly version of these standards, have been adopted by Google, Microsoft, Apple, Shopify, and others as the default form of [passwordless authentication](<https://www.descope.com/learn/post/passwordless-authentication>).
FIDO authentication uses asymmetric cryptography and biometrics to make authentication both secure and frictionless. Moreover, the biometric data never leaves the user’s device, making it virtually impossible for cybercriminals to conduct account takeover.
Adding passkeys to a consumer application offers a great balance between security and user experience.
## How to add biometric login to your app
For web and mobile apps, biometric login is delivered through passkeys and the WebAuthn standard rather than custom fingerprint or face-scanning code. A user registers a credential at signup, typically confirmed with a fingerprint or face scan, and that same device-bound key is checked at every future login. The biometric itself never leaves the device or reaches your server.
Most teams don’t implement WebAuthn from scratch, since handling registration ceremonies, attestation, and cross-device fallbacks correctly is a meaningful engineering lift.
A platform like Descope adds biometric login to a React or [Next.js](<https://docs.descope.com/getting-started/nextjs>) app through its SDKs and drag-and-drop flows, so a fingerprint or face scan can replace a password without your team building the underlying protocol work.
**Also Read: **[**Developer’s Guide to Passkeys**](<https://www.descope.com/blog/post/developer-guide-passkeys>)
## Add biometric authentication to your app with Descope
With most mobile devices now natively supporting biometrics, applications that let users authenticate with a swipe of their finger can simplify onboarding, increase retention, and improve security. Descope helps developers add biometrics, passkeys, and other authentication methods through drag-and-drop workflows that abstract away the complexity of building WebAuthn by hand.
[Sign up for Descope](<https://www.descope.com/sign-up>) on our “Free Forever” tier and see how easy it is to build biometric authentication flows for your app.
## Frequently asked questions about biometric authentication methods
---
### [Best Customer MFA Solutions in 2026: Top 7 Compared](https://www.descope.com/blog/post/customer-mfa-solutions)
Compare the best customer MFA solutions for 2026. See how Descope, Auth0, Entra, Firebase, and more compare on security, developer experience, and price.
*Full content: [https://www.descope.com/blog/post/customer-mfa-solutions.md](https://www.descope.com/blog/post/customer-mfa-solutions.md)*
The best customer MFA solutions combine broad authentication method coverage (OTP, push, passkeys, biometrics) with adaptive, risk-based policies, so trusted users log in with minimal friction while risky sign-ins get extra verification. For customer-facing apps, that usually means a platform like Descope, Auth0, Microsoft Entra External ID, Firebase, Keycloak, Supabase, or Authentik, each with a different tradeoff between ease of setup, control, and cost.
[Customer Multi-Factor Authentication (MFA)](<https://www.descope.com/learn/post/mfa>) is the foundation of secure digital experiences. It’s essential for modern applications, as it protects accounts, safeguards sensitive data, and strengthens user trust across every interaction. By requiring users to confirm their identity with multiple factors such as a one-time passcode, biometric scan, or push notification, MFA helps prevent unauthorized access even when credentials like passwords are compromised.
A sound, adaptive approach prioritizes both UX and security. Effective customer MFA can significantly reduce account takeover risk, reduce fraud, and ensure compliance without adding unnecessary friction. Because customer MFA shapes onboarding, engagement, and retention, developers must evaluate available options carefully to find a solution that offers the right balance of security, compliance, and UX.
In this guide, we explore the leading customer MFA solutions available today, covering:
- What MFA is and what to look for in a solution
- A comparison of the 7 top options in terms of features, strength, and fit
- A practical guide to choosing the best customer MFA solution for your needs
## At a glance
- Customer MFA solutions add a second validation step to logins for external users, protecting customer accounts without hurting the sign-in experience.
- The seven customer MFA provider options compared here are Descope, Auth0, Microsoft Entra External ID, Firebase Authentication, Keycloak, Supabase, and Authentik.
- Descope leads for teams that want to add and change MFA through developer-friendly no-code and low-code workflows, with adaptive MFA, passkeys, and native AI agent authentication built in.
- Auth0 and Microsoft Entra External ID suit ecosystem-aligned teams, while Firebase, Supabase, Keycloak, and Authentik appeal to code-first and self-hosted use cases.
- Choosing the right customer MFA solution depends on your user scale, your build-versus-buy preference, developer experience, pricing model, and whether you also need to authenticate AI agents.
## Quick facts
| **What customer MFA is** | A second identity check for external users, on top of a password or other primary login |
| **Who needs it** | Any customer-facing app protecting accounts, payments, or sensitive data |
| **How it differs from workforce MFA** | Built for scale and low friction across consumers and partners, not policy control over employee devices |
| **Common MFA methods** | OTP, push notifications, passkeys, magic links, and biometrics |
| **Key outcome** | Fewer account takeovers and less fraud, without adding login friction |
## What is MFA?
Multi-factor authentication (MFA) is the process of validating a user’s identity using two or more independent factors. These typically include something the user knows, something they have, or something they are. By combining these elements, MFA significantly lowers the risk of compromised credentials being used for unauthorized access.
Modern MFA goes beyond static codes or passwords. Developers can now implement adaptive MFA that evaluates contextual signals such as device trust, IP reputation, and user behavior to determine when additional verification is needed. This balance between security and usability allows trusted users to log in smoothly while increasing protection when risk is detected.
## Customer MFA vs workforce MFA
Customer MFA protects external users such as customers and partners at scale and prioritizes a low-friction experience, while workforce MFA protects employees and prioritizes policy enforcement and device control.
MFA deployments can also be tailored to specific use cases beyond that core split. Customer MFA is designed to meet the needs of clientele and external parties, while workforce MFA is meant primarily for employees and internal parties. Each has features that cater to the specific needs of its users.
Core components of customer MFA often include:
- **Authentication methods:** OTPs, push notifications, passkeys, or magic links.
- **Adaptive policies:** Context-aware authentication that adjusts security based on device, location, or session risk.
- **Workflow orchestration:** Tools to design MFA steps visually or programmatically across multiple applications or tenants.
- **Lifecycle management:** Covering user enrollment, recovery, and factor management.
- **Integrations:** Support for risk engines, analytics, and compliance systems.
Unlike internal workforce MFA, customer MFA must scale across a wide range of audiences including consumers, partners, and business customers. Each group may require different identity providers, branding, and user journeys.
The right customer MFA solution helps developers deliver secure, low-friction login experiences that grow with their applications. Below, we compare seven leading MFA platforms designed to protect external users while keeping authentication simple and adaptable.
## What to consider when looking for a customer MFA solution
Choosing the right customer MFA platform depends on your application’s users, risk profile, and growth goals. While most solutions offer basic two-factor authentication, customer-facing environments require more flexibility, scalability, and adaptability to user context.
A lot of multi factor authentication software is built primarily for securing employees, so it’s worth checking that a platform is actually designed for customer-facing scale before you commit to it.
Key factors to evaluate include:
- **Multiple authentication methods:** Support for OTPs, push notifications, passkeys, and magic links to provide users with secure and convenient options.
- **Adaptive and risk-based security:** Ability to adjust MFA prompts dynamically based on device trust, IP reputation, and behavioral signals.
- **Tenant management:** Tools to define per-tenant MFA policies and configurations for B2B or multi-tenant apps.
- **User experience:** Prebuilt UI components and customizable workflows that integrate into your app’s design.
- **Developer experience:** How quickly a team can add MFA, the quality of the SDKs and documentation, and whether flows can be changed without redeploying.
- **Integration ecosystem:** Native connectors for fraud detection, risk scoring, analytics, and identity providers.
- **AI agent and non-human identity support:** Whether the platform can authenticate AI agents and service accounts in addition to human users. This is one of the fastest-growing MFA requirements in 2026.
- **Scalability and compliance:** Reliable performance, audit trails, and compliance readiness for growing user bases and regulated industries.
A strong customer MFA solution balances protection with usability, enabling teams to deliver secure, frictionless login experiences across all audiences, from end users to business partners.
With these considerations in mind, let’s explore the top customer MFA solutions available today.
**Also read:** [5 Core Benefits of MFA (When Done Correctly)](<https://www.descope.com/blog/post/mfa-benefits>)
## Comparing the top customer MFA solutions
The top options for customer MFA range from full-featured CIAM platforms to tailored MFA solutions. Each offers a wide variety of MFA options, like OTP, magic links, or proprietary apps. Some offer greater control over security, UX, and other features, usually at the cost of higher complexity.
Here’s how the best MFA solutions for customer-facing apps stack up at a glance:
| **Provider** | **Key features** | **Developer experience** | **Free tier / pricing model** | **Best for** |
| --- | --- | --- | --- | --- |
| **Descope** | Adaptive MFA, passkeys, visual workflows, step-up security, multi-tenant management, agentic AI and MCP support | Visual workflow editor, 15+ SDKs, no-code and low-code flows | Free Forever tier includes MFA and adaptive MFA up to 7,500 MAUs; usage-based pricing above that | Dev and product teams building consumer-facing or SaaS apps that need strong ID management without unnecessary complexity |
| **Auth0** | OTP, push, WebAuthn, adaptive MFA, branded login pages | Extensive SDKs and docs, but MFA config lives outside the no-code path | Free tier excludes MFA; MFA starts on the $35/month Essentials plan | Orgs that need broad standards coverage and can handle added complexity and cost |
| **Microsoft Entra External ID** | FIDO2, Microsoft Authenticator, OTP, Conditional Access, lifecycle management | Strong for teams already in the Microsoft stack, less so outside it | Core tier free up to 50,000 MAUs; premium MFA features are paid add-ons | Regulated entities that need adaptive MFA and access controls plus easy Microsoft integration |
| **Firebase Authentication** | TOTP, SMS OTP, passwordless, Google auth options, prebuilt UI libraries | Fast setup for mobile apps; MFA and multi-tenancy require upgrading to Identity Platform | Free Spark plan is limited; MFA and multi-tenancy are billed on the pay-as-you-go Blaze plan | Dev teams building mobile-first apps or that are okay with writing custom code |
| **Keycloak** | TOTP, WebAuthn, or external MFA, OIDC, SAML, LDAP, configurable flows, multi-tenancy | Full control via the Admin Console, but manual setup and no official managed hosting | Free and open-source to self-host; no per-user fees, but you cover the infrastructure | Enterprises that want full control over MFA and have the DevOps resources to run it |
| **Supabase** | OTP, TOTP, magic links, passwordless options, integrated Postgres database | Simple setup for teams already using Supabase for their backend | Free tier covers up to 50,000 MAUs, but MFA is a paid add-on starting around $75/month | Dev teams that need an open-source backend and auth combined, and can add MFA as a paid extra |
| **Authentik** | TOTP, WebAuthn, push-based MFA, OIDC, SAML, LDAP, flexible policy engine | Self-hosted with an admin UI; open-source docs are solid but support is community-driven on the free tier | Free and open-source for self-hosting; paid enterprise tiers add support and SLAs | Dev teams seeking open-source and/or self-hosted MFA with strong interoperability |
Now, let’s take a closer look at each of these top contenders.
## Descope
### Overview
Descope is a customer MFA provider and a full-feature, [no/low-code CIAM platform](<https://www.descope.com/product>) built to make MFA and passwordless login simple, secure, and adaptable for any external-facing application. Designed for developers and product teams, Descope enables the creation of frictionless authentication flows that combine multiple authentication methods such as passkeys, one-time passcodes, magic links, and biometrics.
Its visual workflow editor and extensive SDK library allow teams to design, test, and deploy adaptive MFA and passwordless experiences without writing backend code or managing infrastructure. As co-founder Slavik Markovich has [put it](<https://www.descope.com/press-release/seed-funding>), the goal behind Descope’s no-code approach is to “de-scope” authentication from every app developer’s daily work, so teams can focus on their core product instead of building, maintaining, and updating login flows themselves.
Beyond MFA, Descope supports multi-tenant SSO, fine-grained access control, and orchestration across B2C and B2B environments. eams can connect risk engines, fraud detection tools, and external identity providers within the same flow to protect user accounts while keeping login experiences fast and consistent across customers, partners, and AI agents.
### Key capabilities
- **Broad MFA coverage** – Support for multiple authentication methods including [passkeys](<https://www.descope.com/use-cases/passkeys>), [OTP](<https://www.descope.com/use-cases/otp>), [magic links](<https://www.descope.com/use-cases/magic-links>), [social login](<https://www.descope.com/use-cases/oauth-social-logins>), [security questions](<https://docs.descope.com/auth-methods/security-questions>), and biometrics.
- **Adaptive MFA and risk-based policies** – Protect accounts with [context-aware MFA](<https://www.descope.com/learn/post/adaptive-authentication>), [session management](<https://docs.descope.com/authorization/session-management>), and [bot detection](<https://docs.descope.com/fingerprinting>) that respond dynamically to risk.
- [**Visual workflow editor**](<https://www.descope.com/flows>) – Drag and drop MFA and passwordless steps to design adaptive authentication flows without writing backend code.
- [**Step-up authentication**](<https://docs.descope.com/mfa-and-step-up/step-up>) – Add extra authentication checks before sensitive in-app user actions, like changing a shipping address or wiring money.
- [**Prebuilt UI widgets**](<https://docs.descope.com/widgets>) – Embed MFA enrollment, verification, and recovery components directly into your app.
- [**Journey-time orchestration**](<https://www.descope.com/use-cases/identity-orchestration>) – Connect MFA with fraud detection, authorization, compliance, and analytics tools.
- **Multi-tenant management** – Configure MFA methods and access policies per tenant using built-in [RBAC](<https://docs.descope.com/authorization/role-based-access-control>) and [FGA](<https://docs.descope.com/authorization/rebac>).
- [**SDKs and APIs for modern frameworks**](<https://docs.descope.com/api>) – Support for over 15 SDKs, including Next.js, Flutter, and React Native.
- **Connector ecosystem** – [Integrate](<https://www.descope.com/integrations>) with third-party risk, fraud, and directory services for extended authentication intelligence.
- **Agentic identity support** – Secure and manage consented [authentication for AI agents and MCP ecosystems](<https://www.descope.ai/>) alongside human users.
### Strengths
- **Adaptive protection:** Context-aware MFA uses device, location, and behavioral signals to trigger additional verification only when necessary, balancing security and usability.
- **Dynamic factor selection:** Flows can be customized to recommend the best MFA method for each situation, automatically switching to secure fallbacks when a factor isn’t available or practical.
- **Fast implementation:** Visual workflows let teams design, test, and deploy authentication flows without backend complexity or infrastructure setup.
- **Augmentation-friendly architecture:** Using Descope as an [OIDC Provider](<https://docs.descope.com/identity-federation/applications/oidc-apps>), organizations can implement MFA without changing their existing auth systems.
- **Developer-first platform:** SDKs, APIs, and prebuilt UI components make integration straightforward across modern frameworks.
- **Transparent pricing and reliable support:** Usage-based pricing and responsive developer assistance help teams deploy confidently.
### Limitations
As a newer platform than legacy providers like Auth0 or Microsoft’s identity stack, Descope has a smaller library of large-enterprise case studies, though its production customer base is growing quickly and consists of 1000+ organizations in production. Teams that specifically need decades-long vendor track records for procurement purposes may want to weigh that against the tradeoffs of a more modern, no-code architecture.
### Ideal for
Descope is ideal for developers and product teams building consumer or SaaS applications that need passwordless authentication, multi-tenant SSO, and adaptive MFA without the complexity of managing identity infrastructure. It’s equally suited for startups launching fast and enterprises modernizing legacy systems.
## Auth0
### Overview
Auth0, part of Okta, is a well-known platform for customer MFA at scale. It supports OTP, push, and WebAuthn factors along with SSO, social login, and adaptive access controls. Developers can add MFA through Auth0’s APIs, Rules, and Actions, but the platform has notable limitations.
Auth0 cannot support MFA-only or MFA-augmentation use cases because its MFA API requires a primary Auth0-issued auth token, and some methods, such as magic links, can only be used as primary factors, not step-up MFA. As deployments grow, teams may also encounter added configuration complexity and higher-tier pricing: MFA itself isn’t available on Auth0’s free tier and requires the paid Essentials plan or above.
### Key capabilities
- Support for MFA methods such as OTP, push, and WebAuthn authentication
- Adaptive MFA that applies additional checks based on user risk and behavior
- Hosted login pages with customizable branding and localization
- Integration with enterprise standards such as SAML, OIDC, and social identity providers
### Strengths
- **Enterprise-grade MFA:** Proven support for adaptive MFA and secure federation across large environments.
- **Developer ecosystem:** Extensive SDKs, documentation, and integration marketplace for rapid setup and customization.
- **Mature platform:** Trusted by enterprises with a large community and partner ecosystem.
### Limitations
Auth0 pricing can escalate at scale, since MFA and other advanced features are gated behind paid tiers rather than included in the free plan. Add-ons stack up particularly quickly for larger deployments. MFA customization also tends to require more configuration and code than a no-code workflow.
### Ideal for
Organizations that want a proven, enterprise-ready MFA solution with broad standards support and strong developer tooling. Auth0 is best for teams that can handle additional configuration complexity and cost in exchange for scalability, reliability, and enterprise features.
## Microsoft Entra External ID
### Overview
Microsoft Entra External ID extends Microsoft’s identity platform to support secure, adaptive MFA for customers, partners, and external users. Built on the same foundation as Entra ID, it offers strong MFA options including FIDO2 security keys, Microsoft Authenticator push notifications, and one-time passcodes.
Entra External ID enables organizations to enforce granular access controls, apply Conditional Access policies, and maintain compliance across hybrid and cloud applications. Its enterprise-grade capabilities make it a trusted choice for regulated industries and large organizations already using Microsoft 365 or Azure.
### Key capabilities
- MFA support using FIDO2 security keys, Microsoft Authenticator, and OTP verification
- Conditional Access policies that evaluate user, device, and session risk in real time
- Lifecycle management for external users with automated provisioning and access reviews
- Integration with enterprise apps and SaaS platforms through SAML, OIDC, and SCIM
### Strengths
- **MFA and compliance:** Enterprise-grade MFA with built-in governance and reporting tools to meet security and regulatory standards.
- **Deep Microsoft integration:** Native interoperability with Microsoft 365, Azure, and thousands of connected applications.
- **Scalable architecture:** Supports large external user bases while maintaining consistent security and policy enforcement.
### Limitations
Entra External ID is tightly coupled to the Microsoft ecosystem, which makes it less flexible for multi-cloud teams that don’t already run on Azure. The External ID feature set for customer-facing scenarios is also still maturing relative to Microsoft’s workforce-focused Entra ID product.
### Ideal for
Enterprises and regulated organizations that need adaptive MFA and strong access controls tightly integrated with Microsoft services. Ideal for teams seeking centralized management, compliance visibility, and integration with their existing Microsoft identity ecosystem.
## Firebase Authentication
### Overview
Firebase Authentication is Google’s developer-focused identity service that simplifies adding MFA to web and mobile applications. It supports SMS-based verification, email OTPs, and integration with TOTP authenticators, allowing developers to add strong authentication with minimal setup.
Built directly into the Firebase platform, it integrates with services like Firestore, Cloud Functions, and Firebase Hosting, making it an appealing option for mobile-first apps and startups. While Firebase MFA is straightforward to implement, customization and scalability can become challenging as user bases and security requirements grow.
### Key capabilities
- MFA using SMS one-time passcodes and TOTP apps such as Google Authenticator
- Support for passwordless options like email link sign-in and Google One Tap
- Integration with major social providers including Google, Apple, and Facebook
- Prebuilt UI libraries for web, iOS, and Android to speed up implementation
### Strengths
- **Simple MFA implementation:** Quick setup for SMS or app-based verification with minimal backend configuration.
- **Mobile-first experience:** Optimized SDKs and UI libraries for Android, iOS, and cross-platform frameworks.
- **Google ecosystem integration:** Works natively with Firebase and Google Cloud services for cohesive app development.
### Limitations
MFA and multi-tenant management require upgrading to Firebase’s Identity Platform tier, which moves billing to a pay-as-you-go model. SMS-based MFA is billed per verification on top of that. Enterprise federation and multi-tenant support are also narrower than what dedicated customer identity platforms offer.
### Ideal for
Developers building mobile or consumer-facing apps who want fast, reliable MFA implementation with minimal operational overhead. Firebase Authentication is best for small teams and startups already invested in the Google ecosystem looking to add secure, frictionless MFA to their applications.
> **Looking for customer MFA you can add without building it yourself, and that also authenticates AI agents?** Descope’s Free Forever tier gives you visual MFA workflows, adaptive MFA, passkeys, and agentic identity support up to 7,500 monthly active users. [Sign up free](<https://www.descope.com/sign-up>).
## Keycloak
### Overview
Keycloak is an open-source identity and access management platform that provides full control over authentication, authorization, and MFA. It supports time-based one-time passcodes (TOTP), FIDO2/WebAuthn for hardware or biometric authentication, and integration with third-party MFA providers.
Because it’s self-hosted, Keycloak offers maximum flexibility for developers who want to customize authentication flows and policies to meet specific enterprise or compliance requirements. However, its manual configuration, upgrade complexity, and operational overhead can present limitations as projects scale.
### Key capabilities
- MFA using TOTP, WebAuthn, or external MFA integrations
- Support for major protocols including OIDC, SAML, and LDAP
- Configurable authentication flows and policies through the Admin Console
- Realm-based structure for managing multiple tenants or applications
### Strengths
- **Flexible MFA support:** Built-in and extensible options for TOTP, WebAuthn, and external MFA providers.
- **Open-source customization:** Full access to configuration and source code for complete control overAI models mentioned in this file
- Claude (Anthropic) — “- [How to Secure an AI Agent With Claude Agent SDK + Descope](https://www.descope.com/blog/post/secure-ai-agent-claude-descope): Build a secure AI agent with the Claude Agent SDK and Descope: vault cr…” (llms.txt)
- ChatGPT (OpenAI) — “- [The Descope MCP Server Is Available On Claude and ChatGPT](https://www.descope.com/blog/post/descope-mcp-server-claude-chatgpt): The Descope MCP Server is now available as a Claude Connector and a …” (llms.txt)