# 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 ### [Social Login: Definition, Pros & Cons, Examples](https://www.descope.com/learn/post/social-login) *Full content: [https://www.descope.com/learn/post/social-login.md](https://www.descope.com/learn/post/social-login.md)* Your app is ready to launch—features polished, almost go-time. But what about [authentication]()? Should you add social login? Will users actually use it, or just get confused? It’s a fair question. With 168 passwords to juggle [(per NordPass]()), many users jump at quicker options, but not without hesitation around privacy or account creation. The good news? When done right, social login brings big wins for both user experience (UX) and security. Let’s break down the benefits, risks, and how to roll it out right. ## At a glance - Social login lets users sign in to an app using an existing account from a provider such as Google, Apple, Facebook, or GitHub, instead of creating a new password. - It works through the OAuth 2.0 and OpenID Connect standards, where the provider confirms the user’s identity and returns a token to the app. - The main benefits are less password fatigue, faster signup and higher conversion, fewer stored passwords to breach, and lower maintenance. - The main tradeoffs are dependence on the provider, privacy considerations around shared data, and the need to implement it securely to avoid flaws such as nOAuth. - Developers can add social login to a Next.js, React, or Node.js app through an identity provider’s SDK rather than integrating each provider by hand. ## Quick facts | **What social login is** | Signing in with an existing account from a provider like Google or Apple instead of creating a new password | | **How it works** | Through the OAuth 2.0 and OpenID Connect standards, with the provider returning a token to the app | | **Common providers** | Google, Apple, Facebook, Microsoft, GitHub, LinkedIn, Discord | | **Key benefit** | Faster signup and login, with no new password for the user to create or the app to store | | **Main risk** | Provider dependence and implementation flaws, such as trusting unverified email claims | ## What is social login? Social login—also called social sign-on, social sign in, social authentication, or social SSO—is an authentication method that lets users log in to your app using their existing social accounts on platforms like Google, Apple, Facebook, or LinkedIn. Instead of creating yet another password, they click something like “Sign in with Facebook” or “Continue with Google,” approve a permissions request, and they’re in. It’s fast, familiar, and easy. Under the hood, a social login app doesn’t store or even see the user’s password on the social platform. Instead, it receives a signed token confirming who the user is, which is what makes social login fundamentally different from a traditional username-and-password form: the credential never leaves the provider that issued it. ![OAuth example screenshot]() When implemented well, social login makes everyone’s life easier: - **Reduced password fatigue** – No need to remember (or reset) yet another password. - **Fewer fake accounts** – Real accounts are tied to existing identities. - **Lower maintenance costs** – Developers don’t have to manage password infrastructure. - **Better conversion rates** – Especially helpful for mobile and ecommerce apps where every second counts. ## Social login vs. SSO Social login uses a consumer identity provider such as Google or Apple to authenticate individual external users, while SSO lets employees inside one organization reach multiple approved apps with a single set of credentials. Social login often gets lumped in with [Single Sign-On (SSO)](), and while they share some DNA, they serve different use cases. | **** | **Social login** | **SSO** | | --- | --- | --- | | Who it’s for | External, consumer-facing users | Employees within one organization | | How identity is verified | A consumer provider like Google, Apple, or Facebook | A corporate identity provider like Okta or Microsoft Entra | | Typical use | Consumer apps, ecommerce, mobile signup | Enterprise apps, internal tools, business suites | [SSO is typically used in enterprise]() environments. A single login, like a corporate Google or Microsoft account, grants access to a set of approved business apps. It’s efficient and controlled, but usually locked to a managed suite. Social login, on the other hand, is more flexible and user-driven. It works great for consumer apps where people want the freedom to log in with the platform they already use every day: Google, Apple, Facebook, LinkedIn, and others. Of course, that flexibility comes with tradeoffs, especially when it comes to security and UX control. But done right, it can unlock serious adoption gains. ## How does social login work? Social login works by redirecting the user to a trusted provider to authenticate, then having that provider hand back a token the app uses to sign the user in, all without the app ever seeing the user’s provider password. Behind the scenes, social login runs on [Open Authorization (OAuth 2.0)]() and [OpenID Connect (OIDC)](), open standards that allow your app to securely authenticate users via trusted third-party platforms. Here’s how the flow typically works: - Your app presents “Sign in with [Social Platform]” options on the login screen. - The user picks a provider and is redirected to that platform to authenticate. - They accept a prompt asking for permission to share certain identity details. - The provider confirms their identity, and they’re logged into your app. As long as the user has an account with that social platform, they don’t need to sign up or manage new credentials, a big win for UX. ## Why use social login for your app ![Auth method breakdown image]() Many developers wonder whether social login can benefit their project. Some look at the [dwindling share of Meta social logins]() (from 65% of the top 100 sites down to 36%) and ask, “Is login with Facebook actually used?” And while your choice of provider definitely matters, our data shows that social login is a huge hit, representing **a third of all sign in events** across Descope customers, close on the heels of traditional passwords. ![Social login provider breakdown]() Looking at a breakdown of social login providers: - Google dominates with 90.8% of social authentications - followed by Apple at 8.8%. Bear in mind that this reflects both user and business preferences: Users can’t choose what isn’t offered, and businesses typically provide the most popular options. The data shows how embedded these providers are in daily life. Users often arrive already logged into Google (on Chrome or Android) or Apple (on iOS), making social login a natural entry point. This effect is amplified on mobile. Our data shows mobile representing 37.8% of logins, with desktop at 29.2%. This tracks closely with data from eMarketer, which indicates [44.6% of all U.S. retail]() originates from mobile devices. For mobile-first applications, social login is practically essential because users already struggle with traditional password entry on small screens.  As Wharton marketing professor [Ron Berman puts it](), “Because screens are small, the larger the hassle it is to purchase, the lower the purchase propensity on mobile phones.” Every barrier, no matter how small, hurts mobile conversions. But when users are already authenticated with their device's ecosystem, social login removes this friction entirely. ### The case for simplicity: Google One Tap While we previously touched on Google’s dominance in the social login space, there’s a new, streamlined development making this provider an even more attractive option.  [Google One Tap]() takes social authentication a step further by automatically detecting when a user is already signed in to their Google account. Instead of redirecting to a new page or popup, it presents a native prompt right where the user is, enabling a true one-click (or tap) login experience. ![Peek-a-box One Tap Example]() **Learn more: **[Google One Tap for Your App With Descope]()  ### What about niche providers? If you’re building a product for a specific crowd, it can pay to go beyond the big players. - A dev tool with **GitHub login**? Feels right. - A business app with **LinkedIn login**? Instant credibility. - A gaming platform with no **Discord option**? Missed opportunity. It’s clear that Apple and Google are the prevailing forces in social login. But when you want to appeal to a specific audience, like business professionals or developers, offering GitHub or LinkedIn social login options can go a long way toward cementing your brand with these demographics. Even if your users don’t click, they’ll associate you with these providers. Choosing a smaller social login provider isn’t for everyone. If you’re not sure what platforms or devices your users already engage with, stick to the big players. That said, adding Apple, Google, and trialing one other provider at a time can potentially boost your brand and login success rates. Consider this: a gaming platform without Discord or Twitch login might feel tone-deaf. A workflow tool relying solely on traditional passwords could signal that it’s out of touch with modern methods. No matter what you choose, your auth strategy is part of your product’s identity...and social login is no exception. ## Is social login secure? Social login is secure when it’s built on OAuth 2.0 and OpenID Connect and implemented correctly, though the apparent simplicity of the flow can mask real complexity that creates vulnerabilities if account merging and token validation aren’t handled carefully. That said, offloading authentication to an external provider like Google or Apple means leveraging one of the world’s most sophisticated security ecosystems. Their auth infrastructure handles everything from device [biometrics]() to [bot detection]() at a scale few could match. ### Remember nOAuth? Case in point: Descope’s security team discovered a critical OAuth implementation flaw affecting Microsoft Azure AD applications in 2023. Dubbed [nOAuth](), this vulnerability stemmed from applications trusting unverified email claims when merging user identities. This practice could have led to complete [account takeover (ATO)](), affecting multiple major applications and authentication providers. Working with a dedicated authentication provider helps address these challenges through proactive monitoring, quick vulnerability patching, and intrinsic protection against both common and unique attack vectors. For example, the nOAuth vulnerability never affected Descope customers (despite Descope discovering the exploit) because the platform was already enforcing [additional email verification steps]() during account merging. This was due to using the immutable sub claim as the primary identifier rather than relying on mutable email claims. When properly implemented, social login can enhance security while improving the user experience. The key is striking the right balance. Social login should deliver a smooth journey for legitimate users while maintaining strong defenses against potential attacks and misconfigurations. [Adaptive authentication](), for instance, can add additional security when contextual signals indicate a high-risk login attempt. This pairs neatly with social login, allowing users to sign up and sign in smoothly unless certain risk thresholds are met. ### Other social login pitfalls Other potential drawbacks to social login include: - **Data privacy concerns** – Users have concerns about the ways social media platforms collect and use their data, so they may be hesitant to give another app access to it. - **Single point of failure** – Although unlikely, using social login might lead to account compromise through a “single point of failure.” Compromised credentials for a user’s social media account can give attackers access to your platform and any other accounts associated with it. Pairing social login with adaptive, risk-based checks helps limit the blast radius if a user’s provider account is ever compromised elsewhere. - **Complex implementation** – The standards governing social login are open and interoperable, but can also be time-consuming for developers to build in-house. [Even seasoned developers]() find it tricky to implement OAuth and OIDC into their apps, since every provider has slightly different scopes, token formats, and edge cases to account for, and getting account merging wrong can introduce serious security gaps rather than just UX friction. But good social security hygiene in your UX and using a platform like Descope to take the heavy lifting (and risk) off your plate make social login worthwhile. ## How to add social login to your app Adding social login to an app generally follows the same pattern regardless of framework: 1. **Register your app with the provider** to get a client ID and secret. 2. **Configure the redirect URI** the provider will send users back to after they authenticate. 3. **Trigger the provider login** from your app’s sign-in screen. 4. **Exchange the returned code for a token**, then create or match the user’s account in your system. Most teams don’t hand-build each of these steps for every provider. An identity platform SDK handles the OAuth and OIDC flow, token exchange, and account matching for you, so you configure providers rather than integrate them one at a time.  This matters because each provider has its own quirks in how it issues codes, names its scopes, and formats its tokens, so a from-scratch integration that works with Google today can still need rework when you add Apple or GitHub next month. An SDK absorbs those differences behind a single, consistent interface. Here’s how that looks for three common frameworks. ### How to add social login to a Next.js app 1. Install the Descope Next.js SDK and wrap your app in an `AuthProvider` with your project ID. 2. Add the Descope sign-in component to your login screen and configure which social providers to display in your Descope project. 3. Use the SDK’s session hooks to check authentication state and access the logged-in user. See the [Descope Next.js quickstart]() for the full walkthrough. ### How to add social login to a React app 1. Install the Descope React SDK and wrap your app in an `AuthProvider` with your project ID. 2. Add the Descope sign-in component, which renders your configured social login buttons automatically. 3. Use the provided hooks to read session and user state, and pair with a backend SDK if you need server-side session validation. See the [Descope React quickstart]() for the full walkthrough. ### How to add social login to a Node.js app 1. Install the Descope Node.js backend SDK and initialize a client with your project ID. 2. Pair it with a frontend SDK (or Descope’s hosted flows) so users can trigger social login from the UI. 3. Validate the session token from the Authorization header on incoming requests using the backend SDK. See the [Descope Node.js quickstart]() for the full walkthrough. Descope supports several other web, mobile, and backend frameworks, with all of them powered by [Descope Flows](), a no-code identity journey editor that abstracts away the complexity of adding social login to your app. ## Social login in action: a real-world example Long story short? One B2C enterprise using Descope saw login behavior shift dramatically post-launch: - Social login adoption grew from 10% to 29% in just two months. - Traditional password use dropped from 42% to 26%. - That’s a 190% increase in social login usage. Two key variables played a role in the outcome:  - First, nearly three-quarters of all logins for this platform were from mobile devices; - Second, only the two largest social login providers were selected (Apple and Google). ![Impact of social login example]() In the two months after launching the new option, social login usage on their platform grew from 10% of all logins to 29%, while traditional password use declined from 42% to 26%. To put that in perspective, social logins increased by a jaw-dropping 190% in the two months since launch, while password use fell by roughly 61% in the same period. This example highlights a clear user preference for social authentication when available. It demonstrates how quickly users adopt more convenient login methods by merging existing password-based accounts with external providers for a smoother experience. ## What to look for when implementing social login If you’re evaluating how to build or buy social login for your app, here are the criteria that matter most. ### OAuth 2.0 and OpenID Connect support Your app needs to handle OAuth 2.0 and OpenID Connect flows for token exchange and user info, whether you build this yourself or rely on a platform that implements it for you. ### Account linking Plan for users signing in with multiple providers, avoid duplicates and merge accounts securely. Trusting an unverified email claim to decide whether two accounts belong to the same person is exactly the mistake that caused the nOAuth vulnerability: always verify identity with an immutable identifier, such as the provider’s subject claim, rather than a mutable one like email. ### Scope minimization Only request the data you actually need. Asking for too much spooks users and increases the amount of sensitive data your app has to handle. ### Callback and provider options Each platform plays by its own rules. Apple requires Apple login for iOS apps with social options; others have their own scope or token limits, and you’ll want SDKs and long-term maintenance from official sources so you’re not chasing provider API changes yourself. Always plan a fallback option too, since social login isn’t failproof; something like [passkeys]() works well as a backup. If this all sounds complicated, that’s because it often is. Considering the cost, risks, and ongoing investment of handling social login in-house, working with an experienced authentication provider can be especially valuable for new or growing products. This allows you to reap the benefits of social login while avoiding the pitfalls, lowering barriers for entry to legitimate users without sinking your engineering team’s time into monitoring, maintenance, and patching. Take it from Descope customer Seetharam Venkatesh, Co-Founder of [funda.club](): > “Authenticating our community members with LinkedIn is intuitive for them, gives us a better understanding of their identity, and removes the burden of managing passwords.” ## Add social login with Descope Descope lets teams add social login for any provider to a Next.js, React, or Node.js app through drag-and-drop workflows and SDKs, rather than integrating each provider by hand. You get pixel-perfect presentation for your social login options, equipped with proper claim validation and secure account merging, so your users get a frictionless sign-up and sign-in experience. [Sign up for a Free Forever account]() with Descope to see how easy adding social login to your site or app can be, or [book time with our auth experts]() to learn more about user merging and adaptive auth. ![Social logins]() ## Frequently asked questions about social login --- ### [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](), 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](). 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]() 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]()! - **Permanence (or immutability):** Unlike [passwords](), 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](). 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]() 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]() 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. ![Fig: A prompt for completing a fingerprint scan on a Windows PC]() ### Facial recognition [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. ![Fig: A prompt to complete facial recognition on an Apple mobile device]() ### 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]() (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]() 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](), [Google](), and [Samsung]() 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]() and [account takeover](). The [2026 Verizon DBIR]() 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]()), Fast Identity Online ([FIDO2]()), and [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]()). 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](), 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*]()*, 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]() (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]() ## 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]() 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](), 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**]() ## No / low code biometric auth with Descope Descope lets teams [add biometrics]() to their apps through visual workflows rather than building WebAuthn by hand. You can use biometrics for strong MFA, add [passkey authentication]() 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]() to start using Descope today, or [book time with our auth experts]() if you have questions first. ![Passkeys Dark]() ## Frequently asked questions about biometric authentication --- ### [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]() 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]() 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]() 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. ![NHI types]() 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]() 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]() 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]() 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)]() 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**]()** and the **[**Agent2Agent Protocol**]()**. ** ## 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]() (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]() endpoint), verifies the [token 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**]()**: **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)**]()**:** 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)**]()**:** 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)**]()**: **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)**]()**:** 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](), agentic identity, and non-human identity management, sign up for a [Free Forever account](), join our [AuthTown dev community](), or explore the [Agentic Identity Hub](). ## FAQs about non-human identity --- ### [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](), 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](), 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]() 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. ![Fig: How OAuth works]() 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)]() 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]()), and the **enterprise IdP** (which governs and mediates the connection). ![XAA how it works slide (1)]() 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]() 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]()). - **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]() 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](), 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]() 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]() ### 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]() 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]() in the [Agentic Identity Hub](): - 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]() 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]() walks through a full exchange end to end. You can also join [AuthTown](), our dev community, or [sign up]() for a Free Forever Descope account to try the flow in your own project. --- ### [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](): 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]() 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](), 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]() 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]() and [magic links]() options, send nothing to a phone number, so there's nothing for the attacker to catch. [Passwordless methods]() 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]() 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]() verifies a user with a physical characteristic such as a fingerprint or a face scan, checked on the device itself. [Device 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]() 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]() checks. A takeover attempt usually arrives from a new device in a new location within minutes of a password reset, and [adaptive MFA]() can require a stronger factor exactly there while staying out of the way otherwise. 6. Add [silent network authentication]() (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](), 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]() 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]() 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]() 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]() 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]() 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](), 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. ![Fig: Passkeys flow]() 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.]() Start with a [Free Forever account]() to build the flow yourself, or [book time with the team]() to talk through a migration off SMS. ## FAQs about SIM swapping --- ## Blog ### [Free SAML Decoder: How to Read and Debug SAML Responses](https://www.descope.com/blog/post/saml-decoder) Decode a SAML response in your browser for free, then debug it field by field: status, audience, timing, and signatures. *Full content: [https://www.descope.com/blog/post/saml-decoder.md](https://www.descope.com/blog/post/saml-decoder.md)* [SAML]() (Security Assertion Markup Language, pronounced "SAM-el") extends a login from an [identity provider (IdP)]() to an application as a `SAMLResponse`. This is a [Base64]()-encoded message that arrives as an unreadable block of characters. Requests and logout messages sent over the HTTP-Redirect binding are also [DEFLATE]()-compressed before encoding. A SAML decoder reverses the encoding, and any compression, to return the XML that was actually sent. Decoding that XML makes it readable again, and it’s the first step in diagnosing [single sign-on (SSO)]() failures. When an SSO login breaks, the application often shows a generic error but not the underlying cause. The root of the problem is in the XML response: its status, assertion, and the conditions attached to it. However, decoding simply makes the XML human-readable. It doesn’t diagnose whether they’re valid, which is why debugging takes several more steps. This guide uses [Descope’s SAML Guru](), a free browser-based SAML decoder, to read a response from end to end. We’ll work through the fields where SSO most often breaks, and briefly cover the most common fixes for each. The guide also assumes you’re already familiar with SAML, what it’s intended to do, and how it differs from other approaches like [OpenID Connect (OIDC)](). You can easily refresh your understanding by reading our dedicated guides: [How the SAML Protocol Works](), [OIDC vs. SAML](), and Descope’s docs on [setting up SSO with a SAML tenant](). ## At a glance - A SAML decoder turns an encoded `SAMLResponse` or `SAMLRequest` into readable XML, so you can see exactly what the IdP sent. - Login responses arrive over HTTP-POST and are Base64 only. Requests and logout messages sent over HTTP-Redirect are DEFLATE-compressed first, so a plain Base64 decode leaves them unreadable until they're inflated. - Decoding shows you the message; it does not validate the signature or the assertion. Readable is not the same as trusted. - Most SSO failures come down to a few fields: `Status`, `Audience`, the `Conditions` time window, `Recipient`, and `InResponseTo`. - SAML Guru runs entirely in your browser, so the message never leaves your machine. ## How to decode a SAML message Reading a response takes two steps: capture the encoded value, then decode it. The output from SAML Guru is the XML we’ll debug in later sections. **First, capture the value using your browser to log in with SSO.** The message is a single parameter. A login response arrives over the HTTP-POST binding as a hidden form field named `SAMLResponse`. An AuthnRequest, and often a logout message, travels over the HTTP-Redirect binding instead, in the URL query string as `SAMLRequest=` (or `SAMLResponse=` for a logout response). Most popular browsers (Chrome, Firefox, Safari) have a built-in developer mode that exposes documents like SAML messages. Open the developer console (or equivalent) in your browser, select the **Network** tab (or equivalent), and enable the option to preserve logs; this prevents the console from being wiped out when redirected or refreshed. Repeat the SSO login you’re troubleshooting, and you should see a SAML document appear in your developer UI. Copy the value of the payload only, not the parameter name or the surrounding markup. ![Fig: The Network tab of Google Chrome DevTools, viewing the payload of a selected SAML message.]() You may also choose to install a plugin or extension to capture and decode the SAML message all in one window. However, most browser addons do not allow you to paste and decode existing SAML messages, which will often be what you’re working with when troubleshooting an end-user login failure. ![Fig: The SAML-tracer extension for Google Chrome displaying a SAML response.]() **Now, decode the SAML response.** Paste the value of `SAMLResponse` into [SAML Guru](), which will resolve the encoding and print the XML. If your message is DEFLATE-compressed, SAML Guru will automatically inflate it before decoding. ![Fig: A DEFLATE-compressed, Base64-encoded SAML AuthnRequest decoded in SAML Guru.]() Once decoded, read the summary (**SAML Info**) first to orient yourself with the basics, then switch to the raw XML view to begin the diagnostic process. The rest of this guide assumes you’re working with a properly decoded SAML response, so make sure the raw XML tab shows actual values rather than unreadable characters. ## What does a SAML response contain? A `SAMLResponse` has two layers: the response envelope, which carries transport-level status and addressing, and the assertion inside it, which carries the user's identity and the conditions on trusting it. Both are defined in the [SAML 2.0 core specification](), and Descope's [SAML explainer]() covers the wider protocol. The table below describes each field, which you’ll compare against your own decoded output, with this serving as a legend: | **Field** | **What’s in it** | **Decoded example** | | --- | --- | --- | | Destination | The exact URL the IdP addressed the message to | https://api.descope.com/v1/auth/saml/acs?tenantId=T2exampleTenant00000000000 | | Issuer | The entityID identifying the IdP that issued the message | https://idp.example.com/saml/metadata | | Status | The overall result of the authentication attempt, expressed as a status-code URI | urn:oasis:names:tc:SAML:2.0:status:Success | | Signature | The IdP's cryptographic signature over the response, the assertion, or both | On the assertion: RSA-SHA256 with an embedded X509 certificate | | Subject | The user identity with which the SAML assertions are associated | See NameID, Recipient, InResponseTo, and Bearer NotOnOrAfter below | | NameID | The identifier for the authenticated user, and the Format that identifier is expressed in | jane.doe@example.com (emailAddress format) | | Recipient | The endpoint permitted to receive this assertion | Same URL as Destination | | InResponseTo | The ID of the specific request this response answers | _req00000000-0000-4000-8000-000000000000 | | Bearer NotOnOrAfter | The moment after which the assertion can no longer be presented | 2026-01-15T11:00:00.000Z | | Conditions | The window in which the assertion is valid, bounded by NotBefore and NotOnOrAfter | NotBefore 2026-01-15T09:55:00.000Z, NotOnOrAfter 2026-01-15T11:00:00.000Z | | Audience | The service provider the assertion is intended for | T2exampleTenant00000000000-P2exampleProject0000000000 | | AttributeStatement | The user attributes the SP maps to profile fields, roles, and groups | email, name, department, groups (Engineering, Admins, Everyone), roles (viewer, editor) | | AuthnStatement | Records how and when the user authenticated, and identifies the session for a single logout | 2026-01-15T09:58:00.000Z, urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport, _e5f6a7b8-0000-4000-8000-000000000002 | ## How to debug a SAML response Work down the decoded message roughly in the order it appears. Not every field is worth exploring as a failure point; either they’re extremely unlikely to be the cause, or they’re set in stone by the spec. ``, for example, records how and when the user authenticated, and it’s highly unlikely to break a login. Read the decoded message from the top. The response header, `Issuer`, and `Status` sit in the response envelope; everything from `Signature` down lives in the assertion. Each section below covers what the field and its contents are, what correct and broken look like, and the fix. Code blocks in this section include sample fields, as they might appear in a complete SAML response. These are illustrative, and yours may look significantly different depending on the field’s possible parameters. ### Response header The opening `` element carries the envelope attributes: `ID`, `Version`, `IssueInstant`, `Destination`, and `InResponseTo`. `ID`, `Version` (always `2.0`), and `IssueInstant` are effectively never the cause of a failure. `InResponseTo` also appears in the assertion and is covered under subject confirmation below. The one that can actually fail here is `Destination`: the exact URL the IdP addressed the message to, which must equal your assertion consumer service (ACS) URL. ~~~html ~~~ - **Correct:** `Destination` matches your ACS URL in full, scheme, host, path, and query string included. - **Fails when:** the decoded `Destination` differs from your ACS URL, so the SP rejects a message addressed elsewhere. Usually the IdP app holds the wrong ACS URL, or a proxy rewrote the host in front of the SP. - **Fix:** correct the ACS URL in the IdP app; if it looks right, check for a proxy changing host or scheme (http versus https). `Recipient` in the assertion must match this same URL. ### Issuer `` follows the header, and repeats inside the assertion. It holds the entityID of the IdP that issued the message, the IdP's unique identifier from its metadata. ~~~html https://idp.example.com/saml/metadata ~~~ - **Correct:** matches the entityID the SP has on file for the connection, exactly (`https://idp.example.com/saml/metadata` in the example). - **Fails when:** the value does not match, so the SP rejects the message as an unknown issuer or routes it to the wrong connection. Common right after an IdP migration changes the entityID while the SP still holds the old one. - **Fix:** re-import the IdP metadata on the [SAML connection](), or correct the entityID by hand. With several connections, confirm the login maps to the right one. The signing certificate ships in that same metadata, so a stale issuer and a stale cert usually re-import together. ### Status `` reports the outcome. Success appears as ``; that full URI, not the bare word "Success," is the value in the message. Anything else is a failure, and the response carries no assertion below it. ~~~html ~~~ - **Correct:** a single top-level `StatusCode` whose `Value` ends in `:Success`. - **Fails when:** the top-level `Value` ends in `:Requester` (fault in the SP's request), `:Responder` (the IdP could not process it), or `:VersionMismatch`. A nested second-level `StatusCode` gives the reason, and an optional `` often states it in plain text. Common second-level codes: - `:AuthnFailed` means the user failed to authenticate - `:InvalidNameIDPolicy` means the SP asked for a NameID format the IdP will not issue - `:RequestDenied` means the IdP could process the request but refused it - `:NoPassive` means the request asked for no user interaction, but the user was not already signed in - **Fix:** follow the code. `:Requester` means fix your side (ACS URL, `NameIDPolicy`, binding); `:Responder` usually means the user is not assigned to the app or an IdP policy blocked them. Nothing below this field in the SAML message matters until the status actually reads Success. ### Signature and certificates `` sits right after a repeat of `Issuer` (which is the same value you checked above). It may sign the response, the assertion, or both (the example signs the assertion). `SignatureMethod` gives the algorithm (RSA-SHA256), `DigestValue` binds it to specific content, and `` is the IdP's signing certificate. There’s not much you can do with the signature, even decoded. Validation is the SP's job, against the certificate it trusts. ~~~html ZXhhbXBsZURpZ2VzdFZhbHVlMDAwMDAwMDAwMDA9 ZXhhbXBsZVNpZ25hdHVyZVZhbHVlLXRoaXMtaXMtYS1kZW1vLXNhbXBsZS1ub3QtYS1yZWFsLXNpZ25hdHVyZS1wYWRkaW5nLXRvLWxvb2stcmVhbGlzdGljLTAwMDAwMDAwMDAwMDAwMDAwMDAwPQ== MIIDRzCCAi+gAwIBAgIUVIjNBEBr0Lwq9eUkDqJbkQ7D79kwDQYJKoZIhvcNAQELBQAwMzEYMBYGA1UEAwwPaWRwLmV4YW1wbGUuY29tMRcwFQYDVQQKDA5TQU1MIEd1cnUgRGVtbzAeFw0yNjA4MzAxOTAwMzBaFw0zNjA4MjcxOTAwMzBaMDMxGDAWBgNVBAMMD2lkcC5leGFtcGxlLmNvbTEXMBUGA1UECgwOU0FNTCBHdXJ1IERlbW8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDXjm5gaK/WnVmjcEgDPyMn6KgWnSGqGyFl8KfelmrMiR7AJ3QZwLzVG7UZPitteLm+NEBQNiSKocYLyTb+Kqtom3immlxVg1PNQHxjlDx06Ikf437RP4DFW79OLshE43c5QtJ98Vrp5nqL64dkfqRyXjSYKBFidtjEkj7ZiCkradg7jbWHRrkO6gyahYWGWRas5ftXwLG+FLTBigrXMQTApeXhLdMYU+P3fI6mZ2EBNc4/eQRfPYUYuYcye1X5hc2ZToWfMtOwhj8Knxz161G5+OAFvanwhS29THLtsJDurJqyF7mOcO6aaqrpevAJamb6kdgWh7aD80/quMsmvbq9AgMBAAGjUzBRMB0GA1UdDgQWBBRM9h5boXhlH6ueEEdofSNUP0K7HDAfBgNVHSMEGDAWgBRM9h5boXhlH6ueEEdofSNUP0K7HDAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQB8kRu6jnHyg/5Y9MYKjFfyiVF3wp5rmFIF+DZStoiOD3uc6yhPfDU2LafVk1EzvgQ+l03rMn5p8P18I879AsZX5XY9PcFnJEt2eMp8ZuBeukcAN/VQxi6J5cKdH3+r5G21IOhUWBh3Swb/4xEddjcrVuvZF++ecLmzZYW3s4So4J0NHcZC+iCxZvpm4ZS+Cl4+Yf97acCq+9RtvS6dmdFTjHNt0UO8cuSgEIlHfCuqvzMXP5SSeY0nauEAgopO75DiFCs77lb2TJugHfy78A7Rdi+eUWBQIOTSDjOqyxyf61zrTb6sJKWSFvdWHU6Vme3qm2Th83YbcvRjDmnv7Bns ~~~ - **Correct:** a signature present where the SP requires it, with an accepted algorithm, a matching digest, and a trusted certificate. - **Fails when:** a message that passes every readable check is still rejected. The failure is validation, not content, in a few buckets: - the SP's stored certificate no longer matches the IdP's, after a rollover or expiry (by far the most common) - the digest does not match because something altered the bytes in transit, so canonicalization (the normalizing step before hashing) no longer reproduces it - the SP requires a signature the message does not carry, such as a signed response when only the assertion is signed - **Fix:** re-import the IdP's current signing certificate from metadata and enable metadata refresh so rollovers do not break silently. On Descope, a bad or stale certificate reads as `E062604` or `E062606`. For a digest mismatch, find what is mutating the message in transit. Monitor certificate expiry ahead of the date. ### NameID In the assertion's ``, `` is the identifier the SP keys the user on, and its `Format` attribute is as load-bearing as the value. ~~~html jane.doe@example.com ~~~ - **Correct:** a stable value with a `Format` the SP expects, the same for a given user every login (`jane.doe@example.com`, `Format` ending in `emailAddress`, in the example). - **Fails when:** - a new user is created every login, or an existing one never matches, because the IdP sends a changing value, often a `transient` format where the SP expects a stable one - the login fails with a format complaint, because the SP's `NameIDPolicy` asks for a format the IdP will not issue - **Fix:** point the IdP at a stable attribute (email or a persistent directory ID) and set `Format` to match what the SP keys on. Keep both constant; changing either later splits one user into two accounts. ### Subject confirmation The `` (bearer method) ties the assertion to this login and recipient. `Recipient` must equal your ACS URL, the same value as `Destination`. `NotOnOrAfter` here is a bearer deadline, separate from `Conditions`. `InResponseTo` turns on login direction: SP-initiated logins send a request first, so it is present and must match the outstanding request ID; IdP-initiated logins have none, so it must be absent. ~~~html ~~~ - **Correct:** `Recipient` matches the ACS URL; `InResponseTo` matches the request, or is absent for an IdP-initiated login; the bearer deadline has not passed. - **Fails when:** an `InResponseTo` matching no outstanding request, or present on an IdP-initiated login, is rejected as unsolicited or a replay. The usual cause is the SP losing request state (a dropped session, or a load-balanced node that did not share it), not an attack. A `Recipient` mismatch behaves like a `Destination` mismatch. - **Fix:** match config to the real login direction: IdP-initiated needs the SP to accept unsolicited responses, SP-initiated needs request state to survive across nodes. Fix `Recipient` like `Destination`; an expired deadline is a timing problem, next. ### Conditions `` bounds validity with `NotBefore` and `NotOnOrAfter`; the SP checks the current time against that window. ~~~html ~~~ - **Correct:** validation falls between the two timestamps (the example allows five minutes either side of issuance). Window lengths vary by IdP; what matters is that the SP's clock reads a time inside it. - **Fails when:** a login that just happened is rejected as expired or not-yet-valid. That almost always means clock skew, the IdP and SP clocks disagreeing by more than the window's slack. A genuinely expired assertion, from a stalled redirect, is rarer. - **Fix:** sync both clocks to NTP. For unavoidable drift, allow a minute or two of skew tolerance on the SP rather than widening the window at the IdP. ### Audience Inside ``, `` names the one SP the assertion is for, written as that SP's entityID (`T2exampleTenant00000000000-P2exampleProject0000000000` for Descope; elsewhere a URI like [`https://sp.example.com/metadata`]()). ~~~html T2exampleTenant00000000000-P2exampleProject0000000000 ~~~ - **Correct:** matches the SP's entityID as an exact string. A trailing slash or an http/https difference is a different audience. - **Fails when:** a fully successful, in-window assertion is still rejected. When everything else checks out and the login fails anyway, read ``: it will not match the SP's entityID, and the SP error usually says "audience" or "not intended for this service provider." - **Fix:** set the IdP's audience (labeled Audience URI, Audience Restriction, or SP Entity ID) to the SP's exact entityID. On Descope, copy it from the tenant's SAML configuration rather than retyping. ### AttributeStatement `` holds the user attributes the SP maps to profile fields, roles, and groups. Each `` has a `Name` and one or more `` (the example sends email, name, department, multi-valued `groups`, and multi-valued `roles`). ~~~html jane.doe@example.com Jane Doe Engineering Engineering Admins Everyone viewer editor ~~~ - **Correct:** attribute names match what the SP maps against; multi-valued attributes arrive as repeated `` elements, not one delimited string. - **Fails when:** login succeeds but the profile is empty or roles and groups do not apply, from a name mismatch (`group` versus `groups`, or a display name where the SP wants an ID). On Descope, when Groups are configured as a mandatory attribute, the SSO Setup Suite connection test returns `E062028` when the assertion carries no groups at all, separating "misnamed" from "never sent." - **Fix:** align names on both sides and confirm multi-valued release. For group-to-role on Descope, set the [group mapping]() with the Groups Attribute Name the IdP uses, then map each group to a role. Confirm the IdP releases the attribute before chasing names. ### Simplifying SAML SSO setup and debugging with Descope A SAML decoder answers one question quickly: what did the IdP actually send? Reading the response top to bottom turns a generic login failure into a specific field to fix, and most of those fixes are a corrected URL, a synced clock, or an aligned attribute name. Bookmark [SAML Guru]() for the next time an SSO login breaks. Help your end user capture the SAML message, then paste it into the tool for debugging. If you would rather catch these problems before a user hits them, Descope lets you add SAML SSO without building the federation yourself, with self-service setup and connection testing for your customers' admins. Sign up for a [Free Forever account]() or [book time with our team](). ## FAQs about free SAML decoders --- ### [API vs. MCP: What's the Difference and When to Use Each?](https://www.descope.com/blog/post/api-vs-mcp) APIs and MCP serve different consumers. Compare discovery, auth, invocation, and determinism, then run the same Descope user search both ways. *Full content: [https://www.descope.com/blog/post/api-vs-mcp.md](https://www.descope.com/blog/post/api-vs-mcp.md)* *This tutorial was written by Manish Hatwalne, a developer with a knack for demystifying complex concepts and translating "geek speak" into everyday language. Visit *[*Manish's website*]()* to see more of his work!* --- APIs are the connective tissue of modern software. Every time an app talks to a payment processor, pulls weather data, or syncs a calendar, it's calling an API, usually over HTTP with JSON payloads. The model has lasted because it's simple: define an endpoint, send a request, and get a response. In discussions of AI agents, [MCP (Model Context Protocol)]() now comes up alongside APIs. MCP is a protocol that lets AI models discover and call tools at runtime. An agent pulls the list of tools an MCP server offers, then calls whichever one it needs, without a developer hardcoding which endpoint to hit. That has led to an "MCP vs. API" framing, as if choosing one rules out the other. The comparison doesn't quite hold, because the two solve different problems. An API is how two systems exchange data. MCP is how AI agents use external tools and services. This article covers where each sits in the stack, how they complement each other, and a demo that runs the same Descope task both ways. ## MCP and APIs: What each layer is for A REST API is a contract between a service, such as a payment processor or a weather service, and the code that calls it. That contract gets resolved when the code is written: a developer reads the docs, picks the right endpoint, and bakes that decision in before it ships. It's deterministic, documented, and versioned. If the API changes, you find out through a changelog, not a runtime surprise. MCP flips that around. It gives an AI model a standard way to discover tools at runtime with `tools/list` (the MCP method that returns a server's tool catalog) and invoke them with `tools/call` (the method that runs a specific tool with arguments). When an MCP client such as Cursor, Claude Desktop, or your own agent connects to an MCP server, it asks what's available and receives a list of tools. The model then picks the tool that fits the task based on the tool descriptions, at the moment it's needed. The clearer way to compare them is to ask who the consumer on the other end of the call is. A REST API is written for a developer building deterministic systems. MCP is written for an AI model selecting actions at runtime. Seen that way, the "vs." stops making sense. An MCP server often wraps existing APIs, though some are built as standalone implementations. Either way, it gives an AI model the same access a developer already has, resolved at runtime instead of write time. The diagram below shows both paths for Descope. An AI agent reaches the Descope Management API through an MCP server, while your code can still call that same API directly. Both paths land on the same backend. ![Fig: Two paths to the Descope Management API, through an MCP server or through a direct REST call.]() ## Four dimensions where MCP and APIs differ The consumer framing explains why MCP and APIs coexist. If you're building or evaluating either one, the differences show up in four places: discovery, authentication, invocation, and determinism. ### Discovery With a REST API, discovery happens before you write any code. You read the documentation or the OpenAPI specification to learn which endpoints exist, what parameters they take, and what they return. That knowledge is baked into your code by the time it ships. MCP moves that step to runtime. When a client connects to an MCP server, it sends a `tools/list` request and gets back a manifest of every tool the server exposes, including what each one does and which inputs it expects. The model reads that manifest fresh each session. If a new tool is added to the server, the model discovers it on the next connection without any code changes. ### Authentication Traditional APIs put authentication on the developer. You obtain an API key or OAuth token and attach it to every request, typically as a bearer token in the `Authorization` header (the standard HTTP header for credentials). When the token expires, your code has to refresh it, and calling five APIs means managing five sets of credentials. MCP moves most of that work out of the developer's code. The MCP specification bases authorization for remote servers on [OAuth 2.1](), and the authorization flow runs once, when the client first connects. From then on, the MCP client attaches the token to its requests automatically, and the model never handles it. On the other side of the connection, the MCP server holds whatever credentials it needs for downstream APIs and exposes only the actions its scopes allow. ### Invocation Calling a REST API is explicit by design. You pick the HTTP method, set the path, build the headers, and write the body. If the request is malformed, the server won't guess your intent. It returns an error. MCP invocation starts from a goal instead. A user tells an agent what they want, such as "What's the weather today?", and the model works backward from the tools it discovered to find the one that applies. It then constructs a structured `tools/call` request with the right parameters. That path from intent to action is assembled in real time rather than hardcoded. ### Determinism Determinism is the sum of the other three dimensions. A REST API call does exactly what the code says: same input, same endpoint, same output. You can test and trace it knowing exactly what will run. MCP trades some of that certainty for flexibility. The model chooses which tool to call and how, so the same request can resolve to different tool calls depending on context or phrasing. That flexibility suits open-ended tasks, and it's also why MCP deployments need guardrails, such as scoped permissions and human-in-the-loop approval for sensitive actions. The Descope MCP Server, for example, [starts every session in read-only mode](). Write operations require the user to explicitly elevate the session, and the write window closes automatically after a limited time. ## Demo: Running the same task through a REST API and MCP The clearest way to see the difference is to run one task both ways. The demo below searches for users in a Descope project, once with a direct Management API call and once through the Descope MCP Server, then compares what each approach requires. ### Prerequisites and setup You'll need a Descope account with a project and [at least one user added to it](). If you haven't created a project yet, follow the [project creation steps]() first. This demo uses a project called MCP-Vs-API, with `manish@example.com` added as a user. It connects to the Descope MCP Server from VS Code, but the server also works with Cursor, Claude Desktop, and other MCP-compatible clients. Follow the [VS Code setup in the Descope MCP Server documentation](). It adds this `.vscode/mcp.json` file (VS Code's workspace-level MCP configuration) to your project root: ~~~javascript { "servers": { "descope": { "type": "http", "url": "https://mcp.descope.com" } } } ~~~ That URL is the US endpoint. If your Descope projects are hosted in the EU region, [use the EU server URL]() instead. Next, connect the MCP server to your Descope account. VS Code prompts you to approve the connection, and once you do, your browser shows a confirmation screen: ![Fig: Authorizing the Descope MCP Server connection from VS Code.]() You only need to authorize once. After that, VS Code manages the session and token, so later requests run without you supplying credentials. ### Using the Descope Management API Before running the API call, you'll need two values: your Project ID, found on the [**Project Settings**]() page of the Descope Console, and a Management Key, created under **Company Settings**. The [Descope Management documentation]() explains how to generate one. Together they form the `:` pair that authenticates every Management API call. With a REST API, you need to know the endpoint, its parameters, and how to authenticate before you write the call. Here's the user search as a cURL request against the search endpoint: ~~~bash curl -X POST "https://api.descope.com/v2/mgmt/user/search" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer :" \ -d '{ "limit": 100, "page": 0 }' ~~~ The endpoint, `/v2/mgmt/user/search`, came from the [Search Users reference in the Descope docs](). Nothing in the request discovers it for you. The project isn't a body parameter either. It's implied by the Project ID and Management Key in the `Authorization` header. The body sets `limit` (the maximum number of results per page) and `page` (the zero-based page number). Both are optional, and `limit` defaults to 100, but this request sets them explicitly so it lines up with the MCP run later. The API returns raw JSON: ~~~javascript { "users": [ { "loginIds": [ "manish@example.com" ], "userId": "U3Ha...", "name": "Manish Hatwalne", "email": "manish@example.com", "phone": "", "verifiedEmail": true, "verifiedPhone": false, "roleNames": [], "userTenants": [], "status": "invited", "externalIds": [ "manish@example.com" ], "picture": "", . . . } ], "total": 1 } ~~~ ### Using the Descope MCP Server With the Descope MCP Server connected, you can use it directly from [GitHub Copilot]() in VS Code. > **Note:** Using the Descope MCP Server in VS Code requires a recent version of VS Code with GitHub Copilot or another MCP-aware extension active. Next, give Copilot the task in plain English: ~~~plaintext Task prompt: ------------- Please show me users from "MCP-Vs-API" project in my Descope account. ~~~ The prompt specifies no endpoint, no parameters, and no credentials. From there, Copilot worked out what the request required. It confirmed the active Descope session, listed the available projects, and selected MCP-Vs-API with the `selectProject` action, which belongs to the server's `session` tool (the tool that manages project context): ~~~javascript { "action": "selectProject", "args": { "projectId": "P3Ha..." } } ~~~ On its first attempt at the search, Copilot passed an unsupported parameter, `pageSize`. It recovered by calling `list_operations` (the tool that returns the server's operation catalog and input schemas) to check the `SearchUsers` schema, then retried with `{"limit": 100, "page": 0}`. Those are the same parameters you sent to the API endpoint explicitly. The model worked them out from the schema: ~~~javascript { "operation": "SearchUsers", "args": { "limit": 100, "page": 0 } } ~~~ The MCP server ran that operation against the Management API and returned the user record for `manish@example.com`, including name, status, and user ID. ![Fig: GitHub Copilot searching users in the MCP-Vs-API project through the Descope MCP Server.]() Copilot then summarized the record in natural language instead of raw JSON: ~~~plaintext Copilot response: ------------------- I found 1 user in the MCP-Vs-API project: Name: Manish Hatwalne Email: manish@example.com Status: invited User ID: U3Ha... If you want, I can also pull a fuller user record or list users by role/status. ~~~ Compare that with the REST call. The developer never looked up which endpoint handles user search, built the request parameters, or put a Management Key in a header. The model and the MCP server handled all of it. Behind the scenes, the Descope MCP Server exposes a set of tools, each grouping related Management API operations. The agent picks the tool that fits the request based on its description. The `SearchUsers` operation used above, for instance, belongs to the `users_read` tool. The full list is in the [Descope MCP Server tools reference](). **Tip:** The Descope MCP Server also includes `docs_ask_question`, a tool that answers natural-language questions about Descope with responses grounded in the official documentation. That means you can ask Copilot, or any other MCP-compatible coding assistant in your IDE, how a Descope feature works without leaving your editor, which helps when you're debugging. ### Comparing the two approaches The API call involved no session check, no project lookup, and no trial and error on parameter names. Everything was decided in advance, which is what you want from a deterministic system. The trade-off is that it required prior knowledge of the API, and the developer owned the credential, supplying a Management Key in the `Authorization` header on every call. The MCP route started from a prompt. Copilot used the tool descriptions and schemas to work out the exact request, correcting itself along the way. Put the two responses side by side and they describe the same user: same `userId` (the user's unique Descope identifier), same status, same backend. What changed is how the record was reached, not what came back. For Descope, MCP is a runtime front end that still calls the same Management API a developer would call directly. That's why it's best understood as a consumption layer on top of the API rather than a competing way to reach your data. ## REST API and MCP at a glance Here's the same comparison as a quick-reference table. | **Dimension** | **REST API** | **MCP** | | --- | --- | --- | | Consumer | A developer writing deterministic code | An AI model selecting actions at runtime | | Discovery | Learned in advance from API docs | Queried at runtime with tools/list, fresh each session | | Authentication | Credentials attached to every request by the developer, usually in an HTTP header | Authorized once at connection time; the client and server handle tokens from then on | | Invocation | Explicit: method, endpoint, headers, and body set by hand | Model-driven: the model maps a goal to a tool and sends a structured tools/call request | | Determinism | Same input always produces the same call | Same request can resolve to different tool calls depending on context | | Setup required per call | Know the endpoint, parameters, and response shape beforehand | The model reads tool descriptions and schemas and infers the parameters | | Error handling | Server returns an error on a malformed request | The model can often retry with a corrected call in the same session | | What it returns | Raw JSON, shaped exactly as the API defines | The same underlying data, often summarized in natural language | Every row points the same way: MCP and REST are built for different consumers, not different tasks. ## When to use REST API vs MCP The choice mostly comes down to who, or what, is making the call. ### When a REST API makes sense Use a direct API call when the workflow is known in advance and won't change based on context. A billing service charging a card through a payment processor doesn't need to decide anything. The endpoint and parameters are fixed, so a direct call is faster and easier to test than routing it through an AI model. The same goes for latency-sensitive calls, like loading a user profile on every page view, and for CI/CD pipelines running scheduled migrations. If you already know exactly which call needs to happen, a direct API call is the simpler choice. ### When MCP makes sense Use MCP when the right tool isn't known until runtime, which usually means an AI agent has to figure it out. A coding assistant asked to "check if this user's account is verified" doesn't know in advance which API applies, so MCP lets it discover and call the right one. The same logic applies to an AI support agent that might need to look up a user, issue a refund, or check a subscription, depending on what the customer asks. If you can't answer "What will this call need to do?" until the moment it happens, that's MCP's territory. ### Why production systems usually run both Most real architectures use both, each where it fits. Consider a SaaS company using Descope for identity. Its web and mobile apps call Descope's authentication APIs and SDKs directly for deterministic, high-volume work like signup, login, and session validation, and its backend calls the Management API for tasks like provisioning users. The same company might run an internal support tool where a support rep types a question such as "Was this user's email ever verified, and when did they last log in?" into an AI chat interface. That tool can connect to the Descope MCP Server and let the model figure out which tools answer the question. Engineers can use the same MCP server from their IDE to debug user issues without leaving the editor. ## Match the layer to the consumer The demo makes the relationship concrete: same user, same backend, two consumption layers. What separates MCP and REST APIs is the consumer on the other end of the call: how it discovers what's available, how it authenticates and invokes an action, and whether the outcome is fixed in code or decided at runtime. A REST API is built for a developer who already knows what they need. MCP is built for an AI model that has to figure that out. Deterministic, high-frequency, well-understood workflows belong on direct API calls. Anything that requires an AI agent to reason about which tool fits the request belongs on MCP. Most production systems, like the support tool example above, run both. If you're building on Descope, the [Descope documentation]() covers both layers: the Management API for deterministic, code-driven integrations, and the Descope MCP Server for AI agents that need to discover and act on the same data at runtime. And if you're putting an MCP server in front of your own API, the [Descope MCP documentation]() covers adding OAuth 2.1 authorization to it. --- ### [Build Auth-Ready MCP Apps With Descope and Skybridge](https://www.descope.com/blog/post/descope-skybridge-mcp) Skybridge ships Descope as a branded OAuth provider. Point descopeProvider at your project and your MCP App gets a production-grade authorization server in minutes. *Full content: [https://www.descope.com/blog/post/descope-skybridge-mcp.md](https://www.descope.com/blog/post/descope-skybridge-mcp.md)* Traditionally, AI responses are limited to text output in a chat window. That’s a limitation that actively hampers usability: sometimes a user needs to click a button, fill in a form, or see a map. [MCP Apps]() close this functional gap, allowing a tool call to display an interactive interface that renders directly inside Claude or ChatGPT. [Voyage Privé's MCP app]() is a good example of this in action. If you ask for a luxury hotel room for two adults in New York for the first week of June, you get an actual results widget with a clickable map. Instead of digging through a wall of text, you can comfortably view property details and go straight into a booking with the dates and number of guests preserved. ![Fig: Voyage Prive’s MCP App]() The moment that interface needs to know who's using it, though, developers run into the same wall every MCP server hits: [spec-compliant OAuth is non-trivial to build from scratch](). Skybridge, a full-stack TypeScript framework for building MCP Apps, closes that gap with `descopeProvider`. Point it at your Descope project and your MCP App inherits a production-grade authorization server without your team needing to build any protocol plumbing. ## How the integration works Skybridge handles the MCP server, view rendering, and client compatibility, so you write React components instead of wiring up MCP transport by hand. `descopeProvider` extends that same philosophy to auth. Give it your MCP Server's Issuer URL from Descope, and Skybridge publishes the OAuth metadata Claude and ChatGPT need to discover Descope as an authorization server, verifies every access token Descope issues, and enforces scopes before a tool call runs. Here’s what wiring it up looks like: ~~~typescript import { descopeProvider, Skybridge } from "skybridge/server"; export const app = new Skybridge({ name: "auth-coffee", version: "0.0.1", oauth: descopeProvider({ url: process.env.DESCOPE_MCP_SERVER_URL, scopes: [""], }), handler: (server) => { /* ... */ }, }); export type AppType = typeof app; ~~~ Every request Skybridge routes to a tool call has already been through Descope's OAuth flow without any manual token parsing or separate library to verify the JWT yourself. Descope handles the consent screen, [Dynamic Client Registration (DCR)](), and issuing the token in the first place. ## A working MCP server in a few minutes Setup follows the same flow as any other Skybridge auth integration. - Skybridge provides a reference implementation for this integration:[ auth-descope](), a coffee shop finder that greets the authenticated user and surfaces their saved favorites. Run it, and Skybridge hands you a tunnel URL (which looks something like `https://tough-pants-worry-546.alpic.dev`): ~~~bash npx create-skybridge --example auth-descope ~~~ - In your [Descope console](), go to[ Resources]() and create a new MCP Server resource. Give it a name, and in the MCP Server URL field, paste the tunnel URL you get from running the Skybridge example. - Turn on [Dynamic Client Registration]() under MCP Client Registration since `descopeProvider` requires it so Claude and ChatGPT can register themselves automatically instead of you registering each client manually. If you need to run with DCR disabled behind Alpic's DCR proxy, go with `customProvider` with `serverUrl` instead; Skybridge ships an [auth-descope-alpic]() variant for that exact scenario. ![Fig: MCP server configuration in the Descope console]() - Grab the Issuer URL from Connection Information. The Issuer looks like `https://api.descope.com/v1/apps/agentic//`. `descopeProvider` parses the project ID out of that same string to set the token audience, so on a custom domain—where that segment isn't present—pass `audience` explicitly or the server will throw at startup. Drop the URL into your environment: ~~~bash DESCOPE_MCP_SERVER_URL=https://api.descope.com/v1/apps/agentic// ~~~ - Restart and open it in Claude or ChatGPT. Your MCP App now runs behind a real OAuth 2.1 flow. ## Why run it on Descope Skybridge ships branded providers for several identity vendors, so the question that actually matters here isn't whether the auth works. It's whether what sits behind it is siloed or connected to everything else you need for identity.  If your company runs Descope for anything else, your MCP App plugs into the same unified identity layer: the same users, consent flows, and audit trails all live in one coherent auth universe. You won’t be standing up a secondary auth system to absorb what your day-one build can’t do, and you won’t have to reconcile two sets of user identities when someone signs in through Claude instead of your portal. Beyond simply logging in, the [Agentic Identity Hub]() covers the rest of what an agentic app ends up needing: inbound auth for the clients calling your MCP server, outbound token management for the third-party APIs your tools call on the user's behalf, and scope and policy enforcement across both. Those pieces would take months to build by hand when you eventually need them down the road, but Descope makes them plug-and-play simple.  You can find the Skybridge integration on Descope’s console, too. Open any MCP Server resource, click **Usage Samples**, and you'll find a **Skybridge** tab next to FastMCP, pre-filled with your project's discovery URL. ![Fig: The code sample for connecting your Skybridge MCP server to Descope]() ## Try it yourself [Create a free Descope project](), point it at your tunnel URL, and you'll have a secure MCP App running in Claude or ChatGPT in a few minutes. Want to learn more about Descope? [Use our MCP server](), join our[ AuthTown dev community](), or[ explore the Agentic Identity Hub]() to see more AI use cases in action. --- ### [Top 5 Firebase Authentication Alternatives for 2026](https://www.descope.com/blog/post/firebase-authentication-alternatives) Compare the top 5 Firebase Authentication alternatives for 2026, including Descope, Supabase, Keycloak, and Cognito, and how to avoid vendor lock-in. *Full content: [https://www.descope.com/blog/post/firebase-authentication-alternatives.md](https://www.descope.com/blog/post/firebase-authentication-alternatives.md)* The top Firebase Authentication alternatives for 2026 are Descope, Supabase, Keycloak, Amazon Cognito, and Microsoft Entra External ID, each suited to a different need. Firebase Authentication is a go-to identity solution for developers building on Google Cloud, especially for mobile-first or early-stage applications. However, as apps grow in complexity and scale, teams find themselves constrained by its limitations and look for alternatives that offer more control over cost, data, and identity features, without being tied to a single cloud provider. In particular, vendor lock-in, limited backend flexibility, cost and scalability concerns, data privacy needs, and other issues often push developers to look for Firebase Auth alternatives that offer greater customization, better cost control, and true enterprise-grade features. In this guide, we’ll cover: - Why developers seek out Firebase Auth alternatives - What the top Firebase Auth alternatives have to offer - How to pick the best Firebase Auth for your needs ## At a glance - The top Firebase Authentication alternatives for 2026 are Descope, Supabase, Keycloak, Amazon Cognito, and Microsoft Entra External ID. - Developers look beyond Firebase Auth mainly to avoid Google vendor lock-in, as well as for more control over cost, data, and identity features. - Descope leads for teams that want to add and change auth through visual workflows without writing custom code, with passkeys, MFA, and AI agent authentication built in. - Supabase and Keycloak are the strongest open-source and self-hosted options, while Amazon Cognito and Microsoft Entra External ID suit AWS and Microsoft-aligned teams. - The right choice depends on whether you want a managed platform, an open-source option, or an ecosystem-native service, and on your developer experience and compliance needs. ## Quick facts | **What Firebase Auth is** | Google’s managed authentication service, built into Firebase and tightly coupled to Google Cloud | | **Why developers seek alternatives** | Vendor lock-in, cost and scalability concerns, data privacy needs, and limited customization | | **Top alternatives** | Descope, Supabase, Keycloak, Amazon Cognito, and Microsoft Entra External ID | | **Open-source options** | Supabase and Keycloak, both self-hostable with no licensing costs | | **Key consideration** | Whether you want a managed platform, an open-source option, or an ecosystem-native service | ## Why developers seek Firebase Auth alternatives Avoiding Google vendor lock-in is the single biggest reason developers look for a Firebase Auth alternative. Many teams outgrow Firebase Authentication for a few key reasons: - **Vendor lock-in:** Firebase is tightly integrated with Google Cloud services, making it difficult to migrate to other platforms without major architectural changes. - **Cost and scalability:** Firebase’s usage-based pricing can result in unpredictable cost spikes, especially for high-traffic or global applications. - **Data privacy and control:** User data is stored on Google’s infrastructure by default, which can make it harder to meet strict compliance requirements such as GDPR or HIPAA. - **Limited customization and infrastructure control:** Firebase offers minimal flexibility for teams that want to self-host, support hybrid environments, or build multi-tenant and partner-specific auth flows. - **Security and compliance concerns:** Firebase relies on basic security defaults and lacks built-in tools for advanced security orchestration, leaving room for misconfigurations that could expose user data. Each option below is a popular Firebase Authentication alternative, but they differ in strengths depending on your technical requirements and product roadmap. ## Firebase Auth alternatives at a glance Here’s how the top Firebase Auth alternatives compare: | **** | **Key capabilities** | **Developer experience** | **Open source** | **Strengths** | **Ideal for** | | --- | --- | --- | --- | --- | --- | | **Descope** | Flexible auth support, connector ecosystem, strong multi-tenancy, AI and agentic support | No-code and low-code visual workflows, SDKs, APIs, MCP server and skills | No | Visual workflows, predictable pricing, self-service SSO and SCIM, adaptive MFA | Devs building cross-platform, multi-tenant, or agent-ready apps | | **Supabase** | Many auth options, row-level security, serverless functions, flexible SDKs | Firebase-like APIs and SDKs, dashboard-driven setup | Yes | Open-source and self-hostable, Postgres integration, Firebase-like UX | Devs and startups seeking a stack like Firebase with more backend control | | **Keycloak** | Self-hosting, built-in admin console, fully customizable UX, protocol flexibility | Admin console-driven, steeper setup curve | Yes | Full auth control, protocol flexibility, open-source with vendor neutrality | Orgs with DevOps resources that want to self-host auth and need customization | | **Amazon Cognito** | User pools, federated ID support, AWS triggers for auth flow customization | AWS-native tooling, Lambda-driven customization | No | Deep AWS integration, flexible federation options, custom auth logic | AWS-invested teams that need flexible ID federation and are OK with complexity | | **Microsoft Entra External ID** | Self-service, branded user journeys, built-in security, strong user lifecycle management | Azure-native tooling, policy-driven configuration | No | Enterprise alignment, compliance-ready, user ID governance functionalities | Orgs that already use MS infrastructure and need enterprise ID management tools | Below, we’ll take a closer look at how each platform works and their optimal use cases. ## Descope ### Overview Descope is a modern external IAM platform designed for developers who need flexible, secure authentication without the overhead of managing complex infrastructure. It’s ideal for both B2C and B2B SaaS apps, especially those that need built-in support for multi-tenancy, partner integrations, or IAM for AI agents and MCP ecosystems. ![Descope Flows homepage]() Descope includes native features like organization management, tenant-aware SSO, and fine-grained access controls, making it easy to scale across users and environments. In addition, it enables teams to ensure secure, scoped, and consented access for their AI agents and MCP servers, an approach [industry analysts have called out]() while recognizing Descope as one of the first identity providers to treat AI agents as first-class identities. ### Key capabilities - Visual [workflow editor]() to create and modify login, signup, and MFA flows - Extensive plug and play [connector ecosystem]() for seamless integration with third-party services - [Anonymous user tracking]() for top-of-funnel B2C user visibility - Comprehensive [SSO Setup Suite]() for configuring, mapping, and testing SSO and SCIM connections - [Embeddable UI widgets]() for self-service identity management and admin - Support for a wide range of auth methods including [passkeys](), [OTP](), [magic links](),[social login](), and [Google One Tap]() - Built-in multi-tenant management with [RBAC]() and [FGA]() - [Adaptive MFA](), [session protection](), and [bot detection]() - Support for 15+ web, mobile and backend SDKs and a robust [REST API]() - [Identity orchestration]() that coordinates authentication, authorization, risk, and fraud tools - [Agentic identity]() support to get agents enterprise-ready and organizations agent-ready ![Descope Outbound App Library]() ### Firebase integration made easy Developers may not want to move away from Firebase Authentication completely, but still seek more robust capabilities to customize login, MFA, or user onboarding.  By acting as a [federated identity provider via OpenID Connect](), Descope handles the user authentication flow, then passes the authenticated user to Firebase. This setup adds flexibility without losing Firebase’s core capabilities. Descope also lets you [add passkey authentication]() to your Firebase app by acting as an OIDC identity provider. It handles the full passkey login flow and sends the authenticated user to Firebase, enabling secure, passwordless login without changing your backend. Moreover, Descope provides a [Firebase Connector]() that lets you use Descope authentication without moving your product off Firebase. With this integration, Descope can return a Firebase-compatible token as part of the authentication response—available through SDKs or API. ![Firebase connector]() ### Strengths - **Visual workflows:** Descope’s drag and drop editor lets developers design login, signup, MFA, and SSO flows without backend scripting or custom glue code. This simplifies auth implementation and speeds up time to production. - **Predictable pricing and responsive support:** Descope offers transparent, usage-based pricing with no hidden fees or surprise jumps. Teams benefit from fast, knowledgeable support to help them implement, troubleshoot, and scale with confidence, as evidenced by Descope winning the Best Support G2 badge the last eight quarters in a row. - **Streamlined SSO: **Build and manage SSO journeys with workflows, enable self-service setup, and migrate existing configurations with no disruption. - **Passwordless authentication:** Descope supports passkeys, magic links, OTP, and social login natively. These methods can be easily added to any flow, reducing reliance on passwords while improving UX and security. - **Omnichannel authentication:** With Descope, authentication flows can be unified across web, mobile, and third-party or partner applications. The same no-code or low-code workflows can be reused across environments, making updates and scaling easier over time. - **Adaptive MFA:** Firebase Authentication’s own MFA is limited to SMS by default, with TOTP authenticator-app support only available after upgrading to the paid Identity Platform tier. Descope includes a wide range of MFA methods out of the box and lets developers enforce them only when needed, using native and third-party risk signals, without overhauling existing auth systems. - **Enterprise agent ready:** Descope supports secure authentication and access control for agentic AI systems through its [Agentic Identity Hub](). - **Built for developers:** Whether using hosted components or fully custom UIs, Descope gives developers flexibility with SDKs and APIs in React, Node.js, Python, Flutter, and more. The platform fits into any tech stack without locking teams into rigid patterns. ### Ideal for Developers building cross-platform, multi-tenant, or agent-ready apps who want auth flows they can launch and modify quickly without backend rewrites. ### Limitations As a newer platform than some of the legacy providers on this list, Descope has a smaller enterprise case study library, though its production customer base is growing quickly across both B2C and B2B SaaS deployments and includes customers such as GoFundMe, Databricks, Linktree, and Navan. Because Descope is a managed service rather than something you self-host, teams that specifically want to run their own auth infrastructure on their own servers will find Keycloak or self-hosted Supabase a closer fit. ## Supabase ### Overview Supabase is an open-source Firebase alternative that offers a backend-as-a-service experience with built-in authentication, Postgres database, storage, and edge functions. Its authentication service is powered by GoTrue, a JWT-based auth server, and supports multiple login methods out of the box. Supabase is a good choice for developers who want Firebase-like functionality with more transparency and control. ![Supabase homepage]() ### Key capabilities - Email/password, magic link, and third-party OAuth providers - Postgres-based auth with row-level security - Serverless functions (Edge Functions) for backend logic - SDKs for JavaScript, Flutter, and other platforms - Self-hosted or fully managed deployment options - Support for asymmetric JWT signing, with P-256 elliptic curve and RS256 options ### Strengths - **Open-source and self-hostable:** Supabase allows full control over the backend and can be deployed on your own infrastructure. - **Tight integration with Postgres:** Offers fine-grained access control and real-time capabilities using native Postgres features. - **Firebase-like developer experience**: Provides an easy transition for teams familiar with Firebase but looking for open standards and flexibility. ### Ideal for Developers and startups that want a Firebase-style stack with more backend control and the ability to self-host if needed. ### Limitations Authentication is one part of a broader backend platform for Supabase, so advanced identity features like fine-grained multi-tenancy or enterprise SSO orchestration are less deep than what a dedicated identity provider offers. Self-hosting adds operational work too: teams running their own GoTrue instance lose access to some dashboard-managed OAuth provider settings and take on responsibility for upgrades, backups, and scaling that a managed platform would otherwise handle. ## Keycloak ### Overview Keycloak is an open-source identity and access management solution built by Red Hat. Unlike Firebase Authentication, which is a hosted, simplified solution tied to Google Cloud, Keycloak gives developers full control over their auth infrastructure. It’s designed for teams that want to self-host and customize every part of their login and identity flows. ![Keycloak homepage]() ### Key capabilities - Self-hosted deployments with support for clustering and high availability - Built-in admin console to manage users, roles, and authentication realms - Customizable login screens and authentication flows - Native support for standard protocols including SAML, OIDC, and LDAP - Fine-grained role-based and attribute-based access control - Step-up authentication support extended to SAML service providers (in early preview), alongside existing OIDC support ### Strengths - **Full control over authentication stack:** Unlike Firebase, Keycloak allows teams to deeply customize their identity setup, including user journeys, token lifetimes, and login screens. - **Protocol flexibility:** Supports enterprise standards like SAML and LDAP out of the box—protocols not natively supported by Firebase Auth. - **Open-source and vendor-neutral:** Can be deployed in any environment with no licensing costs, offering more long-term flexibility than Firebase’s Google Cloud lock-in. ### Ideal for Organizations with DevOps resources that want to self-host authentication and need maximum flexibility around protocols, customization, and integration with legacy systems. ### Limitations Keycloak is self-hosted only, so it requires dedicated DevOps resources for deployment, upgrades, and scaling, with no managed cloud option from the maintainers to fall back on. Teams without existing platform engineering capacity often underestimate the ongoing maintenance burden until they’re a few releases in. **Also read: **[**Top 6 Keycloak Alternatives**]() ## Amazon Cognito ### Overview Amazon Cognito is AWS’s native authentication and user management service, offering secure access control for web and mobile apps. Like Firebase Authentication, it provides built-in support for user sign-up, login, and federated identity. However, while Firebase emphasizes simplicity and fast setup, Cognito requires more AWS-specific knowledge and is better suited to teams already building within the AWS ecosystem. ![Amazon cognito homepage]() ### Key capabilities - User pools for managing and authenticating users - Federated identity support with SAML, OIDC, and social providers - AWS Lambda triggers to customize auth flows - Native integration with AWS services like API Gateway, AppSync, and IAM - Multi-Region replication for authentication resilience during regional outages - Self-service, on-demand provisioned API rate limits ### Strengths - **Deep AWS integration:** Works seamlessly with other AWS services, making it ideal for applications already running on the AWS stack. - **Flexible federation options:** Supports SAML, OIDC, and major social providers, offering more identity protocol coverage than Firebase. - **Custom auth logic:** Developers can use Lambda triggers to inject custom behavior into sign-up, sign-in, and token issuance flows—something Firebase only supports with more limited extensibility. ### Limitations UI customization is limited compared to purpose-built CIAM platforms, multi-tenant identity needs workarounds rather than native support, and Cognito is best suited to teams already on AWS rather than those wanting a cloud-agnostic option. **Also read:** [The Top 5 Amazon Cognito Alternatives]() ## Microsoft Entra External ID ### Overview Microsoft Entra External ID is a cloud-based identity and access management service designed for enterprises that need to allow external identities to securely access their apps and resources. While Firebase Authentication focuses on quick setup and developer-friendly tools, Entra External ID is built for complex enterprise environments that require advanced security, compliance, and governance features. It offers powerful capabilities but may be harder to implement for teams not already using Microsoft infrastructure. ![MS Entra External homepage]() ### Key capabilities - Supports self-service registration and sign-in with social or enterprise identities - Enables branded, customizable user journeys for external apps and portals - Includes built-in security, conditional access, and MFA options - Manages user lifecycle with governance, access reviews, and expiration policies - Delegated credential management API for letting customer-facing apps manage a signed-in user’s own passkeys ### Strengths - **Enterprise alignment: ** Includes native tools for compliance, access control, and identity lifecycle management. - **Compliance-ready: **Works with Microsoft cloud and productivity services, making it a strong fit for existing Azure environments. - **Identity governance features:** Native tools for managing user lifecycle, permissions, and audit trails ### Ideal for Large organizations that already use Microsoft 365, Azure, or hybrid infrastructure and need enterprise-grade identity management and governance. ### Limitations Entra External ID is tightly coupled to the Microsoft ecosystem and less flexible for multi-cloud teams. The External ID feature set, while maturing quickly, is still newer and less complete than workforce-focused Entra ID. ## How to choose the right Firebase Auth alternative When choosing the best Firebase Auth alternative, consider your existing infrastructure, needs, and reasons for augmenting or replacing Firebase Auth. | **If your priority is** | **Consider** | **Why** | | --- | --- | --- | | Avoiding vendor lock-in | Descope, or a self-hosted option like Supabase or Keycloak | Descope gives you a managed platform not tied to a single cloud, while self-hosting gives you full infrastructure ownership | | A simple, vendor-neutral setup | Descope | Visual workflows, SDKs, and an MCP server get auth running quickly without committing to one cloud ecosystem | | Open-source flexibility and control | Supabase or Keycloak | Both are self-hostable with no licensing costs, trading operational work for full control | | Staying within an existing AWS environment | Amazon Cognito | Deep native integration with AWS services like Lambda, API Gateway, and IAM | | Staying within an existing Microsoft environment | Microsoft Entra External ID | Built-in alignment with Azure, Microsoft 365, and enterprise governance tools | | Enterprise SSO features | Descope or Microsoft Entra External ID | Both offer enterprise-ready SSO and compliance functions, with Descope spanning ecosystems and Entra External ID suited to Microsoft-aligned orgs | ## Move beyond Firebase Auth with Descope Descope gives teams a managed alternative to Firebase Auth with no vendor lock-in to a single cloud, adding login, passkeys, and MFA through SDKs and visual flows instead of custom backend code. Teams get the flexibility of a fully customizable auth system without the maintenance burden of self-hosting or the constraints of staying inside one cloud provider’s ecosystem. [Sign up for a Free Forever account]() with Descope and start building secure, scalable auth flows today. Have questions about augmenting or replacing Firebase? [Book time with our experts](). ## FAQs about Firebase Auth alternatives --- ### [WebAuthn vs FIDO2: Understanding the Differences](https://www.descope.com/blog/post/webauthn-vs-fido2) Learn the difference between WebAuthn and FIDO2, how they work together for passwordless login, and which to implement. *Full content: [https://www.descope.com/blog/post/webauthn-vs-fido2.md](https://www.descope.com/blog/post/webauthn-vs-fido2.md)* WebAuthn is the web-based API that lets browsers and apps register and verify passkeys or security keys, while FIDO2 is the broader standard made up of WebAuthn plus the Client to Authenticator Protocol (CTAP). WebAuthn is a part of FIDO2, not a competing alternative to it, which is the main thing to understand about how these two terms relate. One of the biggest recent advancements in authentication, authorization, and user account management across all virtual platforms has been the shift toward passwordless authentication. [Over a third of all organizations worldwide]() plan to adopt or continue using passwordless authentication in the next one to three years. And two of the top options available to them are WebAuthn and FIDO2. Below, we’ll provide an overview of these two [authentication protocols](), dive into their similarities and differences, explore the benefits of using one or both, and explain how to implement them. ## At a glance - WebAuthn is a component of FIDO2: FIDO2 is made up of the WebAuthn API and the Client to Authenticator Protocol, or CTAP. - WebAuthn is the web API, standardized by the W3C, that lets a browser or app register and verify a passkey or security key. - FIDO2, from the FIDO Alliance, is the full passwordless standard that combines WebAuthn for the web side with CTAP for the device side. - They work together for passwordless login: WebAuthn talks to the app, CTAP talks to the authenticator, and a passkey is the credential they exchange. - For most web apps, implementing WebAuthn is implementing the web-facing part of FIDO2, so developers rarely choose one over the other. ## Quick facts | **What WebAuthn is** | A W3C web standard and API that lets browsers and apps authenticate users with passkeys or security keys | | **What FIDO2 is** | The full passwordless standard from the FIDO Alliance, combining WebAuthn and CTAP | | **How they relate** | WebAuthn is one of FIDO2’s two required components, not a separate or competing standard | | **Who standardizes each** | WebAuthn is standardized by the W3C; FIDO2 as a whole is published by the FIDO Alliance | | **Key takeaway** | You can’t have FIDO2 without WebAuthn, though WebAuthn can be discussed and used on its own | ## What is WebAuthn? Web Authentication API, better known as WebAuthn, is an open standard for user authentication on web applications published by the World Wide Web Consortium (W3C). It relies on public-key cryptography, a highly secure framework involving key pairs, to authenticate users across services without a password. To learn more about how the WebAuthn registration and login flows work in detail, see our full [guide to WebAuthn](). The history of WebAuthn dates back to 2013, when it was proposed because of rising concerns about password security. Level 1 was published as an official W3C recommendation in 2019, Level 2 followed in 2021, and Level 3 reached full W3C Recommendation status in August 2026. Work on Level 4 has begun, though no draft has been published at the time of writing. Reaching full Recommendation status matters because it means the spec’s behavior is stable enough for browser vendors and platform makers to build against with confidence. For teams evaluating WebAuthn today, that stability is one more reason the earlier “wait and see” posture toward the spec no longer applies. Along with Client to Authenticator Protocol (CTAP),  it's one of the two components of FIDO2, which we’ll discuss shortly. Today, WebAuthn is supported by essentially every major browser, covering about 96% of global browser traffic, and both Google and Apple have shipped full support across their platforms and browsers. Android supports passkeys through the Credential Manager API, which replaced the older FIDO2 API for most use cases, though that API is still used for physical security keys and non-discoverable credentials. Apple has built WebAuthn-based passkeys directly into iOS, iPadOS, and macOS, syncing them through iCloud Keychain. WebAuthn works by associating a user with *something they are or possess*, such as [biometrics]() or a hardware security key, though the most common application is via a mobile device that can combine both factors. Once the association is made, a [passkey]() is generated which is then used for any future login attempts. This process ensures security by focusing on inherence and possession factors rather than knowledge factors ([passwords]()) that can be stolen or cracked. At the same time, it maximizes the user experience (UX) and minimizes friction. ## What is FIDO2? FIDO2 is an open authentication standard comprising two components, CTAP and WebAuthn, published by the Fast Identity Online (FIDO) Alliance. As its name implies, FIDO2 is an updated version of the original FIDO specification, enabl passwordless authentication across web and mobile applications. For the full breakdown of FIDO2, how it differs from the earlier FIDO U2F and UAF standards, and how FIDO authentication works step by step, see our dedicated [FIDO2 guide](). [The FIDO Alliance](), which launched in February 2013, has grown substantially, presently including several hundred member companies dedicated to streamlining secure authorization. It was formed by Lenovo, Nok Nok Labs, PayPal, and Validity Sensors, with Google and Microsoft joining later that year. The roster has since expanded to cover most major platform, browser, and device makers, including Descope. The other main component of FIDO2 is the Client-to-Authenticator Protocol (CTAP), which provides a uniform standard for communication between the client (i.e., a website or app) and roaming authenticators (e.g., a smartphone). Combining this with the cryptographic authentication of WebAuthn, FIDO2 enables secure passwordless authentication across a wide variety of applications with minimal friction for the user. ## WebAuthn vs FIDO2: key differences Given the interconnectedness of FIDO2 and WebAuthn, they’re often referred to interchangeably. However, there are key differences between them: - **FIDO2** is the broader term and standard that covers the entire passwordless authentication system (WebAuthn + CTAP). - **WebAuthn** specifically refers to the web API part of FIDO2 that developers use to enable browser-based (or Android-native) passwordless authentication. Simply put, it’s impossible to have FIDO2 without WebAuthn. | **Aspect** | **WebAuthn** | **FIDO2** | | --- | --- | --- | | **What it is** | A web API for registering and verifying passkeys or security keys | A full passwordless authentication standard | | **Scope** | Covers the browser/app-to-authenticator handshake on the web side | Covers WebAuthn plus device-to-authenticator communication (CTAP) | | **Standardized by** | W3C | FIDO Alliance (incorporating the W3C’s WebAuthn spec) | | **Covers the device side** | No; relies on CTAP for external authenticators | Yes, through CTAP | | **Relationship** | A required component of FIDO2 | The complete standard; cannot exist without WebAuthn | ![Fig: FIDO2 components]() ## How WebAuthn and FIDO2 work together for passwordless login WebAuthn and CTAP hand off a login request between the browser and the authenticator, with a passkey as the credential that ties the exchange together. In practice, this handoff runs in four steps: 1. The web app calls the WebAuthn API in the browser to start a registration or login request. 2. WebAuthn passes that request to the authenticator. If the authenticator is external, such as a phone or a security key, this hop uses CTAP to communicate with it. 3. The authenticator creates or unlocks a passkey, confirmed with a local gesture like a fingerprint scan, face scan, or device PIN. 4. The authenticator signs the challenge and sends the response back through WebAuthn to the app, which verifies it and completes the login. This division of labor, WebAuthn on the web side and CTAP on the device side, is what lets an authenticator that isn't built into the browser take part in a login at all. Passkeys move between a user's devices separately, either by syncing through a provider like iCloud Keychain or Google Password Manager, or through CTAP's hybrid transport, which lets a user sign in on one device with a passkey held on another. It’s also why [passkeys]() are often described as the user-facing product of FIDO2: the standard defines the mechanics, and the passkey is the credential a person actually sees and uses. However, it’s worth considering how WebAuthn and FIDO compare to other common solutions. ### Use cases for WebAuthn and FIDO2 Choosing between various authentication protocols often comes down to the specific use cases and needs in a target deployment. For example, [SCIM and SAML]() are most apt for identity management or single sign-on (SSO), respectively. Likewise, whether to use [OIDC or SAML]() depends on whether target systems are more web/mobile based (OIDC) or utilize more legacy software (SAML). Choosing between a full FIDO2 implementation and WebAuthn is similar, with one key difference: imbalance. Using FIDO2 requires WebAuthn, but it is possible to use CTAP with a platform-specific API rather than generic WebAuthn. Some major platforms implement CTAP in this way, like Microsoft’s [Win32 WebAuthn API]() or Google’s [FIDO2 API for Android](). As the names of these APIs suggest, they are compliant with the WebAuthn and FIDO2 specifications, but they offer extra integration with their specific platforms. Regardless, all FIDO2 use cases are WebAuthn use cases by default. And it’s a boon, as most environments using contemporary and emerging technologies will favor the greater security and assurance that come with FIDO2’s combination of WebAuthn and CTAP. However, mature organizations that depend heavily on legacy software may have no choice but to use WebAuthn with the older FIDO 1.0 Universal Authentication Framework (UAF) or Universal Second Factor (U2F), which our [FIDO2 guide]() covers in more depth. A few common deployment patterns illustrate where each fits in practice. - A consumer web app that only needs users to sign in from a browser, on a laptop or phone they already own, typically only needs WebAuthn. The browser’s built-in platform authenticator (Face ID, Windows Hello, or a fingerprint sensor) handles the biometric or PIN check, and no external hardware or CTAP handoff is involved. - An enterprise rolling out hardware security keys to employees, on the other hand, needs the full FIDO2 stack. WebAuthn to talk to the browser and CTAP to talk to the physical key over USB, NFC, or Bluetooth. - A native mobile app that wants to let a user sign in with a security key they’ve already registered on their laptop needs CTAP specifically, since that’s the protocol that lets an external authenticator participate outside the browser context WebAuthn was originally built for. ## The biggest benefits of WebAuthn and FIDO2 WebAuthn and FIDO2 are more similar than different, and this becomes much more apparent through the benefits they provide. Both streamline login, account management, and overall authentication processes. This all starts from favoring passwordless authentication methods over traditional password-centric ones, which are susceptible to credential theft and weak or mismanaged credentials. Well-intentioned users could create weak passwords or fail to update them due to fatigue from the abundance of accounts. And simply *having* credentials to steal makes users prime targets for cybercrime. In addition, both platforms make account management significantly easier for users, which improves overall UX and cuts down resource costs for IT helpdesk calls and other support. Password resets are a leading driver of helpdesk tickets at most organizations, and removing the password removes that ticket category almost entirely. Another major benefit of both WebAuthn and FIDO2 is their widespread adoption. About 96% of global browser traffic now runs on browsers that support WebAuthn according to caniuse.com, and that number keeps climbing as platforms add or increase their support. Adoption at scale isn't new, either: [Discord rolled out security key support]() to all users in December 2023, giving more than 500 million accounts a FIDO2-based option well before passkeys became mainstream. Major consumer platforms have since followed at larger scale. Amazon reports over [175 million customers signing in with passkeys](), and [Microsoft recorded a 987% increase in passkey use]() in late 2024 after redesigning its sign-in experience to default to passkeys where available. Together, these examples show adoption compounding across nearly every category of consumer platform, from gaming and social apps to e-commerce and productivity software. ## Which should developers implement, WebAuthn or FIDO2? For a typical web app, developers implement WebAuthn, which is the web-facing part of FIDO2, so the choice is rarely one versus the other in practice. Calling the WebAuthn API from your app already gets you the FIDO2 security model for anything that authenticates directly in the browser. FIDO2 as a whole, and CTAP specifically, become relevant when you need to support external roaming authenticators, like a USB security key connecting to a device over a protocol WebAuthn alone doesn’t handle, or when you’re building native mobile or desktop experiences alongside the web. In those cases, you’re still building on WebAuthn; you’re just also accounting for the CTAP layer that lets an external authenticator participate. In practice, most teams don’t implement either specification’s raw API by hand. A platform or SDK [like Descope]() handles the registration and authentication ceremonies, the CTAP handoff to external authenticators, and the edge cases around device loss and account recovery, which is considerably less work than building and maintaining that logic in-house. ## Implementing WebAuthn and FIDO2 in applications For developers, WebAuthn and FIDO2 can be installed in nearly any software project. And for adopters, beyond simply adding the functionality, there are also issues of inventory and staff training to account for, along with compatibility scanning to ensure consistent interoperability across devices. [Setting up passkey authentication]() with WebAuthn and/or FIDO2 is as simple as: - Installing or importing and then initializing the software development kit (SDK). - Enabling users to sign up through information channels to and from target browsers. - Implementing user sign-in through a single call between the platform and browser. - Adding user device intake and update functionality to allow for new biometric signifiers. - Enabling session validation (i.e., granular session management) for long-term security. Most teams reach for an SDK or platform rather than the raw WebAuthn API precisely because of this: it collapses several ceremonies’ worth of cryptographic handling into a few function calls. Developers can streamline implementation further with Descope flows (see below), and our [passkeys]() and [FIDO2]() guides go deeper on the underlying mechanics if you want to understand what’s happening under the hood. Some challenges that dev teams and adopters can face when implementing WebAuthn or FIDO2 involve the sheer scope of user, device, and key registration. The process is relatively complex compared to traditional password setups, and a high volume and diversity of users, devices, and accounts can lead to high resource demand. There are also issues with support in legacy-heavy tech stacks, particularly with FIDO2, where migration adds more potential costs for IT teams. Account recovery is another practical concern that teams underestimate early on. A password can be reset by email, but a lost or replaced device means a user has lost the authenticator that held their passkey or credential. Any production rollout needs a documented recovery path, whether that’s a backup authenticator registered in advance, an admin-assisted recovery flow, or a fallback method like a one-time code sent through a separate, already-verified channel. Teams that skip this step tend to find out it’s needed the first time a user shows up with a new phone and no way in. ### How Descope simplifies WebAuthn and FIDO2 integration Descope adds passkeys, WebAuthn, and FIDO2-based login to any app through SDKs and visual flows, so your team doesn’t have to build WebAuthn ceremonies or CTAP handling by hand. [Descope Flows]() let you add these authentication methods with a no-code, drag-and-drop process, selecting the specifications you’d like to implement and placing them directly into your project. ![Biometrics Flow]() [Sign up]() for a Free Forever account with Descope to simplify your auth with WebAuthn, FIDO2, or any other protocol you need. Have questions about our platform? [Book a demo]() with our auth experts. ## Frequently asked questions about WebAuthn and FIDO2 --- ## Customer Stories ### [Collectors Customer Story | Descope](https://www.descope.com/customers/collectors) See how Collectors unified consumer brand login, partner federation, and admin SSO for millions users on one Descope identity orchestration layer. *Full content: [https://www.descope.com/customers/collectors.md](https://www.descope.com/customers/collectors.md)* **[*Collectors*]()*, the parent company of PSA, PCGS, SGC, and Beckett, needed to unify identity across three distinct login scenarios (consumer brand auth, a co-managed partner product, and internal admin access) under a single platform. Their incumbent solution couldn't provide the federation flexibility, JWT customization, or integration depth they required. Learn how Descope gave Collectors' identity team the control and extensibility they needed to consolidate authentication for millions of users across brands and partners.* --- ## About Collectors Collectors is the global leader in third-party grading and certification for collectibles. Its portfolio includes [PSA]() (trading cards, memorabilia, and video games), [PCGS]() (coins and currency), [SGC]() (vintage and pre-war cards), [Beckett]() (grading, price guides, and publications), and [CardLadder]() (analytics).  With over a quarter million monthly active users, 30,000 daily active users, and nearly 8 million machine-to-machine credential exchanges across 5.7 million user records, Collectors operates identity infrastructure at a scale where fragmentation can quickly create UX friction. ## Three login experiences, one identity challenge Collectors' identity requirements were somewhat atypical: the company had three different authentication use cases with different trust models, user populations, and technical constraints. - **Internal admin access** required corporate SSO for employees accessing administrative tools. On its own, this was straightforward [SAML-based SSO](). But running it alongside two other login patterns on a platform that treated each as a separate configuration environment created operational fragmentation for a lean identity team. - **Consumer brand login** served the primary user base across PSA, PCGS, and other Collectors properties. Sub-brands needed to federate to a central, self-hosted authentication page with Collectors' own branding, privacy policies, and footer. The incumbent platform made this federation rigid, and routing users across brands while maintaining consistent session behavior required workarounds that added overhead without adding flexibility. - **A co-managed partner product** introduced a different trust model. Partner users needed to authenticate through the partner's own identity provider via OAuth, with Collectors acting as an intermediary. The incumbent platform had no clean abstraction for this kind of multi-party federation. The core challenge was architectural: Collectors needed an authentication provider that could handle all three use cases within a unified identity model. Dan Van Tran, CTO at Collectors, said: > "Our consumer federation, partner federation, and admin SSO grew up separately, so each one was its own world to maintain. We wanted one unified place to run them without giving up our work on claims and scopes. Descope fit all three experiences into the same auth model, letting us keep the control we’d built.” ## The Descope experience Collectors needed a solution that could replicate the JWT claim patterns and scope controls they'd built previously while extending into areas where their former provider had set limitations. They evaluated alternatives against federation flexibility, JWT template depth, connector-based integration architecture, M2M scope control, and engineering responsiveness. Descope addressed all of these requirements. Collectors rolled out Descope across each of their three use cases: admin SSO, consumer brand authentication, and partner federation. Each use case exercised different parts of Descope's solution, but all three ran through the same flow-based orchestration layer: - The SAML-based admin SSO flow authenticates employees through Collectors' corporate identity provider, applies specific audience info and custom admin scope claim, and completes. Once the redirect model and frontend integration were set up, the team moved quickly to production. - User records were imported from the incumbent alongside Collectors' internal database. During the transition, a [just-in-time (JIT)]() password sync captured credentials as users logged in through the incumbent and wrote them to Descope. These accounts were then ready at cutover without a forced password reset. MFA enrollment data was also preserved from the legacy provider, and Collectors implemented a new MFA pattern: users select their method (SMS OTP or voice call OTP) at registration, stored as a custom attribute and enforced at sign-in through the flow. - Partner users authenticate through the partner's custom identity provider, with Descope acting as the intermediary. The flow initiates an OAuth exchange with the partner's identity provider, then a proxy connector call to Collectors' backend API creates or validates the user, maps custom attributes across both systems, and handles edge cases like suspended user redirects and error audit events. Descope's[ connector]() system ties the identity layer into Collectors' broader infrastructure: [Twilio]() for SMS and voice OTP delivery, Mimecast (via [SMTP connector]()) for transactional email, [AWS S3]() for audit log streaming, [webhook-driven event handling]() for MFA verification, and the proxy API that powers user creation in the partner federation flow. Authentication flows across all three use cases support English, French Canadian, and Japanese. Account lockout emails, OTP messages, and user-facing screens are localized per user locale, extended by Descope's [Google Cloud Translation connector](). The migration also surfaced requirements that drove new platform capabilities, feature requests pushed to production before the migration completed rather than as a future roadmap. Descope shipped PKCE support for custom OAuth providers, public/private key JWT authentication for external identity provider integration, .NET SDK enhancements, JIT session migration support for Okta CIS, and localization changes. Smit Gujarathi, VP of Marketplace Engineering at Collectors, said: > "Partner federation could have been a service we owned and maintained forever. With Descope Flows, it’s a simple matter of configuration. In case we did run into an unexpected requirement, the Descope team built the feature while we were still in the middle of the project. That’s not your typical auth vendor." ## Simplifying the identity surface for six million users Leveraging Descope’s flexible orchestration and federation capabilities, Collectors replaced a fragmented identity stack with a single orchestration layer that handles consumer federation, partner authentication, admin SSO, and millions of monthly M2M exchanges. As they continue enriching their identity experiences with Descope, they plan to add more integrations, introduce [native mobile applications](), and enhance token management.  Dan Van Tran, CTO at Collectors, said: > "Identity used to be three separate engineering efforts for us, and now it's one. What matters most looking ahead is agility: we can add integrations, test different flows, and refine token management without rebuilding the foundations every time we want to try something new." For organizations managing identity across multiple brands, partners, and user populations, Descope provides the flow-based architecture and robust integrations to consolidate without compromising, and without spending months and countless dev cycles to end up with never-ending maintenance. --- Descope is a flexible [customer and agentic platform]() that helps organizations easily add authentication, authorization, and identity management to their apps, AI agents, and MCP servers. Customers use us for initiatives such as [passwordless authentication](), [SSO](), [identity federation](), [strong MFA](), [fraud prevention](), and [agentic identity](). To get started with Descope, [sign up for a Free Forever account](). If you have questions about our platform, [book time with our auth experts](). --- ### [b.well Connected Health Customer Story | Descope](https://www.descope.com/customers/bwell-connected-health) Learn how b.well Connected Health unified machine identity, patient authentication, and outbound SSO onto Descope while keeping their own business logic in-house. *Full content: [https://www.descope.com/customers/bwell-connected-health.md](https://www.descope.com/customers/bwell-connected-health.md)* **[*b.well Connected Health*]()* gives people one place to gather and act on their health data, serving patients directly and through partner platforms. Unifying identity through Descope let b.well meet compliance requirements and adopt new patterns like FHIR scopes for machine access control and outbound SSO. Here’s how Descope helped them keep the same business logic while reducing cost, complexity, and engineering effort associated with high-volume token exchanges.* --- ## About b.well Connected Health b.well is the connective layer between patients and the health data scattered across systems that hold it. The company works with partners including Samsung and Walgreens, and its platform sits behind consumer health experiences announced with OpenAI, Google, and Perplexity. Logan Edwards, Senior Director of Engineering at b.well, said: > “The mission at b.well is to simplify healthcare. We focus on helping people access, manage, and truly own their health data. EMRs don’t talk to each other by default. That’s why we help you see all your health data in one place, with the least friction possible.” Partners can serve b.well to their end customers using two integration patterns: - A partner authenticates its own users and b.well appears seamlessly inside their product, without re-authenticating - b.well builds the end-to-end experience, white-labeled to the partner’s brand ## Why Descope Compliance was the primary driver for seeking an external auth vendor, made more urgent by the growing number of enterprise partners b.well serves. A major customer’s requirements led b.well to seek vendors with native FHIR compliance. The second compelling event was the sheer volume of partner-driven token exchanges, measured in tens of millions per month. On their incumbent provider, the cost of these machine-to-machine transactions began to soar. The team was now working against the clock to find an alternative with friendlier pricing. The final piece came from what b.well themselves were building: a FHIR (Fast Healthcare Interoperability Resources) database that works as a master patient index, resolving the same person across partner ecosystems that would otherwise hold unconnected records for them.  Getting those identifiers into a token uses a pipeline designed by b.well’s engineering team: Lambda triggers, SDK calls, and a gateway service handle the business logic around them. b.well had already solved their FHIR scoping model, so what they needed was an auth provider who could fit neatly into that flow rather than ripping and replacing it. b.well had already solved the identifier enrichment problem, but at a cost: claim customization sat outside what their previous provider offered by default, with their gateway handling the surrounding logic. Logan Edwards, Senior Director of Engineering at b.well, said: > “OAuth and FHIR compliance were obviously top of mind during vendor selection, but so was the ability to customize a user’s claims on their token. That wasn’t out-of-the-box, and we were paying for it. The fact that Descope did that by default and offered even more options definitely impressed.” Beyond OAuth compliance and custom claims on tokens, b.well wanted the ability to leverage plug-and -play components it wouldn’t have to build. If the organization was going to work with an external auth provider, out-of-the-box building blocks Descope provided made the migration more worthwhile. That included features like diverse multi-factor authentication (MFA) options, passkeys, single sign-on (SSO), and easily maintainable flows. ## The Descope experience b.well started their Descope implementation with machine-to-machine (M2M) authentication, aiming to address rising costs and rate limits on their existing system. Logan Edwards, Senior Director of Engineering at b.well, said: > “M2M was the right place to start. We validated that Descope could handle our scaling needs better than what we were on, before anything touched a patient. The migration itself was a non-event, which is exactly what you want.” b.well bases its standards on FHIR and uses FHIR-specific scopes for access control, so moving meant building app clients carrying those same scopes. Their M2M traffic now runs through Descope [Inbound Apps]() on the OAuth Client Credentials flow, with roles and permissions attached. These span their FHIR service, token service, and integration hub. Using the [Descope Terraform provider]() and a [GitHub Actions wrapper](), b.well manages scopes and Inbound Apps in a version-controlled manner alongside the rest of their infrastructure.  Some aspects of their previous solution needed to be rebuilt, but Descope’s dev-friendly tooling made this a light effort. Signup and authentication journeys now run as [Descope Flows]() embedded as web components inside their React and React Native apps, with per-tenant styling and per-partner custom domains. Each white-labeled experience keeps its own look and feel, and end-patients don’t see b.well screens or branding unless the partner chooses to expose it.  Imran Qureshi, Chief Technology Officer and Chief AI Officer at b.well, said: > "Descope flows save us from building auth UI, which can be tricky to make secure. And the [Descope MCP Server]() can edit Flows, so we don't even need to learn the Descope Console. The Descope CI/CD promotion is cool because you can promote Descope changes from dev to staging to prod like code." b.well can now offer auth methods and features with drop-in, out-of-the-box simplicity: passkeys (including Face ID and Touch ID on native), authenticator apps, magic links, per-tenant MFA policy (plus saving user preferences), and self-service SSO. ![b.well login screen]() For their partner-side build, Descope paves the way for easier onboarding. When building for one partner, for example, patients needed to click through the portal to third-party services for cost estimates and similar tasks, which meant outbound federation. b.well knew this was a solved problem, and their engineers’ time was better spent on the core product rather than building this from scratch. b.well built those portal journeys on Descope [Federated Apps](), with Flows handling the assertion binding. The same design balance shows up in b.well’s signup flows, where an [HTTP Connector]() calls back into b.well’s own systems. Descope does the protocol work, and the rules that decide what a patient can see stay where b.well wants them, in their own backend. ## Improving patient access, one login at a time Several capabilities in Descope were spurred on by b.well’s technical requirements: - An Epic electronic health record(EHR) client-assertion function needed RS384 signing where Descope’s default was RS256; Descope swiftly added support and documentation - Descope also added support for JSON objects as custom claims, alongside larger claim payloads - b.well provided valuable input for extending Descope’s delegation mechanisms, which would serve caregivers of patients or those signing in on behalf of dependents b.well Connected Health went looking for an identity provider that could satisfy enterprise compliance needs and bring down the cost of high-volume token exchange. They got both, and along the way, they also added passkeys, fully featured MFA, and outbound SSO their engineers never had to build.  Logan Edwards, Senior Director of Engineering at b.well, said: > “For engineering leaders of organizations in a similar scenario, I’d encourage them to lean into what a vendor offers as their value-add. Compliance and M2M volume were what started our search, but we got so much more by choosing Descope.” While the migration is complete, b.well’s engineering team looks forward to expanding their Descope solution by leveraging features like agentic identity (their platform already boasts an agent-ready SDK) and end-to-end automation. Their team expects automation to deliver the most value, with setting up and managing infrastructure across different customer verticals becoming significantly easier than before. Ross Hosman, Chief Information Security Officer at b.well, said: > "I’d like to thank the Descope team for this winning partnership. They’ve completely changed how our engineering team thinks about and does auth in our applications today." --- Descope is a flexible [customer and agentic platform]() that helps organizations easily add authentication, authorization, and identity management to their apps, AI agents, and MCP servers. Customers use us for initiatives such as [passwordless authentication](), [SSO](), [identity federation](), [strong MFA](), [fraud prevention](), and [agentic identity](). To get started with Descope, [sign up for a Free Forever account](). If you have questions about our platform, [book time with our auth experts](). --- ### [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](https://www.descope.com/customers/elementor.md)* [*Elementor*]()* is the leading WordPress website creation platform, serving web designers, developers, and agencies across the globe. As their customer identity needs grew, their engineering team decided to pursue a managed provider to reduce overhead. Their top requirement: the login experience needed to match the existing Elementor design exactly. Here’s how Descope met that pixel-perfect challenge while delivering flexible, secure authentication.* --- ## About Elementor Elementor is the world’s most popular * *WordPress website creation platform*.* This allows users to design professional, responsive sites visually and in real time, completely eliminating the need to write or understand any code. Elementor users have created over 24 million sites, with more than 13% of the internet using the platform. The no-code editor serves a variety of different user types, from solo developers to marketing agencies. Elementor offers a comprehensive suite of web development services, including hosting, transactional email, image optimization, and accessibility tooling. The creators of Elementor recently introduced [Sticklight](), an AI-powered platform that allows creators to build apps and dashboards using natural language. ## The challenge of a growing user base The authentication at Elementor was working: they had password-based login with [social login]() layered on, and it served their users well. The issue was the overhead that came from owning and maintaining it. A growing user base meant that maintaining authentication infrastructure in-house was drawing engineering attention away from the product the Elementor developers were tasked with building. Elementor sought a vendor not because they needed fundamental improvements to their auth system, but so their engineers could focus on refining their core offering. They wanted an auth provider who could reproduce what they already had while offering all the benefits of a managed solution: less maintenance overhead, a robust connector ecosystem, hands-on support. Crucially, the Elementor platform is sold on the promise of pixel-perfect output, and the authentication screens their users encountered were a meaningful part of that experience. The appearance of every element, from button corners to color values, needed to exactly match their existing design. ## The Descope experience After evaluating their options, Elementor chose Descope for three reasons that mapped directly to their requirements: - [Descope Flows](), which offer flexible low / no-code authentication flow design through a visual, workflow-based editor. - A pricing model finely tuned to accommodate a high-volume B2C company’s growth trajectory rather than one that penalized rapid scaling. Descope shipped several UX-focused capabilities to better serve the requirements set out by Elementor, resolving edge cases and meeting the visual expectations of their design-focused customers. ![Elementor Login Screen]() Gil Lupu, Software Engineering Group Manager at Elementor, said: > “The drag-and-drop design behind Descope Flows was familiar to us because we provide the same concept to our customers. Sharing that core philosophy really made Descope stand out.” ### Building auth without compromising design The early implementation work was heavily focused on design components, with Elementor and Descope closely collaborating to hit the level of granularity desired. Alongside the styling work, the teams worked through architectural questions, like whether Elementor’s multiple apps should be managed as separate Descope projects or consolidated. Descope helped them reason through these technical choices and arrive at a configuration that fit how their products actually relate to each other. While the original in-house auth system had covered passwords and social login, the Descope implementation expanded the options to include [magic links](), [single sign-on (SSO)](), and additional social providers, with [passkeys]() under consideration. Descope Flows became central to how Elementor built and maintained their authentication logic. Rather than treat authentication as a static path, Elementor used Flows to encode substantial business logic. They leverage multiple sign-in and sign-up flows for different clients and use cases, sub-flows that share common logic across them, and an [HTTP connector]() that keeps their internal user database in sync on every sign-in and sign-up event. They also integrate with a variety of Descope’s plug-and-play [Connectors]() ([reCAPTCHA](), [Mixpanel](), [Google Cloud Logging]()) and employ an audit webhook. For scenarios requiring deeper UI control, Elementor uses Descope’s [Bring Your Own Screen (BYOS)]() functionality to render their own user interface while keeping Flows on the back end for authentication logic. Gil Lupu, Software Engineering Group Manager at Elementor, said: > “From the start, the Descope team felt like an extension of our own. They understood what we needed for both auth and design and built alongside us to get there.” ## Auth that grows alongside Elementor's vision The main Elementor app saw great success with its Descope deployment. When the creators of Elementor sought auth for their new product, Sticklight, they once again chose Descope. Sticklight is a separate team from Elementor, offering an AI-powered web design suite with collaboration at its core. Sticklight uses Descope’s multi-tenant architecture to secure the collaboration component: users can create workspaces, add members, and manage permissions across them, with role-based access control (RBAC) applied at the workspace level. ![Sticklight Signin Screen]() Descope’s tenant architecture offers a secure and flexible option that most B2C tenant implementations simply don’t serve. The Sticklight team adopted Descope independently, but they were able to draw from the institutional knowledge the Elementor team had already built. Gil Lupu, Software Engineering Group Manager at Elementor, said: > “We continued to expand how we used Descope for one simple reason: the product does what it promises, and the team behind it actually shows up.” ## Identity delivered with pixel-perfect specifications Authentication is no longer a burden Elementor engineers split their attention to address. The design requirements they sought in their evaluation were delivered by Descope, with new capabilities shipping to meet each need. What emerged from the collaboration between Descope and Elementor is a combination of powerful, flexible auth logic alongside a user-facing design experience that retains the platform’s uncompromised vision. Elementor continues to expand their Descope implementation as their portfolio grows, with new products reaching for Descope based on this impressive foundation. --- Descope is a flexible [customer and agentic platform]() that helps organizations easily add authentication, authorization, and identity management to their apps, AI agents, and MCP servers. Customers use us for initiatives such as [passwordless authentication](), [SSO](), [identity federation](), [strong MFA](), [fraud prevention](), and [agentic identity](). To get started with Descope, [sign up for a Free Forever account](). If you have questions about our platform, [book time with our auth experts](). --- ### [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](https://www.descope.com/customers/token-security.md)* **[*Token Security*]()* is a pioneering cybersecurity company focused on securing agentic AI and non-human identities. Companies trust Token Security to discover and govern each agent and machine credential across all their environments. As the company extended its platform with a customer-facing MCP server, it needed an identity layer that could secure agentic access with the same rigor it provides for its own customers. Here’s how Descope delivered on every requirement.* --- ## About Token Security Token Security provides a comprehensive solution for securing non-human identities (NHIs). With Token Security, organizations can discover, manage, and govern every AI agent, service account, API key, and machine credential across cloud, on-premises, and hybrid environments. The company was named a [Top 10 Finalist for the RSAC 2026 Innovation Sandbox Contest](), recognized for pioneering identity-first security and governance for AI agents. The Token Security platform also includes a Model Context Protocol (MCP) server that lets security teams query their NHI environment in natural language. A security engineer can ask which identities haven’t rotated secrets in 90 days, who owns a given service account, or what the riskiest NHIs are, and get an answer drawn directly from their specific vulnerabilities.  ## The need to secure an agentic AI surface MCP is the open standard that lets AI agents connect to external tools and data (like the data about NHI posture surfaced Token Security). A remote MCP server exposes those tools to clients the operator doesn’t control, which presents three distinct challenges: registering previously unseen clients, authenticating them, and ensuring least-privilege access with granular scoping.  At the same time, Token Security was scaling its enterprise B2B business and wanted one identity platform to govern both the human authentication path and the agentic one. They began evaluating providers with a clear set of parameters: - [Protocol-compliant authorization]() for a remote, customer-facing MCP server - Tool-level access control tied to a user’s existing role and tenant - [B2B authentication]() and [single sign-on (SSO)]() as core capabilities - Tenant-scoped [role-based access control (RBAC)]() that preserved customer semantics - Audit streams that internal systems could subscribe to for downstream automation Itamar Apelblat, Co-Founder and CEO at Token Security, said: > “We secure agentic AI for our customers, so the bar for our own MCP server was high. We needed a layer that treats agents as identities and scopes every tool call to the right user.” ## The Descope experience Descope met the evaluation criteria on every dimension Token Security laid out, across both the agentic and the human authentication paths. The [Agentic Identity Hub]() provided protocol-compliant authorization for the MCP server, while [Descope Flows]() provided a visual, workflow-based identity journey builder that kept login flows out of application code. This meant new auth methods, edge cases, and tenant-specific logic could be introduced without a redeployment.  The [SSO Setup Suite]() offered a self-service wizard that enterprise teams could use to configure SSO and SCIM for their own identity providers. Descope’s migration tooling accommodated the shape of existing Token Security data, including SAML SSO connections with their tenant-specific configurations. The Descope team even engineered bespoke solutions for edge cases presented by the previous system. A single platform now governs how users authenticate to the Token Security product and how their AI clients connect to its MCP server, with the same roles and tenants applied across both.  ### MCP server authorization with the Agentic Identity Hub Descope acts as the OAuth 2.1 authorization server for the Token Security MCP server. The Agentic Identity Hub publishes the discovery metadata MCP clients use to locate the authorization server, hosts the token and authorization endpoints, and handles user authentication and consent.  Because MCP clients connect from AI applications that Token Security doesn’t control, the Agentic Identity Hub supports [Dynamic Client Registration (DCR)]() and [Client ID Metadata Documents (CIMD)](). Metadata tags can be attached at registration that downstream policies use to evaluate access. The access token issued through that client carries the authenticating user, their tenant, and the tool-level scopes granted for the session. The Agentic Identity Hub provides a centralized view of every connected agent, the delegating user, and the tools and scopes they hold.  Itamar Apelblat, Co-Founder and CEO at Token Security, said: > “The same roles and tenants we use for human access now govern what an AI client can do on our MCP server. With Descope, we didn’t have to build a secondary authorization model for agents and hope it stayed consistent with the first.” ### Flexible B2B authentication Token Security built their customer authentication experience using Descope Flows, combining enterprise SSO with TOTP-based [multi-factor authentication (MFA)](), [magic links](), [passkeys](), and [social login]() (Google and Microsoft). The result is an experience that adapts to the identity expectations of each tenant, with the underlying journey served through Flows rather than hardcoded in the application. Role-based access control (RBAC) with tenant-specific definitions ensure enterprise customers retain the access models they’ve already designated for their own organizations, rather than compressing them to fit a vendor’s format. For enterprise tenants, the SSO Setup Suite handles identity provider configuration as a self-service workflow. IdP-initiated login matches the pattern enterprise identity teams expect from their upstream providers, and SCIM provisioning (which had previously taken up to a month for a single customer) is now configured alongside SSO. ## Enterprise-grade auth that scales with growth Descope delivers on the goals that drove Token Security to seek a new identity provider. The MCP server is exposed to customers through protocol-compliant OAuth 2.1, with every agent identified and every tool call scoped to the connecting user’s role and tenant. Enterprise B2B authentication, self-service SSO, SCIM, and tenant-scoped RBAC run on the same platform, using the same access model. For an organization whose core product is agentic and NHI identity security, the choice of authentication provider reaches beyond simple technical scope. Descope gave Token Security an identity layer that matches the high standard of the solution they sell to their own customers. --- Descope is a flexible [customer and agentic platform]() that helps organizations easily add authentication, authorization, and identity management to their apps, AI agents, and MCP servers. Customers use us for initiatives such as [passwordless authentication](), [SSO](), [identity federation](), [strong MFA](), [fraud prevention](), and [agentic identity](). To get started with Descope, [sign up for a Free Forever account](). If you have questions about our platform, [book time with our auth experts](). --- ### [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](https://www.descope.com/customers/octave.md)* **[*Octave*]()* is the agentic go-to-market brain for B2B revenue teams, turning a company’s strategy, ideal customer persona, and messaging into living context that any AI agent, workflow, or tool can weave into its output. Because many of Octave’s customers connect with the product through its MCP server rather than a login screen, the company needed unified authentication regardless of where their users sign in. This is how Descope helped them build it.* --- ## About Octave Octave aims to solve the gap between go-to-market (GTM) strategy and real-world execution. Most GTM knowledge emerges over time, scattered across various decks, docs, and hidden in the heads of individual stakeholders. Octave codifies that knowledge, combining product details, personas, proof points, competitive intelligence, and the unique language that distinguishes a business.  The result is a single source of truth that grounds AI output in real context rather than inference or guesswork. With Octave at their disposal, Large Language Models (LLMS) can reliably support GTM motions without the threat of uncertainty or hallucination. Julian Tempelsman, Co-Founder and CTO at Octave, said: > “There are nuances that don’t fit into any existing system. It’s in this deck over here, that doc over there. We’re codifying those so they’re machine-readable. We want to be the brain that lets all your tools and workflows actually understand your business.” ## Choosing a once-and-done solution As Octave moved upmarket, its authentication needs grew. The company began with a homegrown wrapper built on Google components, which covered Google Workspace sign-ins. However, as customers started asking for Microsoft-based logins, it was clear that demand for more comprehensive [single sign-on (SSO)]() wouldn’t be far behind. For a lean team whose business is GTM context, not customer identity, the build-versus-buy decision was straightforward. Every cycle spent retooling auth flows was one that could’ve been spent refining the core Octave offering. Rather than retrofitting auth every time an [enterprise requirement]() came up in a deal, they sought a solution that meant designing their identity layer once, and only once.  Julian Tempelsman, Co-Founder and CTO at Octave, said: > “Authentication is a solved problem, and it’s not what makes Octave special. We didn’t want to spend our team’s time rebuilding logins whenever a customer asked for a new method. We designed it once, and let Descope handle the rest.” Octave evaluated managed providers and chose Descope for its flexibility, developer experience, [documentation](), and hands-on support. That last point was especially important to Octave; as a company that, in their words, “bear hugs” their own customers, they prized a provider with a similar philosophy. ## The Descope experience With [Descope Flows](), Octave rebuilt auth journeys using a drag-and-drop, visual workflow builder. Octave could tweak and extend this authentication layer without touching application code, significantly reducing development overhead. Descope’s multi-tenant architecture ensures enterprise expectations like data isolation are easy to enforce, with each customer receiving its own logically or physically separate tenant. ![Octave User Auth Screen]() Today, the company uses Descope to support Google Workspace and Microsoft [social logins]() (with custom flow parameters to accept only business email signups) alongside SSO. The migration itself took a couple of weeks, with the Octave team praising Descope’s ability to move a live system with active users onto the new stack without downtime. ### One auth experience for every environment Octave’s [Model Context Protocol (MCP)]() server was a thoughtful extension of the company’s already headless approach. As the team followed the trajectory of Claude and Claude Code, it became clear that users did not want yet another tool to log in to. They wanted the rich context supplied by Octave, delivered where they already worked.  Exposing the product through an MCP server was the smoothest way to achieve this, and because Descope was already handling authentication, the MCP server could use the same sign-in flow. ![Octave MCP Auth Screen]() Julian Tempelsman, Co-Founder and CTO at Octave, said: > “We’re an AI-native, headless product. The majority of our users don’t have to log in to Octave; they connect through our MCP server, which is powered by Descope. Whether someone signs in through the UI or comes in through MCP, the auth runs through Descope Flows.” The [Descope Agentic Identity Hub]() sits in front of the MCP server as the OAuth-compliant authorization layer, handling the spec-mandated elements like [PKCE](), [Dynamic Client Registration (DCR)](), and token issuance. Octave uses DCR with an admin approval step: an unregistered client triggers a request, an admin approves or rejects it, and approved clients connect from then on.  ### Connecting Octave libraries with GTM sources The context provided by Octave is only as good as the data sources it can reach, and those sources span a wide range of GTM apps: CRMs, conversation intelligence, and the many documents, inboxes, and channels where teams actually work. Traditionally, this would require significant upfront work and ongoing maintenance to ensure Octave could query a customer’s data sources with the proper permissions. [Descope Connections]() power outbound integrations with several of Octave’s knowledge sources, including Google Drive, Slack, and Notion. Connections handle the secure storage, token refresh, and access control needed to maintain these connections automatically. This allows Octave to ingest the source material, keep it updated, and return results enriched with real context. No complex integration steps, API keys to secure, or tokens to rotate. ## Enterprise-grade auth that scales with growth The most compelling measure of success, according to Octave, is how little they think about authentication now. SSO infrastructure that would have been a major undertaking on their previous system could be built in about a day. As Octave looks to onboard more customers using enterprise SSO, [SCIM]() and the [SSO Setup Suite]() offer self-service options that take even more maintenance off their team’s hands. Julian Tempelsman, Co-Founder and CTO at Octave, said: > “The best thing I can say about Descope is that we do not have to think about auth. When a customer hears how we handle it, that stops being an objection. And when we do need to extend it, we know it’s easy.” Looking ahead, Octave plans to connect more GTM knowledge sources to further deepen its already rich context. With Descope, Octave can easily ingest scattered data from new channels, send out requests, and create more bidirectional loops. And with identity off their plate, those are priorities the Octave team gets to pursue on their own timeline. --- Descope is a flexible [customer and agentic platform]() that helps organizations easily add authentication, authorization, and identity management to their apps, AI agents, and MCP servers. Customers use us for initiatives such as [passwordless authentication](), [SSO](), [identity federation](), [strong MFA](), [fraud prevention](), and [agentic identity](). To get started with Descope, [sign up for a Free Forever account](). If you have questions about our platform, [book time with our auth experts](). --- ## Press Releases ### [Descope Partners With IDMWORKS for Customer and Agentic Identity](https://www.descope.com/press-release/idmworks-partnership) Partnership pairs Descope's customer and agentic identity platform with IDMWORKS' specialized consulting and managed services to help organizations modernize CIAM. *Full content: [https://www.descope.com/press-release/idmworks-partnership.md](https://www.descope.com/press-release/idmworks-partnership.md)* **Los Altos, CA, September 15, 2026** – [Descope](), a flexible customer and agentic identity platform, today announced a partnership with IDMWORKS, a Top 10 identity and access management (IAM) consultancy. The partnership combines Descope's no / low code identity journeys and agentic identity product innovation with IDMWORKS' deep implementation expertise and established client base to help organizations across North America and beyond adopt frictionless, secure customer and agentic IAM. Descope helps organizations create and manage identity journeys for their customers, partners, AI agents, and MCP servers using visual workflows. Over 1000 organizations like GoFundMe, GoodRx, Databricks, Navan, and Linktree use Descope to enhance customer experience, help prevent account takeover, and ensure secure and scalable adoption of AI agents and MCP servers. Descope has a strong [partner program]() and was recognized on[ CRN's 2025 Stellar Startups]() list in the Security category. IDMWORKS is a leading identity and access management consultancy founded in 2004 with presence across North America, Europe, and Asia. The company has delivered more than 2,500 IAM implementations for clients in healthcare, financial services, manufacturing, and insurance, and maintains deep partnerships across the IAM ecosystem. Under the partnership, IDMWORKS will enhance its customer IAM and agentic identity offerings by providing end-to-end strategic guidance, implementation, integration, and managed services for Descope's platform, in collaboration with the Descope engineering, product, and go-to-market teams. Together, the companies will help clients align identity initiatives with priorities such as digital transformation, CIAM modernization, B2B2X identity management, and secure agentic AI and MCP adoption. "The partnership with IDMWORKS marks an important step in Descope's mission to simplify and secure customer and agentic identity for enterprises," said Rishi Bhargava, Co-Founder at Descope. "IDMWORKS brings two decades of specialized IAM expertise and is always at the forefront of driving modernization for their clients–we’re delighted to help this modernization journey with our developer-friendly platform that enables organizations to embrace agility by designing future-proof identity journeys for customers, partners, and AI agents." “We are excited to welcome a partner-first company like Descope into our global partner network,”** **said Paul Bedi, CEO at IDMWORKS. “We’re committed to helping our clients deliver frictionless identity experiences and securely adopt technologies like agentic AI and MCP. Descope’s platform provides the identity infrastructure to enhance our CIAM services and help drive our clients towards this reality. Their product and technical resources are excellent, and their team is responsive and adaptable to evolving client needs.” ### About Descope Descope is a no / low code customer and agentic identity platform that helps organizations easily create and modify authentication and authorization journeys for customers, partners, AI agents, and MCP servers. Thousands of organizations use Descope to improve customer experience, prevent account takeover, and securely adopt agentic AI and MCP with built-in identity controls. ### About IDMWORKS IDMWORKS is an industry-leading identity and access management (IAM) solutions provider. Since 2004, the company has been dedicated to securing businesses and enabling interactions with their customers, partners, and employees, driving transformative growth. Complex identity challenges are simplified through the team’s vision, expertise, and resilience ensuring strategic outcomes are successful. IDMWORKS' deeply knowledgeable and customer-centric experts have been leading the ever-shifting IAM industry for nearly two decades, positioning the company to deliver cutting-edge cyber security solutions. #### Media Contacts Christine Penwell Offleash for Descope [descope@offleashpr.com]() IDMWORKS Communications press@idmworks.com [www.idmworks.com]() --- ### [Descope Named a Supplier on UK Government's G-Cloud 15 Framework](https://www.descope.com/press-release/g-cloud-15-supplier) UK public sector organizations can now procure Descope's customer and agentic identity platform directly through the framework without running a full tender. *Full content: [https://www.descope.com/press-release/g-cloud-15-supplier.md](https://www.descope.com/press-release/g-cloud-15-supplier.md)* **Los Altos, CA, September 9, 2026** – [Descope](), a flexible customer and agentic identity platform, today announced that its UK entity has been named as a supplier on Government Commercial Agency's (GCA) RM1557.15 G-Cloud 15 framework under Lot 2b: Software as a Service (SaaS). You can view Descope’s listing on the Digital Marketplace [here](). GCA is the UK’s central commercial and procurement organisation, connecting public and private sectors to achieve the best outcomes for the UK and its citizens. GCA uses its commercial expertise to create a simpler procurement experience that redirects valuable resources into essential public services – creating value for the nation.  Being named as a G-Cloud supplier means eligible public sector buyers—central government departments and their arm's length bodies, local authorities, NHS trusts, police and other blue light services, and education institutions—can procure Descope through pre-agreed commercial terms rather than running a full procurement from scratch.  The UK Department for Work and Pensions is among the organizations already using Descope for developer-friendly customer identity that have taken advantage of the flexibility and speed afforded by G-Cloud procurement. Public sector identity requirements in the UK have changed on two fronts. Citizen-facing services are expected to offer the same frictionless and personalized login experience people get from consumer apps, including passkeys and multi-factor authentication that does not depend on perishable factors like SMS. At the same time, departments piloting AI agents and MCP servers are finding that traditional identity models were not built to handle the ephemeral, delegated access these systems require. A recent [Descope survey]() of 400+ identity decision-makers found that while 88% were using or planning to use AI agents, only 37% had progressed past pilots. Most identity systems in production today were built for human users and static service accounts, not for agents that are created dynamically and act on a user's behalf. Descope addresses these challenges with a flexible, developer-friendly customer and agentic identity platform. Thousands of organizations use Descope’s visual workflows and SDKs to build and change authentication and authorization journeys without writing custom code, which helps them better adapt to changing user and market needs. The Descope [Agentic Identity Hub]() is a dedicated identity provider for AI agents that treats AI agents as first-class identities with ephemeral credentials, tool-level access control, and audit logging of every agent action. Capabilities available to UK public sector buyers through G-Cloud 15 include: - **No-code identity flows,** which let teams build and modify login, registration, and step-up authentication journeys visually (including passkeys, MFA, and SSO) without writing or redeploying custom authentication code. - **Enterprise-ready B2B and partner IAM**, which lets teams provide tenant-aware identity experiences (SSO, SCIM, delegated administration, fine-grained access) to other businesses and partners they work with. - **Fraud and account takeover prevention,** which combines device intelligence, risk-based step-up authentication, bot detection, and third-party fraud connectors to protect citizen-facing services. - **Agentic identity management,** which gives every AI agent connecting to an organization's applications, APIs, and MCP servers a dedicated identity, with policy controls governing what each agent is allowed to access. - **Logging and auditing,** which records authentication and agent activity and streams events to third-party SIEM platforms. "Government teams are being asked to modernize citizen and partner login, adopt AI agents, and stay compliant with evolving regulations. Identity is a throughline that runs through all these initiatives," said Guy Rinat, Co-Founder of Descope. "Descope is proud to help organizations like the UK Department of Works and Pensions meet these goals. Being named as a supplier on G-Cloud 15 means UK public sector buyers can deploy our flexible, standards-based identity infrastructure without long procurement cycles." ### About Descope Descope is a flexible  no/low code customer and agentic identity platform enabling organizations to create authentication and authorization journeys for customers, partners, AI agents, and MCP servers. Thousands of organizations use the platform to enhance user experience, prevent account takeover, and securely adopt agentic AI with built-in identity controls. ### About Government Commercial Agency GCA is the UK’s central commercial and procurement organisation, connecting public and private sectors to achieve the best outcomes for the UK and its citizens. GCA uses its commercial expertise to create a simpler procurement experience that redirects valuable resources into essential public services – creating value for the nation.  #### Media Contact Christine Penwell Offleash for Descope descope@offleashpr.com --- ### [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](https://www.descope.com/press-release/cross-app-access-xaa-support.md)* **Los Altos, CA, September 1, 2026** – [Descope](), a leading customer and agentic identity platform, today announced Cross-App Access (XAA) support in its [Agentic Identity Hub](), giving organizations a way to let every enterprise customer govern AI agent access through the identity provider (IdP) they already trust. Descope is among the first identity providers to support both:  - ID-JAG token validation, enabling SSO-like login for any AI agent accessing Descope customers’ MCP servers - ID-JAG token issuance, enabling SSO-like login for Descope customers’ AI agents accessing any MCP server 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. However, many MCP servers use identity anti-patterns that were not designed for autonomous agents.  - Static API keys sit in configuration files and environment variables with no expiration and no tool-level scoping. - Agents borrow the signed-in user's session and inherit every permission that user holds, which greatly increases the blast radius of a single compromised agent. - Authorization is applied at the application level rather than per user, per tenant, per agent, or per tool, leaving agents over-permissioned by default. [2026 research from Gravitee]() found that only 22% of teams treat agents as independent identities, with most relying on shared API keys. [Cross-App Access]() is an open protocol built to standardize how AI agents receive access to another application’s APIs or MCP server. Built on the[ Identity Assertion JWT Authorization Grant]() and adopted as the[ Enterprise-Managed Authorization extension]() to the Model Context Protocol, it replaces static API keys and repeated consent screens with short-lived assertions minted by the identity provider both applications already trust. An agent signed in to one application reaches another application's API or MCP server with no second login. "Every B2B company shipping an MCP server is about to hear the same question from its enterprise customers: can we govern agent access to this MCP server with our own identity provider?" said Rishi Bhargava, Co-Founder of Descope. "Descope’s Cross-App Access support helps customers deploy enterprise-ready MCP servers that can validate assertions coming in from their customers' identity providers and even let tenant admins configure XAA support entirely on their own. This is a huge unlock for any business that has high hopes for their Claude connector or ChatGPT plugin." New Cross-App Access capabilities in the Agentic Identity Hub include: 1. **ID-JAG validation,** which helps B2B companies let their enterprise customers govern agent access through the identity provider they already trust. Organizations can register a trusted issuer for each tenant, accept assertions from Okta, Ping, and other standards-compliant providers, and validate a standard access token at the MCP server without implementing the protocol themselves. 2. **ID-JAG issuance,** which makes Descope the identity provider for the AI agents an organization runs internally. Security teams can grant those agents scoped, short-lived access to any MCP server / API, with policies evaluated on every request instead of being baked into a long-lived credential. 3. **Self-service XAA setup,** which adds Cross-App Access to Descope’s [SSO Setup Suite]() alongside SSO, SCIM, and JIT provisioning. Tenant admins can choose their identity provider, establish trusted issuers, register their AI agents, and map user attributes through a guided flow without any support ticket or manual back-and-forth. 4. **Per-organization scope policies,** which let companies grant different levels of agent access to different enterprise customers on the same MCP server. Policies can be created based on user roles, tenant membership, and claims carried over from the customer's identity provider. 5. **Standards-based token exchange,** which builds on the OAuth 2.1, DCR, CIMD, and consent management support already in the Agentic Identity Hub. Cross-App Access follows the Enterprise-Managed Authorization extension to MCP, using [OAuth 2.0 Token Exchange]() to mint assertions and the[ JWT Bearer grant]() to redeem them. Cross-App Access support builds on the Descope [Agentic Identity Hub](), which handles authentication and access control for hundreds of MCP servers and millions of monthly agentic transactions. Descope, a member of the Agentic AI Foundation (AAIF), was named a Leader in the[ 2025 Frost Radar for Non-Human Identity Solutions](), where Frost & Sullivan analyst Dolores Aleman described Descope as "one of the first vendors to treat AI agents as a first-class identity type." Learn more about Descope’s support for Cross-App Access [in this blog](). ### About Descope Descope is a no / low code customer and agentic identity platform that helps organizations easily create and modify authentication and authorization journeys for customers, partners, AI agents, and MCP servers. Thousands of organizations use Descope to improve customer experience, prevent account takeover, and securely adopt agentic AI and MCP with identity controls built-in. #### Media Contact Christine Penwell Offleash for Descope descope@offleashpr.com --- ### [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](https://www.descope.com/press-release/agentic-identity-hub-2.5.md)* **Los Altos, CA, June 9, 2026** – [Descope](), a leading customer and agentic identity platform, today announced major updates to its Agentic Identity Hub to continue providing MCP developers and AI agent builders with standards-based identity infrastructure for their AI systems. Organizations will now be able to use Descope to manage identities for headless agents, enable scope-based agent access to backend APIs, implement step-up auth flows for sensitive agent actions, and become agent-ready without changing existing user auth systems. Descope also announced its MCP server to let developers use AI agents to run authentication, analytics, and migration operations on their Descope projects. AI agents and MCP servers continue being adopted at a rapid pace, but often by retrofitting human identity patterns that don’t scale to the world of AI agents. Using hard-coded secrets, long-lived API keys, or sharing human credentials with agents prevent production-readiness and lead to insecure deployments that are prone to compromise. According to [GitGuardian](), 28.65 million new hardcoded secrets were added to public GitHub repositories in 2025, a 34% YoY increase. More concerningly, research from [Gravitee]() found that only 22% of teams treat agents as independent identities, with most relying on shared API keys. To become truly agent-ready, organizations need identity paradigms that are purpose-built for AI agents and can interoperate with their existing user authentication systems. “Agentic AI adoption is highlighting the need for a new identity layer,” said Alejandro Leal, Senior Analyst at KuppingerCole. “In the race to deploy AI systems, organizations are employing identity anti-patterns that can’t be governed at scale. Enforcing scoped, delegated access and maintaining identity context across API interactions is critical for secure, sustainable AI growth.” The Descope [Agentic Identity Hub]() is a dedicated identity provider for AI agents and MCP servers built on the principles of ephemeral credentials, delegated access, and strong OAuth / MCP protocol compliance. Organizations like You.com, WisdomAI, Daylight Security, and Octave use the Agentic Identity Hub to securely deploy MCP servers and AI agents with identity controls built-in. Capabilities announced today include: - **Enhanced access policies, **which help teams create granular authorization rules to ensure least privilege access for AI agents accessing MCP servers or backend APIs. Organizations can protect their APIs and MCP servers as resources within Descope, with secure OAuth Token Exchange flows governing delegated access with clear attribution and audits for agents accessing these resources. - **Support for autonomous agents, **which lets non-interactive agents without delegating users securely authenticate themselves and receive scoped, policy-backed access to resources. - **Support for human-in-the-loop flows, **which enables step-up authentication for sensitive agent actions. Using the Client-Initiated Backchannel Authentication (CIBA) flow, users can provide out-of-band approval (emails, push notifications) to grant agents time-bound tokens to perform tasks requiring elevated scopes. - **Standalone MCP auth, **which lets organizations use Descope for MCP auth and consent without changing their existing homegrown or third-party user authentication systems. - The **Descope MCP server**, which lets developers use AI agents and LLMs to run authentication, management, and analytics operations on their Descope projects. “Every organization is thinking about agent-readiness with identity as an infrastructure-level concern,” said Slavik Markovich, Co-Founder and CEO of Descope. “The Agentic Identity Hub already powers auth for hundreds of MCP servers and millions of agentic transactions. Today’s newly announced capabilities help even more organizations become agent-ready–whether by securely exposing their product APIs to AI agents, adding MCP auth without changing existing user stores, or bringing autonomous agents out of the ‘fog of war’ with full identity lifecycle management.” "By unifying our user and MCP identity under Descope, we have an identity system that aligns with the unique security and experience needs of businesses, individuals, and AI agents," said Saurabh Sharma, CPO at You.com. “Our MCP server is protected by OAuth 2.1 with secure client registration and token management–all without rewiring our backend APIs.” ### Resources - AI Launch Week: [https://www.descope.com/launch-week/june-2026]() - Website: [https://www.descope.com/use-cases/ai]() - Demo site: [https://descope.ai]() ### About Descope Descope is a no / low code customer and agentic identity platform that helps organizations easily create and modify authentication and authorization journeys for customers, partners, AI agents, and MCP servers. Thousands of organizations use Descope to improve customer experience, prevent account takeover, and securely adopt agentic AI and MCP with identity controls built-in. #### Media Contact Erica Anderson Offleash for Descope [descope@offleashpr.com]() --- ### [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](https://www.descope.com/press-release/connectors.md)* **LOS ALTOS, California – August 29, 2023 –** [Descope](), the drag-and-drop authentication platform for developers, today announced the availability of third-party connectors that enable app developers to create and customize entire user journeys using no-code tools. Available connectors include Google reCAPTCHA Enterprise, Traceable, Segment, HubSpot, Amazon Rekognition, Google Cloud Translation, Amazon Translate, SendGrid, Datadog, Twilio, and Amazon S3. Customers can add data and actions from connectors to their user journey flows for use cases such as risk-based authentication, bot mitigation, localization, identity verification, and identity orchestration. Descope helps developers add authentication and identity management capabilities to their apps without any custom coding. Descope’s no / low code workflows, SDKs, and APIs abstract away the complexity of authentication so that apps can get to market faster and safer than before. Connectors will extend Descope’s capabilities by allowing customers to weave third-party actions and custom app logic into their user journey flows in a few clicks. Use cases for Connectors include: - Mitigating bot attacks and digital fraud based on user risk scores from services such as [Google reCAPTCHA Enterprise]() and Traceable. - Creating user waitlists for apps in beta by using generic HTTP connectors with tools such as [Airtable](). - Localizing user-facing screens in 100+ languages using translation services such as [Google Cloud Translation]() and [Amazon Translate](). - Adding facial recognition and identity verification controls using services such as [Amazon Rekognition](). - Disseminating user identity traits to downstream CDP and CRM solutions such as Segment and HubSpot. - Sending user journey emails with owned email servers (SMTP) or by integrating with solutions such as SendGrid. > “Identity touches everything in a business. It’s vital for Descope to integrate strongly with other products to help our customers better safeguard and manage their users’ identities,” said Slavik Markovich, Co-Founder and CEO of Descope. “The power of connectors will allow developers to easily harmonize actions across their entire tool stack and ensure that end users get the best possible experience. We are especially excited with the fraud prevention integrations that can get granular risk scores from services like Google reCAPTCHA Enterprise and Traceable, helping developers implement seamless MFA for risky sessions.” ### Identity fraud prevention with Descope connectors Organizations are constantly under attack from adversaries looking to compromise user identities to get a foothold in their systems. The [2023 Verizon DBIR]() found that 86% of all basic web app attacks involved the use of stolen credentials. Bots accounted for around [half of all Internet traffic in 2022]() according to Imperva. Descope’s Connectors with Google reCAPTCHA Enterprise and Traceable help customers better protect against online fraud with minimal setup or configuration. [reCAPTCHA Enterprise]() employs advanced machine learning algorithms to analyze user behavior and assess risk levels in real time. Joint customers can ingest these risk scores into their Descope authentication flows to perform risk-specific actions (e.g. MFA, block login, enable biometrics, allow login). Descope can also leverage intelligence from reCAPTCHA Enterprise account defender to help respond to subtle site-specific abuse. Traceable’s [Digital Fraud Prevention]() employs a combination of API security measures, behavioral analytics, and advanced graph machine learning to protect against fraudulent activities across APIs and digital interfaces. Joint customers can combine Traceable’s risk intelligence with the drag-and-drop authentication capabilities of Descope to create branching user paths based on their identified risk level. > “Traceable’s approach to digital fraud prevention is dynamic and adaptive, continuously learning and evolving from each API interaction,” said Jyoti Bansal, CEO and Co-Founder of Traceable. “Our integration with Descope enables customers to apply this deep fraud intelligence at the most important part of the user journey – signup and login. Stopping bad actors at the gate can prevent millions in breach costs and lost revenue while also greatly improving the experience for real app users.” ### Resources - [Blog]() on the Google reCAPTCHA Enterprise connector. - [Video]() on the Google reCAPTCHA Enterprise connector. - [Explore Descope connectors](). - [Sign up]() for a Free Forever Descope account. - [Descope documentation](). - [Descope community](). ### About Descope Descope is a drag-and-drop customer authentication and identity management platform. Our no / low code CIAM solution enables developers to easily create and customize their entire user journey using visual workflows – from authentication and authorization to MFA and SCIM provisioning. Founded in 2022, Descope is backed by Lightspeed and GGV and is a member of the FIDO Alliance. #### Media Contact Erica Anderson Offleash for Descope descope@offleashpr.com ---