# 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 ### [What Is an Authenticator App & How Does It Work](https://www.descope.com/learn/post/authenticator-app) *Full content: [https://www.descope.com/learn/post/authenticator-app.md](https://www.descope.com/learn/post/authenticator-app.md)* An authenticator app is a mobile app that generates short, time-based one-time passcodes you enter as a second step at login, on top of your password. The codes are created on your device from a shared secret set up when you link an account, refresh every 30 to 60 seconds, and are never sent over the network, so there’s nothing for an attacker to intercept. As digital interactions grow and cyberattacks become more sophisticated, protecting customer accounts has never been more critical. Organizations are looking for security measures that strengthen defenses without driving users away. Authenticator apps have quickly become a go-to solution for this balance. They help businesses keep accounts secure, meet compliance expectations, and build trust, all while keeping login flows simple and familiar. This guide examines the role of authenticator apps in a modern [authentication]() strategy, how an authenticator works under the hood, the best options available today, and how they can facilitate secure and scalable customer experiences. ## At a glance - An authenticator app is a mobile app that generates short, time based one time passcodes used as a second step when you log in, on top of your password. - The codes are created on your device from a shared secret set up when you link an account, and they refresh every 30 to 60 seconds, so there is nothing for an attacker to intercept over the network. - Popular authenticator apps include Google Authenticator, Microsoft Authenticator, Authy, Duo Mobile, and 1Password. - Authenticator app codes are more secure than one time codes sent over SMS, which can be intercepted or redirected through SIM swap attacks. - Setting one up takes a minute: install the app, open the security settings of the account you want to protect, and scan the QR code it shows you. ## Quick facts | **What an authenticator app is** | A mobile app that generates time-based one-time passcodes (TOTP) as a second login factor. | | **What it protects** | Accounts and sensitive actions, even if a password has been stolen or guessed. | | **How the codes are generated** | Locally on the device, from a shared secret and the current time, using open standards like RFC 6238. | | **How it compares to SMS** | More secure: codes never travel over the network, so they can’t be intercepted or redirected through a SIM swap. | | **Key outcome** | Far fewer successful account takeovers, with minimal added friction for legitimate users. | ## What is an authenticator app? An authenticator app is a software-based tool that generates [time-based one-time passwords (TOTP)]() to verify a user’s identity during login or sensitive actions. By adding this second layer of verification, organizations can make it significantly harder for attackers to gain unauthorized access even if usernames and passwords are compromised. For organizations, authenticator apps deliver low-cost, high-impact security that integrates relatively easily with their identity and access management (IAM) flows. Built on open standards like [RFC 6238]() (TOTP) and [RFC 4226]() (HOTP), they work smoothly across mobile and desktop devices, reducing friction for users and developers alike. Popular examples of authenticator apps include Google Authenticator, Microsoft Authenticator, Authy, Duo Mobile, 1Password, and 2FAS. ![Fig: Screenshots of Google Authenticator with TOTP codes (Source: Vox)]() ## How authenticator apps work Authenticator apps rely on a shared secret—a unique cryptographic key—established between the app and your server during setup. Using this key and the current timestamp, the app generates a short TOTP, typically valid for 30 to 90 seconds. When a user attempts to log in, they are prompted to enter the code displayed in the authenticator app. The server independently generates its own TOTP using the same shared secret and verifies that the two match. If they do, the authentication step succeeds. ![Fig: TOTP uses time as the moving factor]() Here’s a step-by-step overview of how these apps work: 1. **Setup:** During initial setup, the user links their account with the authenticator app. This is typically done by scanning a QR code or manually entering a secret key provided by the service. This process securely establishes a shared secret between the app and the server. 2. **Shared secret:** The app securely stores this unique secret on the user’s device, while the server stores a matching reference. Each secret is unique to that specific user and account. 3. **Code generation:** Using the shared secret and the current timestamp, the app generates a short, numeric code (usually 6-8 digits) at fixed intervals, often every 30 seconds. 4. **Code presentation:** The app displays the active code to the user, refreshing it automatically with each time window to maintain uniqueness and security. 5. **Verification:** When the user logs in, they enter the current code displayed in their app. 6. **Code validation:** The server generates its own code using the same algorithm and shared secret. 7. **Code matching:** The server compares its generated code against the one the user submitted, and grants access only if they match. 8. **Code expiration:** Each code expires after its short validity period. For subsequent logins, a fresh code must be used. ## Best authenticator apps for two-factor authentication The apps below cover the most common needs, from simple personal use to enterprise workforce deployments. This is informational content to help readers pick a consumer app. Descope isn’t a consumer authenticator app itself; it’s the platform teams use to add authenticator app support to their own products, covered later in this guide. | **App** | **Platforms** | **Cloud backup and multi-device** | **Best for** | **Cost** | | --- | --- | --- | --- | --- | | Google Authenticator | iOS, Android | Optional backup to a Google Account, syncs across devices | Simplicity and broad familiarity | Free | | Microsoft Authenticator | iOS, Android | Cloud backup tied to a Microsoft account; also serves as a passkey provider | Microsoft and Entra accounts, push approvals | Free | | Authy | iOS, Android (desktop app discontinued in 2024) | Encrypted cloud backup protected by a separate backup password, syncs across mobile devices | Multi-device use with a stronger backup model than Google Authenticator | Free | | Duo Mobile | iOS, Android | Backup varies by organization policy; push-based approvals | Workforce and enterprise deployments | Free for individuals; organizations pay for Cisco Duo | | 1Password | iOS, Android, Windows, macOS, Linux, browser extensions | Syncs through the user’s 1Password vault | Combining password management with built-in one-time codes | Paid subscription, no free tier | | 2FAS | iOS, Android | Optional backup to iCloud or Google Drive, or manual file export | Open-source, privacy-focused use | Free | A few things worth knowing beyond the table: - Authy’s desktop app was discontinued in 2024, so it’s mobile-only now. - Microsoft Authenticator’s password autofill feature was retired in 2025, in favor of Edge. - 1Password has no free tier, it’s priced as part of a broader password manager subscription rather than sold as a dedicated authenticator. ## Benefits of authenticator apps Authenticator apps have become a popular choice for organizations securing customer accounts because they strike a balance between strong security and a familiar, low-friction experience. Here are some of the core benefits of authenticator apps: ### Increases security Authenticator apps make it far harder for attackers to exploit stolen credentials. Even if usernames and passwords are compromised, the account stays protected unless the attacker also has access to the device holding the shared secret. This significantly reduces the risks associated with [phishing](), [credential stuffing](), and [account takeover]() attempts. ### Works offline Authenticator apps work even when users are offline, making them ideal for use in areas with poor internet connectivity or when travelling. ### Improves user experience Because authenticator apps generate codes locally on the user’s device, there’s no need for network coverage, text messages, or emails. This creates a smoother, more reliable authentication process that doesn’t frustrate users or add unnecessary friction. ### Scales across platforms and devices Based on open TOTP standards, authenticator apps work on both iOS and Android, and integrate easily with web, mobile, and API-driven applications. This makes it easy to deliver consistent [multi-factor authentication (MFA)]() experiences to millions of users globally. ## Drawbacks of authenticator apps While authenticator apps provide significant benefits due to their [passwordless]() nature, they also have some drawbacks. Here are a few to consider: ### Device dependency If a customer loses, resets, or upgrades their phone without transferring their authenticator app, they may be locked out of their account. Recovery can be complex and frustrating, increasing the likelihood of support tickets and negative user experiences. ### Recovery processes can be cumbersome Account recovery often requires identity verification steps that are perceived as intrusive or time-consuming by customers. This can lead to churn if users perceive the process as too difficult or slow compared to competitors offering simpler solutions. ### Adds friction to login flows Authenticator apps introduce extra steps in the login process. Customers need to open the app, find the right account, and manually enter a code within a short time window. This friction can lead to login abandonment, especially for users who value speed and convenience. ### Still vulnerable to social engineering attacks Although authenticator apps protect against stolen passwords, they don’t eliminate risks from social engineering. Bad actors can still trick customers into sharing their time-based codes, leading to account takeovers despite MFA being in place. ## Should you add an authenticator app to your authentication flow? If you're building a product rather than picking an app for personal use, the question shifts: should your login flow support authenticator apps as a second factor at all? They aren't the right fit for every user journey, but they deliver a strong balance of security and usability in specific industries, scenarios, and high-risk actions. Here are some situations where integrating an authenticator app makes sense: ### Industries handling sensitive data - **Financial services:** [Banks](), investment platforms, and payment providers use authenticator apps to protect against account takeovers and fraud. - [**Healthcare**](): Patient portals and telehealth apps benefit from stronger MFA to safeguard sensitive medical records and maintain HIPAA compliance. - [**Enterprise SaaS**](): Platforms serving corporate users often require stronger MFA to secure proprietary data and maintain trust with business clients. ### High-risk actions and transactions - **Large financial transfers:** Requiring a one-time code for wire transfers or large withdrawals adds a critical verification step. - **Viewing sensitive customer data:** [Step-up authentication]() can prompt for additional security before displaying high-risk data like physical addresses and payment methods. - **Password resets or account recovery:** Using an authenticator app helps confirm user identity before modifying login credentials. - **Device or location changes:** If a user signs in from a new device, browser, or region, triggering an app-based code provides extra protection against unauthorized access. ### Regulatory and compliance needs - **Industries bound by security standards:** Sectors like finance (PCI DSS), healthcare (HIPAA), and government services often integrate authenticator apps to meet regulatory requirements for strong customer authentication. ### Users with higher risk profiles - **Admins and privileged accounts:** System admins, developers, or executives often get app-based MFA to protect sensitive systems and prevent breaches. - **Customers with high-value accounts:** [Ecommerce]() platforms or marketplaces with significant stored value or loyalty balances often encourage these users to enable authenticator apps. ## Add an authenticator app to your flow with Descope Descope isn’t a consumer authenticator app; it’s the platform teams use to [add TOTP authentication to your app](), along with passwordless and adaptive methods, through drag-and-drop workflows, SDKs, or APIs, no deep security expertise required. Our [CIAM platform]() abstracts away the complexity of authentication while keeping it frictionless and secure, so your team can focus on building and scaling your core product. [Sign up]() for a Free Forever account, or [book a demo]() to see how Descope can support your authentication strategy. ![TOTP Flow]() ## Frequently asked questions about authenticator apps --- ### [What Is FIDO2 & How Does FIDO Authentication Work?](https://www.descope.com/learn/post/fido2) *Full content: [https://www.descope.com/learn/post/fido2.md](https://www.descope.com/learn/post/fido2.md)* FIDO2 is an open authentication standard from the FIDO Alliance and the W3C that replaces passwords with passkeys or security keys secured by public key cryptography. Instead of typing a password, users log in with a fingerprint, a face scan, a PIN, or a hardware key, and the standard works across most modern browsers, operating systems, and devices. In 2023, [47% of online shoppers abandoned their cart because they forgot a password](), and 60% gave up accessing an app altogether for the same reason. With passwords creating this much friction, and remaining a constant target for attackers, FIDO2 passwordless authentication has become the leading answer. In this guide, we’ll break down what FIDO2 is, how does FIDO2 work, how it differs from FIDO, U2F, and UAF, and how it enables passwordless authentication across your apps. ## At a glance - FIDO2 is an open authentication standard that lets users sign in with passkeys or security keys instead of passwords, using public key cryptography. - It is made up of two parts: the WebAuthn API, which the browser and app use, and the Client to Authenticator Protocol, or CTAP, which connects the device to an external authenticator. - Because the private key never leaves the user's device and no shared secret is sent to the server, FIDO2 login cannot be phished, guessed, or reused. - FIDO is the broader family of standards from the FIDO Alliance. FIDO2 is the current generation and replaces the earlier U2F and UAF standards. - FIDO2 works with both platform authenticators such as Face ID and Windows Hello, and roaming authenticators such as a YubiKey, so a hardware key is an option but not a requirement. ## Quick facts | **What FIDO2 is** | An open standard for passwordless, public-key based authentication | | **Who created it** | The FIDO Alliance, in collaboration with the W3C | | **What it replaces** | Password-only logins, and the earlier U2F and UAF standards | | **Its two components** | WebAuthn and CTAP | | **Key outcome** | Phishing-resistant login with no shared secrets to steal | ## What is FIDO2? FIDO2 is an open authentication standard that enables users to log into desktop or mobile applications without using passwords. FIDO2 was developed by the [FIDO (Fast Identity Online) Alliance](), an open industry consortium of tech companies formed in 2013 with the mission to develop and promote [passwordless authentication]() standards and protocols. Instead of passwords, FIDO authentication uses registered devices or FIDO2 security keys to validate user identities. FIDO2 consists of two components: - **The Web Authentication API** ([WebAuthn]()), which enables applications to authenticate users with possession-based and [biometric authentication](). - **The Client to Authenticator Protocol** (CTAP), which enables the client to communicate with a roaming authenticator, such as a hardware security key or a smartphone. By combining these components, FIDO2 provides a more secure and user-friendly authentication experience, reducing the reliance on passwords that are often susceptible to various security threats like [phishing]() and [credential stuffing]() attacks. FIDO2 is supported by 95% of global user devices, making it a standard for modern, secure authentication. ![Fig: FIDO2 components]() ## What is a FIDO authenticator? A [FIDO authenticator]() is a software component or a piece of hardware possessed by the user that is capable of performing FIDO authentication. FIDO authenticators are used to verify possession and/or confirm user identity. They are also responsible for generating keypairs during user registration, protecting private key details, and signing digital certificates for attestation. There are two types of FIDO authenticators: roaming authenticators and platform authenticators. Which one a user ends up relying on usually comes down to their device and the app’s configuration rather than a deliberate choice, since most operating systems default to whichever platform authenticator is already built in. ### Roaming authenticator A roaming authenticator is a device separate from the client device that can perform FIDO authentication. Roaming authenticators connect with client devices over USB, Near-field communication (NFC), or Bluetooth. These authenticators enable users to carry their credentials and use them to authenticate on multiple devices. For this reason, roaming authenticators are also referred to as cross-platform authenticators. **Examples:** Tapping a USB security key, authenticating using a smartphone when logging in from a laptop ### Platform authenticator A platform authenticator is built into the user device that acts as the FIDO client. Common implementations of platform authenticators include some form of user biometric authentication backed by hardware chips (e.g. Trusted Platform Module, Trusted Execution Environment) that protect cryptographic keys. When a user authenticates using the same device they are logging in from, platform authenticators are at work. **Examples:** Apple Touch ID, Apple Face ID, Windows Hello ## How FIDO2 works So, how does FIDO2 work in practice? The goal of FIDO authentication is to shift from “legacy, knowledge-based credentialing” to “modern, possession-based credentialing.” The standard relies on public-key cryptography to achieve this. By using a private-public keypair where the private key never leaves the user’s device, FIDO authentication removes the need for shared secrets between a client and a server. The FIDO2 authentication flow breaks down into two parts: registering a new credential, and then using that credential to log in. **Here’s how FIDO registration works:** ![Fig: How FIDO registration works]() - **Step 1:** During account registration, the user is prompted to choose a FIDO authentication mechanism supported by the application (also called the relying party). - **Step 2:** The user approves the FIDO authenticator by performing an action that depends on the authenticator. Common actions include touching a [fingerprint reader](), touching a security key, entering a PIN, or other approved [authentication methods](). - **Step 3:** A public-private keypair is created that is unique to the user’s device, the user’s account, and the application. - **Step 4:** The public key is sent to the application and associated with the user’s account. The private key never leaves the user’s device. **Here’s how login using FIDO works:** ![Fig: How FIDO login works]() - **Step 1:** During login, the application requires the user to log in with the FIDO authenticator used during registration. - **Step 2:** The user unlocks the authenticator using the same action that they performed during the registration process. - **Step 3:** The device looks up the private key based on the ID provided by the application. It signs the request and sends it back to the application. - **Step 4:** The application verifies the signed request with the stored public key. The user is logged in. > **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. ## How FIDO2 enables passwordless authentication FIDO2 is the technical foundation underneath most modern [passkeys](). When an app says it supports passkeys, it’s really relying on the FIDO2 standard (WebAuthn plus CTAP) to generate and verify the public-private keypair behind the scenes. That’s how FIDO2 is used for passwordless authentication in practice: a user registers once with a platform or roaming authenticator, and from then on, every login is a FIDO2 challenge-response exchange instead of a password check. There’s no password to phish, reset, or leak in a breach, and the user experience collapses down to a fingerprint tap or a face scan. FIDO2 passwordless authentication has become the default recommendation for teams trying to cut both account takeover risk and login friction at the same time. Many platform authenticators also sync FIDO2 credentials through the operating system’s own cloud account (iCloud Keychain, Google Password Manager, or Windows Hello), so a passkey created on one device is usable on another without repeating the whole registration step. Roaming authenticators like a USB security key don’t rely on this syncing at all, since the private key already lives on portable hardware the user can carry between devices. Either way, the app never has to store or manage anything resembling a password. ## FIDO vs FIDO2: what is the difference? FIDO isn’t a standard, it’s the alliance and the family of specifications it maintains. FIDO2 is simply the newest and broadest member of that family. | **Standard** | **What it is** | **Status** | | --- | --- | --- | | UAF | FIDO’s original passwordless standard, using on-device authentication | Superseded by FIDO2 | | U2F | FIDO’s original second-factor standard, paired with a password | Renamed CTAP1, still used inside FIDO2 | | FIDO2 | WebAuthn + CTAP, combining and extending UAF and U2F | Current standard | So what is the difference between FIDO and FIDO2? FIDO is the umbrella organization and its broader mission; FIDO2 is the specific, current-generation standard that most passkey and security-key logins run on today. And whether you’re asking how does FIDO work or how does FIDO2 work, the underlying answer is the same: public-key cryptography, a device-bound private key, and no shared secret for a server to lose. ## FIDO2 vs U2F vs UAF FIDO2, U2F (Universal 2nd Factor), and UAF (Universal Authentication Framework) are all authentication standards developed by the FIDO Alliance, but they serve different purposes and have some key differences: FIDO2 is the latest of these standards, combining the best features of U2F and UAF while expanding the scope to cover passwordless authentication end to end. Let’s cover the basics of FIDO UAF and FIDO U2F to understand their differences. ### Universal Authentication Framework (UAF) FIDO Universal Authentication Framework (UAF) is an earlier version of FIDO’s open standards that provides passwordless authentication. FIDO UAF enables online applications to use native security features on end-user computing devices (like mobile devices and laptops) to perform strong authentication and reduce the reliance on passwords. FIDO2 is broadly seen as the successor to FIDO UAF. ### Universal Second Factor (U2F) FIDO Universal Second Factor (U2F) is the first FIDO open standard, focused on providing [two-factor authentication](). FIDO U2F enables applications to supplement the security of their existing password infrastructure by adding a strong second factor of authentication. U2F defines how to establish communications between FIDO2-enabled browsers / operating systems and a FIDO U2F device (like a YubiKey) to implement [multi-factor authentication](). After the release of FIDO2, U2F was renamed and is now known as CTAP1. | | **FIDO2** | **U2F** | **UAF** | | --- | --- | --- | --- | | Primary Focus | Full passwordless authentication | Strong second factor for 2FA | Passwordless authentication | | Authentication Methods | Biometrics, external security keys | External security keys | Biometrics, local authentication | | Platform Support | Widely supported across platforms, browsers, and devices | Initially focused on 2FA, now supported in various platforms | Varied support, may be limited compared to FIDO2 | | Biometric Data Handling | Stored and processed locally on user’s device | N/A | Stored and processed locally on user’s device | | Use Case | Full authentication solution for various scenarios | Strong second factor in two-factor authentication | Passwordless authentication, though less widely adopted | ## Benefits of FIDO authentication FIDO authentication provides a secure, private, convenient, and scalable way for users to access applications without using passwords. ### Security **FIDO2 is more secure than traditional** [**password-based authentication**]() **methods.** Since FIDO authentication doesn’t use shared secrets like passwords, no sensitive user information is stored on application servers. This reduces the attack surface and makes applications less attractive targets for attackers. Removing passwords also prevents bad behaviors like reusing passwords across online accounts and using boilerplate passwords. This in turn stops identity attacks like credential stuffing, phishing, and [account takeover](). The [2025 State of Customer Identity]() report from Descope found that 72% of organizations had already deployed passkeys or were planning to in the next two years, highlighting how organizations are beginning to follow through on the security promise of passkeys.  ### Convenience **FIDO2 provides a more user-friendly experience and simplified login process.** With FIDO authentication, users don’t have to create and remember passwords, use password managers, or go through cumbersome password reset flows. Instead, users authenticate using built-in device capabilities like fingerprint readers or [face scans](), or by leveraging easy-to-use FIDO security keys. FIDO authentication is also convenient for application builders. Developers no longer have to spend time on managing password infrastructure and can instead focus on building core application capabilities. IT teams save time on password-based help desk requests. Product teams prevent user friction and churn caused due to forgotten passwords. ### User privacy **FIDO2 results in safer, decentralized storage of biometric data.** The use of fingerprint or other biometric authentication methods often raises concerns about user privacy. However, privacy is one of the cornerstones of FIDO authentication. The biometric data used in FIDO authentication is securely stored on the user’s device and not transmitted to any external servers. Moreover, since FIDO key pairs are unique for each application, cybercriminals cannot use them to access other services. ### Interoperability **FIDO2 is interoperable across various platforms, devices, and web browsers.** It’s an open and license-free standard that is meant to be used as widely as possible while also maintaining high security. Any FIDO-certified service undergoes rigorous [testing]() to ensure that clients, servers, and authenticators are all compatible. Websites can enable FIDO2 with a JavaScript API call that is widely supported across major browsers and platforms, as well as billions of user devices. ## FIDO2 implementation considerations While FIDO2 authentication brings significant advantages, it’s important to consider some potential challenges associated with its implementation. None of these are dealbreakers on their own, but they do shape how quickly an organization can roll FIDO2 out and how much support users will need along the way: - **Initial setup complexity:** The initial setup process for FIDO2, involving the registration of devices and keys, can be more complex compared to traditional password setup. Users may need assistance or guidance during the setup phase. Organizations implementing FIDO authentication need to invest in user education and awareness programs to ensure smooth adoption and understanding. - **Cost of hardware tokens:** While some authentication methods within FIDO2 are cost-effective (such as biometrics), external hardware tokens can incur additional costs. This may be a consideration for organizations implementing FIDO2 at scale, especially for their employees and other non-customer stakeholders. This is also why FIDO2 doesn’t require a hardware security key: platform authenticators like Touch ID and Windows Hello let most users skip that cost entirely. - **Limited support in legacy systems:** Legacy systems and applications that rely on traditional password-based authentication may not readily support FIDO2. Migration to FIDO2 might require updates or modifications to existing systems, which can be a challenge for organizations with a large legacy infrastructure. ## Drag & drop FIDO authentication with Descope FIDO2 paves the way to a passwordless future, blending strong security with user convenience, but adding FIDO authentication to your app can be complex to build from scratch. Descope lets you add [FIDO-certified biometric authentication]() with drag-and-drop workflows, SDKs, and APIs, and federates with your existing IdP so you can add passkeys to [Auth0](), [Amazon Cognito](), or [Firebase]() without ripping out what you already have.  [Sign up for a Free Forever account]() to add FIDO2 to your app in a few lines of code, or [book time with our auth experts]() if you have questions. ![Biometrics Flow]() ## Frequently asked questions about FIDO2 --- ### [What Is Authentication? Types, Methods & Best Practices](https://www.descope.com/learn/post/authentication) *Full content: [https://www.descope.com/learn/post/authentication.md](https://www.descope.com/learn/post/authentication.md)* Authentication is the process of validating that a user, device, or service is who or what it claims to be before granting access to an application or resource. It works by checking one or more factors: something you know, like a password; something you have, like a phone or security key; or something you are, like a fingerprint or face scan. For organizations, getting this right is about more than a login screen. The right authentication strategy shields sensitive data, stops account takeovers, and holds up smoothly at scale, even as credentials continue to flood the dark web. This guide unpacks what authentication is, how it works, the main authentication types and protocols in use today, and how to choose the right approach for your application. #### Main points - **The cornerstone of digital security:** Authentication serves as the first and most critical defense against cyber threats and data breaches, which means it’s constantly under attack. - **Passwords on the way out:** While traditional credentials remain common, businesses are rapidly adopting passwordless solutions for better security and user experience. - **Implementation determines success:** The right authentication approach balances strong security with a smooth user experience, requiring careful planning for your specific use case. ## At a glance - Authentication is the process of verifying that a user, device, or service is who or what it claims to be before granting access to an application or resource. - It works by checking one or more factors: something you know such as a password, something you have such as a phone or security key, and something you are such as a fingerprint or face scan. - Common methods include password-based login, token-based authentication, certificate-based authentication, multi-factor authentication, passwordless authentication, adaptive authentication, and biometric authentication. - In 2026, the strongest patterns are passwordless and phishing-resistant login with passkeys, plus adaptive multi-factor authentication that steps up only when risk is high. - Choosing the right approach depends on your users, your risk profile, your compliance needs, and whether you also need to authenticate machines and AI agents, not only people. ## Quick facts | **What authentication is** | The process of verifying that a user, device, or service is who or what it claims to be before granting access. | | **Who needs it** | Any application, system, or service that has to distinguish legitimate users from everyone else, from consumer apps to enterprise systems to machine-to-machine communication. | | **How it differs from authorization** | Authentication confirms identity (“who are you?”); authorization determines permissions (“what are you allowed to do?”). | | **Core factors** | Knowledge (something you know), possession (something you have), and inherence (something you are). | | **Key outcome** | Blocked account takeovers, reduced fraud, and access decisions that hold up under audit, without adding unnecessary friction for legitimate users. | ## What is authentication? Authentication is how digital systems ensure users (or devices and services) are who they claim to be, using everything from passwords to [fingerprints](). Think of it like staying at a hotel: a keycard proves a registered guest’s identity and unlocks their specific room. Both hotels and online services want only legitimate access, but keeping digital “keycards” safe presents a challenge. A simpler everyday version of this happens dozens of times a day: unlocking your phone with a face scan, or opening your banking app with a fingerprint. In both cases, the device is authenticating you before it shows anything sensitive, and it’s doing it in under a second. Case in point: the Verizon [2026 Data Breach Investigations Report]() highlighted credential abuse appeared at some point in 39% of all breaches. That’s why businesses are moving away from passwords toward more secure, user-friendly methods that keep cybercriminals out without making life harder for everyone else. ### Authentication vs. authorization [Authentication and authorization]() answer two different questions. Authentication asks “Who is the user?” and confirms identity, a bit like checking a guest’s ID at a hotel. [Authorization]() asks “What are they allowed to do?” and determines permissions, if a keycard lets them onto the lounge level, for example. | | **What it checks** | **When it happens** | **Example** | | --- | --- | --- | --- | | **Authentication** | Identity: is this really the claimed user? | At login, and again at step-up moments | Entering a password or scanning a fingerprint to sign in | | **Authorization** | Permissions: what can this identity access? | After authentication, on every protected action | A plan member can update their device but not cancel the account | Here’s how they work in practice: when a customer logs in to their mobile carrier account, authentication confirms their identity. Once in, authorization controls what they can access. Maybe they’re a member of the plan, but not the account manager. They can make changes that affect their phone number and device, but can’t order a service upgrade or cancel the subscription. ### User authentication vs. machine authentication Authentication isn’t just for humans. Machines (i.e., devices, apps, etc.) need to prove who they are, too, and increasingly so do AI agents acting on a person’s behalf. Understanding all three, alongside the user authentication methods each relies on, gives a fuller picture of authentication security. User authentication is what most people think of when anything related to auth comes up. It’s the process where humans prove who they are to access systems, apps, and data. User authentication ranges from typing in a password, scanning their face or fingerprint, or entering a [one-time code](). Ultimately, it focuses on confirming human identity and is designed around human capabilities and behaviors. [Machine authentication]() (also known as machine-to-machine or M2M authentication) is how devices, applications, and services confirm identities with each other. Think of it like a handshake between two systems. For example, a smart home thermometer reports temperature readings to a cloud server, which requires it to authenticate with the remote service. The primary use cases for M2M authentication are API communication, microservices, IoT and smart devices, and cloud networking. While each of these scenarios might use a slightly different type of machine authentication, such as [access keys](), [client credentials flow](), or [Proof Key for Code Exchange (PKCE)](), they all require a machine to perform a backend “handshake” with another machine at some point in the journey. Unlike user authentication, machine authentication happens automatically in the background and typically uses more complex credentials since there’s no human experience to consider. It’s also much more frequent, but since machines can complete authentication nearly instantaneously, it doesn’t negatively impact the user. [Agentic identity]() adds a third category that doesn’t fit neatly into either bucket: an agent often needs to act with a human’s delegated authority one moment and with its own scoped, machine-level credentials the next. That distinction is becoming a real design problem for authentication systems, not just a theoretical one, as more products ship agent-facing features. **Learn more:** [What Is Non-Human Identity (NHI)?]() ## The three authentication factors Authentication is designed around three fundamental factors: ![Authentication factors]() | **Factor** | **Description** | **Examples** | | --- | --- | --- | | **Knowledge (something you know)** | Information only the legitimate user should know. The most common factor, and also the most vulnerable. | Passwords, PINs, security questions, passphrases | | **Possession (something you have)** | A physical item that holds a digital secret. Requires both physical access and the ability to breach the device to compromise. | Smartphones, security keys (e.g., YubiKeys), smart cards | | **Inherence (something you are)** | A biometric trait that’s difficult to fake but requires specialized hardware to validate. | Fingerprints, facial recognition, voice patterns, iris scans | Knowledge (something you know) includes passwords, PINs, security questions, and passphrases. These are the most common but also the most vulnerable. They can be guessed through [brute force attacks](), stolen through [credential phishing](), or compromised in [data breaches](). The challenge with knowledge factors is that to be truly secure, they need to be difficult for humans to remember and use. Possession (something you have) relies on physical authenticators that hold a digital secret. These include devices like smartphones (which have dedicated hardware for auth secrets), security keys (e.g., [YubiKeys]()), and smart cards. Such devices are highly secure because an attacker would need both physical access to the device and the ability to breach it. However, possessions can be lost, stolen, or damaged, which can necessitate less-secure fallback methods. Inherence (something you are) uses biometric characteristics like fingerprints, [facial recognition](), voice patterns, and iris scans. These immutable and universal traits are extremely difficult to fake, but they require specialized hardware to validate. [Biometric authentication]() also presents its own unique set of challenges, such as user pushback due to misunderstandings about how their data is used. ## How does authentication work? Authentication is a fundamentally simple process. When a user tries to log in to a system, that system determines the validity of one or more authenticators used to claim a digital identity (such as a password). Only two results are possible: “access granted” or “access denied.” But while the concept of authentication is quite simple, the process of authenticating a user has become significantly more complex over the years. Let’s break it down into its core components. ### The basic authentication process Every authentication system follows the same core fundamentals and standards, like those defined in [NIST SP 800-63-4](): 1. **Identity claim:** The claimant (the user) asserts an identity to the system (such as with an email or username) 2. **Authenticator presentation:** The claimant presents one or more authenticators as proof (password, biometric data, a signed cryptographic challenge, security token, etc.) 3. **Authenticator validation:** The verifier (the system) validates the presented authenticators against stored authentication data 4. **Access decision and session establishment:** If validation succeeds, the system grants access and establishes a session with appropriate permissions Using the hotel check-in from earlier: the guest states their name (identity claim), presents an ID or confirmation email (authenticator presentation), the front desk checks it against the reservation (authenticator validation), then hands over a keycard or flags a problem (access decision). ### How authentication works in a web application The same four steps above look like this in a typical web app: 1. The user submits credentials (a password, a passkey, an OTP) through a login form. 2. The server verifies those credentials against what it has stored, whether that’s a hashed password or a public key from a prior passkey registration. 3. If verification succeeds, the server issues a session or a token, most commonly a [JSON Web Token (JWT)](), representing that the user is authenticated. 4. That session or token travels with each subsequent request, typically in a cookie or an authorization header. 5. The server validates the token on every request rather than re-checking credentials each time. 6. Access is granted or refused based on whether the token is valid, unexpired, and tied to the resource being requested. Where standards fit into this flow: OAuth 2.0/2.1 and OpenID Connect (OIDC) handle the case where a user authenticates with a third party (like “Sign in with Google”) rather than directly with your app, and sessions or JWTs are simply the mechanism most frameworks use to avoid asking for credentials on every single request. ## Importance of authentication Authentication is critical to securing users’ sensitive data, whether it’s stored on networks, applications or systems. Strong authentication is necessary for: - **Security:** Authentication is the most critical layer in your defense against [account takeovers](). Without strong authentication, even the toughest backend firewalls become meaningless once an attacker gains legitimate-looking access. - **User experience:** Poor authentication creates friction that drives users away. Complex password requirements, frequent re-authentication, and confusing multi-factor flows all contribute to user frustration and abandonment. Modern methods like passwordless auth can actually improve user experience while enhancing security. - **Regulatory compliance:** Industries like healthcare (HIPAA), [retail]() and finance ([PCI DSS]()), and government (FedRAMP) have strict authentication requirements. Failing to implement proper authentication controls can result in hefty fines, regulatory body audits, and loss of certifications. Many regulations now specifically require multi-factor authentication for accessing certain data. ## Modern authentication challenges and solutions Today’s traditional, password-based authentication faces a crisis: credentials are routinely exposed, sold to the highest bidder, and even posted for free on underground networks. These billions of credentials are [fed into botnets]() to attempt account takeovers en masse, prompting organizations to enforce increasingly demanding password policies. Yet, users already struggle to create and remember complex passwords, which leads to password reuse (making them vulnerable to [credential stuffing]()), thus, the cycle continues. This is why modern systems often implement multi-factor authentication (MFA), adopt passwordless methods, and layer in adaptive authentication. A newer challenge is emerging alongside these: identity for AI agents and other non-human entities. Traditional authentication assumes a human is at the keyboard; agentic systems break that assumption by acting on a user’s behalf without a person present at every step, which means the identity model has to account for delegated, scoped, and revocable access rather than a single static login. We’ll cover more about how these authentication strategies solve today’s challenges in the following section. ## Types of authentication Authentication can take many forms, and the right method depends on your organization’s security needs, user experience goals, and regulatory requirements. Below, we compare the most common types at a glance, then break each down in more detail. | **Method** | **How it works** | **Security level** | **User experience** | **Best for** | | --- | --- | --- | --- | --- | | **Password-based** | User enters a username and password, checked against stored values | Low | Familiar but frustrating; vulnerable to reuse and phishing | Legacy systems, low-risk applications | | **Token-based** | User presents a physical or software token tied to their account | Medium-high | Extra step, but not tied to memory | Financial transactions, sensitive data access | | **Certificate-based** | Digital certificate issued by a trusted authority verifies identity | High | Invisible to the end user once configured | Enterprise environments, machine identity | | **Multi-factor (MFA)** | Combines two or more factors from different categories | High | Adds a step, but only occasionally | Any account handling sensitive data | | **Passwordless** | Uses possession or inherence factors instead of a password | High | Faster and simpler than passwords | Consumer and enterprise apps alike | | **Adaptive** | Scores login risk in real time and adjusts required verification | High | Nearly invisible for legitimate users | Apps with variable risk across sessions | | **Biometric** | Verifies a physical trait like a fingerprint or face scan | High | Fast, requires compatible hardware | Mobile-first and device-bound experiences | ### Password-based authentication [Password-based authentication]() is a method of verifying a user’s identity by requiring them to enter the password associated with their account. To authenticate with the system, the user enters their username and password, which are then compared to the stored values in the system’s database. If the username and password match, the user is granted access. Although this is the most common type of authentication due to its simplicity and convenience, it is also probably the least secure. Its core weakness is straightforward: passwords can be phished, reused across services, or guessed, especially if the password is weak or reused across multiple systems. ### Token-based authentication [Token-based authentication]() is a method of verifying a user’s identity by requiring them to present a token that is associated with their account. The token is a physical device or a digital file that contains a unique identifier, such as a smart card, USB key, or a software token. Token-based authentication provides an extra layer of security compared to password-based authentication, as the physical token is harder to steal or replicate than a password. They are often used in situations where strong authentication is necessary, such as accessing sensitive data or performing financial transactions. However, although tokens are a reliable method of authentication, they are more expensive and less convenient. They can be lost, stolen, or damaged, so users must take appropriate measures to safeguard them. ### Certificate-based authentication This method verifies the user’s or machine’s identity by using digital certificates. A digital certificate is an electronic document typically issued by a trusted third-party authority. They contain the user’s digital identity, a public key, and the digital signature of the certification authority. As digital certificates are difficult to forge or steal, certificate-based authentication is considered to be highly secure. Usually, it’s used in enterprise environments dealing with sensitive data. However, it is more complex to set up and manage than other authentication methods, so it’s not the most convenient method for widespread use. ### Multi-factor authentication (MFA) Multi-factor authentication, or MFA, requires users to verify their identities using two or more independent factors from different categories (which may or may not include a password) at the time of login. [Two-factor authentication (2FA)]() is the most common version of [MFA](), with only two identification factors needed. With rapidly growing application security risks, more businesses are starting to rely on MFA to secure their applications against cybersecurity threats. ### Passwordless authentication [Passwordless authentication]() refers to a range of authentication methods used to verify a user’s identity without the need for passwords. Instead, passwordless authentication uses a combination of possession and inherence factors, such as: - [Magic links]() – A URL sent via text message or email containing a token that allows the user to log in without requiring a password when they click on it. - [One-time passwords (OTP)]() – Unique, dynamically generated codes with numbers and/or letters that grant one-time access to the user. - [Authenticator apps]() – An authenticator app is a software application installed on the user’s device that generates [time-based one-time passwords (TOTP)](). - [Biometrics]() – A physical trait unique to the user, such as fingerprints, voice, face, etc. - [Passkeys]() – A FIDO2-based credential tied to a device and, increasingly, the clearest line between modern and legacy authentication, since they’re phishing-resistant by design and sync across a user’s devices. By removing passwords, passwordless authentication reduces the risk of unauthorized access, making it superior to other methods. Additionally, it’s more convenient for users, as they no longer need to remember complex passwords. Passwordless authentication is used in a variety of applications, including [online banking](), ecommerce, and enterprise environments. As technology continues to advance, passwordless authentication is likely to become more widespread as a secure and convenient alternative to traditional passwords. ### Adaptive authentication [Adaptive authentication]() scores each login attempt based on contextual risk factors: where the user appears to be located, whether they’re using a new device, etc. This scoring system determines next steps, such as whether they’ll be prompted to complete additional authentication (like MFA). Also known as risk-based authentication (RBA), adaptive authentication balances security rigor with a smooth user experience. It lets legitimate users sail through with only necessary friction, while potential threats are caught as early as possible. ### Biometric authentication [Biometric authentication]() verifies identity using a physical or behavioral trait: a fingerprint, a face scan, a voice pattern, or an iris scan. It’s the most common real-world expression of the inherence factor, and it’s become the default unlock method on most modern phones. Biometric data is typically captured and matched locally on the user’s device rather than transmitted to a server, which limits what an attacker can steal even if they compromise the backend. The tradeoffs are hardware dependency (not every device has a camera or fingerprint sensor capable of secure capture) and user comfort. Some users are wary of biometrics due to misunderstandings about how the underlying data is stored and used, so clear communication about local-only processing matters for adoption. ## Modern authentication protocols Today’s authentication systems rely on standardized protocols that ensure secure, interoperable [identity and access management]() across diverse platforms and services: - [OAuth 2.0/2.1]() is the industry standard for authorization, not authentication on its own. Notably, [OAuth]() isn’t an authentication protocol on its own, but it is a core part of OpenID Connect (below). OAuth powers [social login](), like “Sign in with Google/Apple/Microsoft,” and it’s a key ingredient in [modern AI security](). - OpenID Connect (OIDC) adds an authentication layer on top of OAuth 2.0, and it’s the piece that actually confirms who the user is. [OIDC]() is what actually authenticates users in modern [single sign-on]() (SSO) systems. - SAML 2.0 (Security Assertion Markup Language) is an older SSO protocol still widely used in enterprise environments to exchange authentication data between an identity provider and an application. [SAML]() works by securely exchanging authentication data between identity providers and applications. ![Visual overview of how SAML SSO authentication works]() - [WebAuthn]() and [FIDO2]() are the standards that make passwordless authentication possible in the browser, using public-key cryptography instead of a shared secret. They’re supported natively by modern browsers and operating systems. - [System for Cross-Domain Identity Management (SCIM)]() automates user provisioning and deprovisioning (enabling and disabling access) across multiple systems, which is what keeps enterprise directories in sync as employees or customers join and leave. These [authentication protocols]() work together to create an interwoven, interoperable authentication ecosystem. Combined, they can create smooth auth experiences for users. For example, you might use OIDC to sign into an app with your Google account, while WebAuthn/FIDO handles the actual authentication through your fingerprint via [passkeys](). ## Authentication best practices Authentication best practices evolve over time, but industry standards (like those provided by NIST) and implementation successes serve as reliable barometers. The following tips and tactics will help you build authentication that is both secure and user-friendly. ### Embrace passwordless authentication Passwordless authentication reduces the risk of account takeovers and identity theft while improving user experience. [90% of users are aware of passkeys]() and 75% of users have enabled passkeys on at least one account, making passwordless a practical choice for modern applications. When launching a new auth method like magic links, email-based OTPs, or passkeys, consider gradually rolling out to a smaller cluster of users first. ### Implement adaptive MFA Not every login attempt carries the same risk. Adaptive MFA adjusts the level of validation required based on factors like device reputation, geolocation, and login behavior. This approach introduces unnecessary friction for legitimate, trusted users while strengthening security for suspicious activity. Consider requiring additional authentication steps only for high-risk scenarios like new devices or unusual locations. ### Use phishing-resistant methods Traditional MFA can still be vulnerable to phishing attacks and [MFA bypass techniques](). Prioritize [phishing-resistant methods]() and factors that can’t be easily stolen or replicated, such as FIDO2-based passkeys built on device-bound biometrics. Avoid SMS-based codes when possible, as they’re susceptible to SIM swapping, [man-in-the-middle]() (MITM), and [adversary-in-the-middle]() (AITM) attacks. ### Follow security fundamentals Keep token expiration short, and use [refresh tokens]() behind [secure storage](). Log activity in enough detail to catch anomalies, like a token being used from multiple locations at once. Enforce strict rate limiting to prevent bot-based attacks, and apply [strong password policies]() if you decide to use traditional credentials. For example, you can integrate your password requirements with Have I Been Pwned to prevent users from setting their password to one that’s been breached previously. ## Authentication in action: Real-world case studies Planning and theorizing about authentication can certainly help you prepare for production, but eventually, it’s time to solve real business challenges. Authentication can have a huge impact on security, user experience, and the bottom line across a wide range of industries. Here’s how different sectors implement authentication to meet their specific needs: ### Banking and finance **Pattern: risk-based branching for bot defense.** [GradRight](), an EdFinTech platform helping students finance education abroad, required defense from bot attacks without affecting their user experience. They added conditional checks for bot traffic, automatically branching journeys based on the risk level. If the system uncovered a likely bot, it was given additional auth steps. Legitimate users continued undisrupted. ### Ecommerce **Pattern: per-application session policy.** [CARS24](), a multinational online car marketplace, serves diverse stakeholders, including customers, dealers, and internal users across multiple applications. CARS24’s authentication solution could set different session times, activity timeouts, and other settings to cater to each app’s security requirements, meeting the different needs of their diverse user base. ### Insurance **Pattern: passkey-first with a documented fallback.** [Branch Insurance](), a cloud-native insurance provider, moved to phishing-resistant passkey authentication to serve their 12,000+ independent insurance agents. They saw auth-related support ticket volume drop by about half, and saw 25% adoption in the first 90 days. They also created a fallback flow for the small fraction of devices that might not support passkeys, ensuring users never encountered unnecessary roadblocks. ### Healthcare **Pattern: consolidated, compliant backend across portals.** [SmithRx](), a full-service Pharmacy Benefit Manager, needed to unify authentication across multiple portals while implementing fine-grained access control for their complex healthcare ecosystem. By consolidating their authentication backend, they were able to significantly reduce development overhead while maintaining a [HIPAA-compliant login]() experience. ### SaaS applications **Pattern: SSO, SCIM, and tenant-level RBAC in one stack.** [Notch](), an AI-native customer support platform, needed flexible authentication to serve both startups and enterprises. With their auth implementation, Notch customers gained the benefits of [SSO](), [SCIM provisioning](), and tenant-level access controls with [RBAC](). ## How to choose the right authentication method for your app The right method depends on what you’re actually optimizing for. Use this decision matrix to narrow the field: | **If your priority is…** | **Consider** | **Why** | | --- | --- | --- | | Strong security with low friction | Passwordless with passkeys | Phishing-resistant by design, faster than passwords, no shared secret to steal | | Uneven risk across sessions | Adaptive MFA | Applies extra verification only when risk signals warrant it, rather than every time | | Regulated industries with audit requirements | Phishing-resistant MFA with audit trails | Meets compliance mandates while producing the logging regulators expect | | Developer speed and no-code workflows | A platform approach | Visual workflow tooling ships auth changes without a full engineering cycle per update | | Identity for AI agents and non-human entities | A platform with native agent authentication | Traditional auth wasn’t built for delegated, scoped, machine-executed access | For teams that need to authenticate both human users and AI agents, and want to do it through visual, no-code and low-code workflows rather than custom infrastructure, a platform purpose-built for both is worth evaluating rather than assembling the pieces separately. ## Easy and secure authentication for your app Authentication is at the heart of securing modern applications, and getting it right is critical for protecting your users, your data, and your business. From passwordless logins to adaptive MFA, the challenge is building strong, scalable flows without slowing development or adding friction. Descope’s drag-and-drop [CIAM platform]() helps organizations deliver secure, smooth authentication across every touchpoint, whether you’re securing customers, employees, partners, or AI agents, without the complexity of building it from scratch. [Get started]() with a Free Forever Descope account, or [book a demo]() to see how we can support your authentication strategy. ![Biometrics Flow]() ## Frequently asked questions about authentication --- ### [What Is the Model Context Protocol (MCP) and How It Works](https://www.descope.com/learn/post/mcp) *Full content: [https://www.descope.com/learn/post/mcp.md](https://www.descope.com/learn/post/mcp.md)* Large language models (LLMs) like Claude, ChatGPT, Gemini, and Llama have completely changed how we interact with information and technology. They can write eloquently, perform deep research, and solve increasingly complex problems. But while typical models excel at responding to natural language, they’ve been constrained by their isolation from real-world data and systems.  The **Model Context Protocol (MCP)** addresses this challenge by providing a standardized way for LLMs to connect with external data sources and tools—essentially a “universal remote” for AI. Released by Anthropic as an open-source protocol, MCP builds on existing function calling by eliminating the need for custom integration between LLMs and other apps. This means developers can build more capable, context-aware applications without reinventing the wheel for each combination of AI model and external system. ![Before and after MCP]() This guide explains the Model Context Protocol’s architecture and capabilities, how it solves the inherent challenges of AI integration, and how you can begin using it to build better AI apps that go beyond isolated chat interfaces. ## LLM isolation & the NxM problem It’s no secret that LLMs are remarkably capable, but they typically operate in isolation from real-world systems and current data. This creates two distinct but related challenges: one for end users, and one for developers and businesses. For everyday users, the isolation means a constant “copy and paste tango” to get relevant responses about recent data. This requires manually collecting information from various sources, feeding it into the LLM’s chat interface, and then extracting or applying the AI’s output elsewhere.  While several models offer [AI-powered web search](), and Anthropic’s Claude 3.7 and 4 models [boast a Computer Use feature](), they still lack direct integration with knowledge stores and tools. Even as major platforms like [OpenAI’s ChatGPT]() and [Google’s Gemini]() add built-in app integrations, these remain platform-specific solutions rather than universal standards. For devs and enterprises, the challenge is much more complex: the “NxM problem,” where *N* represents LLMs and *M* stands for tools. On the *N *side, there are many AI systems, and on the *M *side, there are countless systems. Each LLM provider has their own protocols to connect with external tools, making the potential integration points essentially endless.  By breaking the NxM problem down, we can see it causes: - **Redundant development efforts:** Dev teams will repeatedly solve the same integration issues for each new AI model or data source. For example, connecting ChatGPT with your knowledge stores requires starting from scratch with custom code. But with every additional AI system or tool, your devs have to do *everything *from the beginning each time—*N *multiplied by *M*. - **Excessive maintenance:** Tools, models, and APIs will inevitably evolve, and business will want to stay on the cutting edge. The lack of standardization means an integration can potentially stop working because a tool or model is updated, or an old one is deprecated. - **Fragmented implementation:** Different integrations may handle similar functions in totally unexpected ways, creating unpredictable or undesirable results. This fragmentation can lead to end user confusion or frustration as different developers and companies implement inconsistent integrations. However, it’s important to understand that MCP doesn’t solve the NxM problem by simply replacing the integration methods that came before. It connects AI apps to context while building on top of function calling—the primary method for calling APIs from LLMs—to make development simpler and more consistent.  ### Relationship between function calling & Model Context Protocol Function calling, which allows LLMs to invoke predetermined functions based on user requests, is a well-established feature of modern AI models. Sometimes referred to as “tool use,” function calling is not mutually exclusive with MCP; the new protocol simply standardizes how this API feature works, adding context for the LLM. This is achieved by streaming tool definitions (including their capabilities, data stores, and possible prompts) to LLMs from the MCP server.  Without MCP, when you use a function call directly with an LLM API, you need to: - Define model-specific function schemas, which are JSON descriptions of the function, acceptable parameters, and what it returns. - Implement handlers (the actual code that executes when a function is called) for those functions. - Create different implementations for each model you support. MCP standardizes this process by: - Defining a consistent way to specify tools (functions) across any AI system. - Providing a protocol for discovering available tools and executing them. - Creating a universal, plug-and-play format where any AI app can use any tool without custom integration code. You might be familiar with AI apps that use function calling, like Custom GPTs using [GPT Actions](). A Custom GPT can determine which API call resolves the user's prompt, create the necessary JSON, then make the API call with it. While this allows some purpose-built tooling, it’s bound to OpenAI’s ecosystem. MCP brings similar capabilities to any AI application that implements the protocol, regardless of the underlying model vendor. [MCP explained in 15 minutes]() **Also read: **[**MCP vs Function Calling**]() ## MCP architecture and core components The Model Context Protocol uses a client-server architecture [partially inspired by the Language Server Protocol (LSP)](), which helps different programming languages connect with a wide range of dev tools. Similarly, the aim of MCP is to provide a universal way for AI applications to interact with external systems by standardizing context. ![MCP general architecture]() ### Core components MCP architecture consists of four primary elements: ![MCP core components]() - **Host application:** Applications housing LLMs (or LLMs themselves) that interact with users and initiate connections. This includes Claude Desktop, AI-enhanced IDEs like Cursor, and standard web-based LLM chat interfaces. - **MCP client:** Integrated within the host application to handle connections with MCP servers, translating between the host’s requirements and the Model Context Protocol. Clients are built into host applications, like the MCP client inside Claude Desktop. - **MCP server:** Adds context and capabilities, exposing specific functions to AI apps through MCP. Each standalone server typically focuses on a specific integration point, like GitHub for repository access or a PostgreSQL for database operations. - **Transport layer:** The communication mechanism between clients and servers. MCP supports two primary transport methods: - **STDIO (Standard Input/Output):** Mainly local integrations where the server runs in the same environment as the client. - **Streamable HTTP: **Remote connections over standard HTTP. As of the July 28, 2026 spec revision, remote transport is fully stateless. Each request carries everything it needs, with no session to establish or maintain. An earlier HTTP+SSE transport was deprecated in March 2025. All communication in MCP uses [JSON-RPC 2.0]() as the underlying message standard, providing a standardized structure for requests, responses, and notifications. ## How MCP works When a user interacts with a host application (an AI app) that supports MCP, several processes occur behind the scenes to enable quick and seamless communication between the AI and external systems. Let’s take a closer look at what happens when a user asks Claude Desktop to perform a task that invokes tools outside the chat window. ### Capability discovery Before the July 2026 revision, MCP used an initialization handshake to establish a session and exchange capabilities up front. The current spec removes both the handshake and sessions. Discovery now works like this: 1. **Connection**: The MCP client connects to its configured MCP servers with plain HTTP requests, with no session to establish first. 2. **Discovery: **The client calls the `server/discover` method to ask a server what tools, resources, and prompts it offers. 3. **Per-request capability data: **Clients and servers include relevant capability information with each request via the `_meta` field, so any server instance can handle any request without stored context. ![Fig: A simplified MCP flow showing the LLM/Agent interacting with external systems and returning contextualized results]() ### From user request to external data Let's say you ask Claude, "What's the weather like in San Francisco today?" Here's what happens: 1. **Need recognition: **Claude analyzes your question and recognizes it needs external, real-time information that wasn't in its training data. 2. **Tool or resource selection:** Claude identifies that it needs to use an MCP capability to fulfill your request. 3. **Permission request:** The client displays a permission prompt asking if you want to allow access to the external tool or resource. 4. **Information exchange:** Once approved, the client sends a request to the appropriate MCP server using the standardized protocol format. 5. **External processing:** The MCP server processes the request, performing whatever action is needed—querying a weather service, reading a file, or accessing a database. 6. **Result return**: The server returns the requested information to the client in a standardized format. 7. **Context integration:** Claude receives this information and incorporates it into its understanding of the conversation. 8. **Response generation:** Claude generates a response that includes the external information, providing you with an answer based on current data. Ideally, this entire process happens in seconds, creating an unobtrusive experience where Claude appears to "know" information it couldn't possibly have from its training data alone. ### Additional protocol capabilities Since its initial release, MCP has added several significant functions that enhance its capabilities: **Sampling **allows servers to request LLM completions from clients. For example, an MCP server helping with code review could recognize the need for additional context and ask the client’s LLM to generate a summary of recent changes. This enables an essentially “agentic” workflow while still retaining client control over model access, selection, and permissions—all without needing server API keys.  **Note: **The July 28, 2026 revision deprecates Sampling, though it will keep working for now. Removal requires a future proposal and at least 12 months, but new servers should integrate with LLM provider APIs directly. That means holding their own provider credentials. **Elicitation **enables servers to request additional information from users during their operations. For instance, if the GitHub MCP server needs to know which branch to commit to because it wasn’t described in the prompt, it can ask the user for that information mid-operation using structured JSON schemas to validate the response. This enables more interactive workflows while maintaining security through human oversight. **Roots **are a standardized way for clients to expose filesystem boundaries to servers. For example, when using an MCP server for file operations, the client can specify that the server only has access to `/user/documents/project/` rather than the entire filesystem, preventing accidental (or malicious) access to sensitive data stores.  **Note: **Roots is also deprecated as of the July 28, 2026 revision, with the same 12-month window. The replacement is boundary configuration on the server side through tool parameters, resource URLs, or server settings. ## MCP client & server ecosystem Since its introduction in late 2024, MCP has experienced explosive growth. Some MCP marketplaces claim nearly 16,000 unique servers at the time of writing, but the real number (including those that aren’t made public) could be considerably higher. ### Examples of MCP clients The MCP client ecosystem now includes: - [Claude Desktop](): The original, first-party desktop application with comprehensive MCP client support - [Claude Code](): Command-line interface for agentic coding, complete with MCP capabilities - [Cursor](): The premier AI-enhanced IDE with one-lick MCP server installation - [Windsurf:]() Previously known as Codeium, an IDE with MCP support through the Cascade client - [Continue](): Open-source AI coding companion for JetBrains and VS Code - [Visual Studio Code](): Microsoft’s IDE, which added MCP support in June 2025 - [JetBrains IDEs](): Full coding suite that added AI Assistant MCP integration in August 2025 - [Xcode](): Apple’s IDE, which received MCP support through GitHub Copilot in August 2025 - [Eclipse](): Open-source IDE with MCP support through GitHub Copilot as of August 2025 - [Zed](): Performance-focused code editor with MCP prompts as slash commands - [Sourcegraph Cody](): AI coding assistant implementing MCP through OpenCtx - [LangChain](): Framework with MCP adapters for agent development - [Firebase Genkit](): Google’s AI development framework with MCP support - [Superinterface](): Platform for adding in-app AI assistants with MCP functionality Notably, IDEs like Cursor and Windsurf have turned MCP server setup into a one-click affair. This dramatically lowers the barrier for developer adoption, especially among those already using AI-enabled tools. However, consumer-facing applications like Claude Desktop still require manual configuration with JSON files, highlighting an increasingly apparent gap between developer tooling and consumer use cases. ### Examples of MCP servers The MCP ecosystem comprises a diverse range of servers including reference servers (created by the protocol maintainers as implementation examples), official integrations (maintained by companies for their platforms), and community servers (developed by independent contributors). #### Reference servers Reference servers demonstrate core MCP functionality and serve as examples for developers building their own implementations. These servers, maintained by MCP project contributors, include fundamental integrations like: - [**Git**]()**: **This server offers tools to read, search, and manipulate Git repositories via LLMs. While relatively simple in its capabilities, the Git MCP reference server provides an excellent model for building your own implementation. - [**Filesystem**]()**: **Node.js server that leverages MCP for filesystem operations: reading/writing, creating/deleting directories, and searching. The server offers dynamic directory access via Roots, a recent MCP feature that outlines the boundaries of server operation within the filesystem. - [**Fetch**](): This MCP server provides web content fetching capabilities. This server converts HTML to markdown for easier consumption by LLMs. This allows them to retrieve and process online content with greater speed and accuracy. #### Official MCP integrations These servers are officially supported by the companies who own the tools. Integrations like these are production-ready connectors available for immediate use. - [**Descope**]()**: **The Descope MCP Server connects your AI assistant to the Descope identity platform. It gives agents the ability to read documentation, inspect your project configuration, manage users and tenants, configure authentication flows, review audit logs, and make changes to your identity infrastructure, all through natural language and from a single session. - [**Stripe**]()**:** This integration can handle use cases like generating invoices, creating customers, or managing refunds through natural language requests. Here, the main draw is the potential for delegating payment concerns to customer-facing chatbots. - [**Supabase**](): This official MCP server allows users to interact with Supabase through an LLM: creating tables, querying data, deploying edge functions, and even managing branches. As an added security measure, Supabase MCP employs a SQL result wrapper to discourage LLMs from obeying malicious commands hidden in the data. - [**Apify**]()**:** Through the use of over 4,000 Apify Actors, enables a wide range of functions including a RAG (Retrieval Augmented Generation) web browser, data scraping across multiple platforms, and content crawling. #### Community MCP servers The community-driven ecosystem exemplifies how standardization can accelerate adoption and creativity. The following servers are maintained by enthusiasts rather than businesses, which means they trend toward a more diverse range of needs. - [**Discord**]()**:** The gaming-focused messaging app Discord shares many similarities with Slack, and the MCP server integration is no different. This allows users to send and read messages, with automatic server and channel discovery for easier navigation. - [**Docker**]()**:** Enables natural language interaction with Docker to manage containers, volumes, and images. Intended for server admins and tinkerers, this abstracts Docker both local and remote engine management into a friendlier interface. - [**HubSpot**]()**:** This integration with ubiquitous CRM HubSpot allows users to list and create contacts, get recent engagements, and manage companies. While simple, this server provides a simple way to retrieve information for use with other tools. ## Security considerations for MCP servers The rapid adoption of MCP has opened [numerous, critical security challenges]().  [Research by Knostic in July 2025]() involved scanning nearly 2,000 MCP servers exposed to the internet, with all verified servers lacking any form of authentication. This essentially means anyone could access internal tool listings and potentially exfiltrate sensitive data. Similarly, [Backslash Security’s June 2025 findings]() identified similar vulnerabilities in another 2,000 servers, noting patterns of over-permissioning and complete exposure on local networks. The MCP authorization specification addresses some concerns by classifying MCP servers as [OAuth]() Resource Servers, while requiring clients to implement Resource Indicators ([RFC 8707]()). The July 28, 2026 revision builds on this with a set of authorization requirements around issuer validation, client registration, and token refresh. Our breakdown of the 2026 major revision  covers what changed for identity and auth. One cautionary tale of over-permissioning emerged in July 2025, when Replit’s AI agent [deleted a production database containing over 1,200 records](). This was in spite of explicit instructions (a “code and action freeze”) meant to prevent any changes to production systems. The lesson in this appears to be that proper permissioning, had it been handled via OAuth scopes externally, might have saved their code. For comprehensive guidance on MCP authentication and authorization, see Descope’s [MCP auth spec guide](), and for enterprise deployment considerations, refer to our [enterprise MCP challenges article](). Ultimately, human-in-the-loop design remains crucial to keeping LLMs in their appropriate roles, avoiding painful misfires. Clients must request explicit permission before accessing tools or resources, but this protection depends on specific permission prompts—and users understanding the impact of their choices. ## Conclusion The Model Context Protocol represents a significant leap in connecting LLMs to external systems, standardizing a fragmented ecosystem and potentially resolving the NxM problem. By universalizing how AI applications talk to tools and data sources, MCP reduces development overhead and enables a more interoperable ecosystem where innovation benefits the entire community—rather than remaining siloed. That design philosophy has borne fruit already: developments and recommendations we tracked here in earlier versions of this post have since shipped. - Secure elicitation and [progressive scoping]() landed in the November 2025 revision - [Client ID Metadata Documents (CIMD)]() is not the specification’s recommended registration approach, with [Dynamic Client Registration (DCR)]() as the fallback - The July 28, 2026 revision goes even further, making the protocol stateless, formalizing a deprecation lifecycle, and promoting extensions like Enterprise-Managed Authorization (EMA) and MCP Apps to official status Providing a common format for integrations amounts to more than speeding up the processes we already have. It has created a space where both major enterprises and individual contributors can build equally viable, increasingly valuable options to make everyone’s lives better. For more developer updates from the world of authentication, access control, and AI, subscribe to our blog or [follow us on LinkedIn](). If you’re building MCP servers or preparing your APIs to serve AI agents, the [Descope Agentic Identity Hub]() provides the essential identity layer around them:  - [MCP SDKs and framework integrations]() that add authorization in a few lines of code - [Client registration]() through DCR and CIMD - [Consent](), [policy](), and [audit controls]() for the agents that connect Start with a [Free Forever Descope account]() and explore our [MCP docs]() to secure your agents now. ## FAQs about the Model Context Protocol (MCP) --- ### [What Is the Universal Commerce Protocol (UCP)?](https://www.descope.com/learn/post/ucp) *Full content: [https://www.descope.com/learn/post/ucp.md](https://www.descope.com/learn/post/ucp.md)* AI agents got good at finding products long before they got a standardized way to actually buy them. The unfortunate reality for consumers is that an agent can compare headphones across two dozen retailers, but completing a purchase on the user’s behalf hasn’t yet matured to a point of universal acceptance. For most scenarios today, shopping with an agent means either clicking a link (for the user to transact manually) or relying on a custom integration. The [Universal Commerce Protocol (UCP)]() is a direct response to this problem. Launched in [January 2026 by Google](), UCP is an open standard that gives agents, merchants, and payment providers a shared language for the full commerce lifecycle: product discovery, checkout, identity linking, payments, and post-purchase order management.  This post covers what UCP is, how its discovery and capability model works, and why its identity linking capabilities deserve more attention than they’re getting. ## What is the Universal Commerce Protocol (UCP)? UCP is an [open-source specification]() that standardizes how AI platforms transact with businesses. Beyond its notable co-developers (Shopify, Etsy, Wayfair, Target, and Walmart), the protocol launched with endorsements from more than 20 partners across retail and payment providers, including Mastercard, Stripe, Visa, and American Express. The big differentiator between UCP and similar protocols is scope. Where [OpenAI and Stripe’s Agentic Commerce Protocol (ACP)]() concentrates entirely on checkout and payment delegation, UCP covers the entire journey: catalog search, payment, tracking, returns, and everything in between. Google’s *other* agentic commerce protocol, the [Agent Payments Protocol (AP2)](), handles the main trust question (“Did the user actually authorize that payment?”), and UCP answers the orchestration piece (“How do an agent and a merchant transact at all?”). The two are designed to work together; UCP includes an [AP2 mandates extension]() for transactions that require cryptographic proof of user consent. **Read more: **[**The Developer’s Guide to Agentic Commerce**]() The core design philosophy behind UCP is comprised of two parts, both which distinguish the protocol from a traditional API: - **The merchant isn’t superseded by the agent’s platform. **The agent platform is just an interaction layer, and the customer relationship stays with the business. UCP transactions run against the merchant’s own catalog and payment processes, and those make it the merchant of record. - **The protocol is transport-agnostic. **Merchants can expose UCP capabilities over REST, as tools on a [Model Context Protocol (MCP)]() server, or via [Agent2Agent (A2A)]() Protocol, depending on what they already support. ## How UCP works UCP defines four participant roles: 1. The **platform **is the agent-facing surface where the user expresses intent. This could be an AI assistant, a chat interface, or an app. 2. The **business **is the merchant selling the product. 3. The **credential provider **manages the user’s payment credentials and personal data, issuing tokens rather than exposing raw card numbers. 4. The **payment service provider (PSP) **processes the actual charge. ![Fig: A diagram illustrating the four participants in UCP; the user and the discovery profile are not participants and appear for context]() The user in the above diagram isn’t really a participant role in the language of UCP. They authorize everything, through consent screens, identity linking, and (where applicable) AP2 mandates. But they never speak the language of the protocol themselves. Every UCP message flows between these four participants acting on the user’s *behalf*. The discovery profile, covered next, is likewise an artifact the business publishes rather than an actor in the UCP equation. ### Discovery and capability negotiation UCP begins with a JSON document the merchant publishes at `/.well-known/ucp` (a discovery profile at a standardized URL path). The profile states the protocol version, the services and capabilities the merchant supports, its accepted payment handlers, and the public signing keys platforms use to verify webhook and other authenticated messages from the business. Platforms publish profiles of their own, and the active capability set for any interaction is negotiated as the intersection of what both sides declare. UCP’s capability negotiation follows a server-selects architecture, which lets the business determine the active capabilities from that intersection. This means a small merchant that only supports UCP’s checkout and a large retailer that supports everything can both use it while speaking the same language. ### Capabilities and extensions The UCP spec is quite layered, with core shopping primitives (checkout sessions, line items, totals, statuses) settling at the bottom: - **Capabilities** are the major functional units built on those primitives: Checkout, Catalog, Order, Identity Linking, and Payment Token Exchange (and each are independently versioned). - **Extensions **augment capabilities with optional, domain-specific behavior; the AP2 mandates extension (which attaches cryptographic proof of user authorization to a checkout) is the flagship example. With extensions, merchants implement only what they need, and the extension model keeps the core spec from attempting to resolve every industry’s edge cases.  ### The checkout lifecycle A UCP checkout is a stateful session that moves through a defined state machine. Example session states include: - `incomplete` is as the name suggests; the session lacks required information the agent should try to resolve - `ready_for_complete` means the checkout session has all the information it needs, and platform the can finalize it programmatically - `completed` is self-explanatory - Meanwhile, cancellation is available throughout the session. This design is aware that not every transaction can finish headlessly: [Strong Customer Authentication (SCA)]() challenges, [identity verification](), and [CAPTCHA]() still require a human. When they appear, the merchant returns a `continue_url` (a fallback link into the merchant’s own web experience) so the user can finish the step the agent cannot. But a UCP order’s journey doesn’t simply end after payment. Order lifecycle events that surface after purchase completion (e.g., shipped, delivered, returned) flow back into the platform as signed webhooks. ### Payments UCP deliberately separates the commerce flow from payment execution. Merchants declare supported payment handlers in their profile (`/.well-known/ucp`), which lets them keep existing PSP integrations rather than adopting a new payment rail. Credentials move as tokens from the credential provider through the platform to the merchant; the design goal here is that raw payment credentials are never handled by the agent. For autonomous, human-not-present (HNP) purchases, the AP2 extension added the mandated-based audit trail. **Read more: **[**What is the Agent Payments Protocol (AP2) and How Does It Work?**]() ## How identity linking enables agents to shop on a user’s behalf Most explanations of UCP focus on the checkout enablement piece. The most consequential element from an auth perspective, however, is its identity linking capability. This is the mechanism by which the platform obtains authorization to act on a specific user’s behalf at a specific merchant. Without it, an agent transacts anonymously. The merchant can’t connect the session to an existing account, so the user’s stored information (addresses, order history, loyalty entitlements, etc.) are all unavailable. Every checkout starts with the agent collecting basic buyer details from scratch, which defeats the purported ease of agentic commerce. Identity linking closes the loop by letting the user delegate their standing at the merchant to the agent, with the merchant’s knowledge and consent. The mechanism is standard [OAuth 2.0](): 1. The platform initiates an [Authorization Code Flow with Proof Key for Code Exchange (PKCE)]() against the merchant’s authorization server. PKCE is mandatory for public clients. The user authenticates directly with the merchant, and the agent never sees credentials. 2. The merchant publishes its OAuth endpoints via authorization server metadata at `/.well-known/oauth-authorization-server`, so platforms can discover them programmatically. 3. The merchant issues scoped access tokens. PKCE with S256 (a secure hashing protocol) for all code exchanges since agent platforms are frequently public clients. 4. With a valid token, the platform can resolve the buyer’s profile and carry their entitlements into checkout. ![Fig: A diagram illustrating the UCP Identity Linking flow]() ## How UCP identity linking addresses scopes The March 2026 revision to the [identity linking spec of UCP]() reworked this capability in a way that should look familiar to anyone tackling [Model Context Protocol (MCP) authorization](). A mechanism registry lets merchants declare which linking mechanisms they support in a structured way, so the spec can absorb new authentication methods without breaking existing implementations. Capability-driven scopes tie what an agent requests to what it intends to do, so an agent that only needs catalog access never holds checkout permissions.  But the required flow is more demanding than vanilla OAuth 2.0, since PKCE is now a requirement. MCP as a transport brings in [Dynamic Client Registration (DCR)](), which allows agent platforms to onboard without manual setup. This combination of Authorization Code Flow with PKCE, metadata discovery, and DCR is effectively the [OAuth 2.1]() posture the MCP authorization spec arrived at after its first year, just applied to agentic commerce. It faces the same open challenges, though, like how to trust clients that register themselves, which the MCP ecosystem is answering with [Client ID Metadata Documents (CIMD)]().  Ultimately, the implementation burden lands on the merchant. To participate in the identity linking piece of UCP, you need to operate a full OAuth 2.0 [authorization server]()—that means token lifecycle management, client registration, consent, everything. Merchants who already run OAuth for their own apps can extend it, but merchants who don’t face a substantial identity build before the capability can be declared at all. The alternative is sidestepping the build with an existing authorization server. For example, Descope can serve as the authorization server behind a UCP identity linking implementation, providing the endpoints, metadata, consent screens, and scope enforcement while the merchant’s UCP profile points agents to it. Our [guide to building a UCP server with identity linking]() walks through that setup end to end.  ## Where UCP stands in the wider protocol ecosystem Google shipped the first UCP reference implementation, which powers direct checkout from eligible U.S. retailers inside AI Mode in Google Search and the Gemini app. Google Pay handles payment using credentials already stored in Google Wallet. To participate in this, merchants must have an active Merchant Center account.  Shopify, as a co-developer, built UCP support into its platform, and the protocol’s roadmap currently points beyond retail into lodging and food ordering, along with multi-item carts, loyalty account linking, and expanded post-purchase support. Those aren’t the only production implementations, but those outside them are relatively few, for now. The open question at the heart of UCP’s adoption (or really any other agentic commerce protocol) is not whether the plumbing works, but whether consumers will actually use it anytime soon. Customers are warming to the idea of agents as shopping *assistants* more than they are to agents as *shoppers*. [Accenture’s 2026 Consumer Pulse]() survey of more than 25,000 consumers found that 74% would delegate routine commerce tasks like reorders and subscription renewals to an agent, but only 9% are open to fully autonomous purchasing. Meanwhile, [Zeta Global’s research on what they term “active” AI shoppers]() points in a similar direction: 70% prefer to complete the purchase on the brand’s own site even when AI handled the discovery. OpenAI already adjusted to this reality, shifting its ACP-based flows toward merchant hosted checkout after in-chat purchasing saw minimal adoption. Agents now handle discovery and cart building, then hand the user to the merchant’s own environment to pay. But this is where UCP gets really interesting. Unlike other protocols in play, UCP doesn’t live or die on in-chat checkout. Merchants declare only what they support, and each capability is *still useful* on its own: - Discovery profiles make catalogs agent-parseable - Identity linking carries loyalty and saved details into agent sessions - Order webhooks keep post-purchase status updated None of these depend on the agent pressing that final “buy” button. UCP doesn’t need universal buy-in or full delegation to be worth implementing; it just needs to be useful wherever an agent actually joins the journey. As agentic workflows become routine in daily life, and the trust mechanisms mature, UCP is uniquely positioned to tackle the steps consumers eventually hand over. ## The identity layer underneath UCP Every commerce protocol in this space carries its own trust mechanisms. ACP has Shared Payment Tokens, AP2 has mandates, UCP has identity linking and signed messages. All of these assume an earlier question has already been addressed: who is this agent, who is it acting for, and what is it authorized to do? That question is actually answered upstream of the protocol. An agent connecting to a merchant’s MCP server (one of UCP’s supported transports) has to authenticate, establish the user it represents, and receive scoped access before any UCP capability can fire. And on the merchant side, identity linking turns the quest to “support agentic commerce” into a harrowing “build and maintain a standards-compliant OAuth 2.0 authorization server,” loaded with consent management and client registration for agents you’ve never met. This is the layer where the [Descope Agentic Identity Hub]() operates. It gives developers an OAuth 2.1 authorization server for the MCP servers and APIs, support for both DCR and CIMD, along with consent, scope, and token management out of the box. Agentic commerce may take years to settle, and in the meantime, protocols like UCP will keep raising tough questions and requirements. Identity infrastructure that’s driven by the same underlying standards is what will let developers move with these shifting challenges instead of rebuilding for each one. [Check out this working implementation]() of a FastMCP server built for a shopping site that uses Descope Agentic Identity Hub as the identity layer while supporting UCP. Explore Descope’s [Agentic Identity Hub]() now by signing up for a Free Forever Descope account. If you’d like to talk through your agentic commerce project with our auth experts, [schedule a demo]() and join the [AuthTown dev community]().  ## FAQs about the Universal Commerce Protocol (UCP) --- ## Blog ### [How to Secure an AI Agent With Claude Agent SDK + Descope](https://www.descope.com/blog/post/secure-ai-agent-claude-descope) Build a secure AI agent with the Claude Agent SDK and Descope: vault credentials, verify session tokens, and enforce per-tool scopes without hardcoded secrets. *Full content: [https://www.descope.com/blog/post/secure-ai-agent-claude-descope.md](https://www.descope.com/blog/post/secure-ai-agent-claude-descope.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!* --- AI agents become significantly more useful once they can interact with external systems. When your agent can call APIs, execute shell commands, write files, query databases, or connect to SaaS platforms, it starts behaving less like a chatbot and more like an active software operator. That capability, though, introduces a real security challenge: where do the credentials live, and how do you control what the agent is actually allowed to access? In many early implementations, the answer is environment variables, local config files, or hardcoded keys with permissions far broader than any single task requires. As agents grow more autonomous, these shortcuts become difficult to manage. Secrets become harder to rotate, access boundaries blur, and auditing agent activity becomes an afterthought. The [Claude Agent SDK]() gives developers a programmable way to build capable agents, using the same building blocks that power Claude Code: filesystem access, bash execution, [MCP]() connectivity, and subagent orchestration. This tutorial pairs it with [Descope’s Agentic Identity Hub](), a managed identity and credential layer built specifically for agents. Descope handles the identity side of things: verified session tokens, secure credential storage through [Connections](), fine-grained tool scopes, and [centralized audit logging](). By the end, you’ll have a working agent that authenticates with multiple external services using Descope-managed credentials, operates under a verified session identity, and enforces per-tool access boundaries without storing any secrets in your codebase. ## Secure agent architecture The architectural diagram below shows two separate agent flows: how the agent proves its own identity to the tools it calls, and how those tools securely access external services on the user’s behalf using Descope. ![Fig: A diagram illustrating the Claude-Descope agent architecture in this tutorial]() The **inbound layer** handles how the agent proves its identity to the local MCP server. Before any tools are called, the agent goes through a [DCR]() + [PKCE]() login flow with Descope, which issues a session token. Every subsequent tool call carries that token as a Bearer header, and the MCP server validates it with Descope before doing anything else. The **outbound layer** handles how the MCP server reaches third-party services on the user’s behalf. Once a tool call is validated, the server asks Descope for the right credential: a static API key for WeatherAPI, an OAuth token for Google Calendar, and an OAuth token via DCR for Notion. The agent never sees any of these credentials; they flow from Descope to the MCP server at runtime, only when needed. **Note:** This separation is crucial. The agent authenticates once at startup and operates under a verified identity throughout. External credentials are brokered on demand, scoped to that identity (a specific user), and never stored in the codebase or passed to the agent itself. If a credential isn’t connected yet, the tool returns an authorization link rather than failing, so the user can connect it and simply re-run the agent. This also means multiple users can run this agent with Descope handling their OAuth tokens securely. ## Setup and prerequisites Your demo agent will connect to three external services, each representing a different type of connection: 1. [**WeatherAPI.com**]()**:** A public weather API secured with a static API key 2. **Google Calendar:** Your personal calendar, accessed via [OAuth]() 3. **Notion:** A workspace doc created via the Notion MCP server, accessed via Dynamic Client Registration (DCR) Here is what the demo agent will do: You ask the agent to plan your day. It checks the weather (static API key), pulls your schedule from Google Calendar (OAuth), and creates a plan page in Notion (DCR) for you. Once configured, all three sets of credentials live in Descope’s Connections vault, *not* in your codebase. Your agent fetches them at runtime through Descope, so neither your repo nor your local environment ever holds a sensitive key or token. ### What you’ll need To complete the tutorial you’ll need to have the following: - **Python 3.11+** and **pip** - A **Descope account** with a project (`Descope-Claude-Agent`) created. [Sign up here](), and keep your [Management Key]() and [Project ID]() handy. - An **Anthropic API key.** [Get one here]() - A **Weather API key.** [Get one here]() (The free tier is enough). - A **Google Cloud project** with the Calendar APIs enabled and an OAuth 2.0 client configured. - A **Notion account**, no OAuth app registration is needed; Notion’s MCP server supports DCR, so the client registers itself automatically at runtime. ### Project structure Download this [GitHub repository]() to get started: ~~~bash cd Descope-Claude-Agent python -m venv venv source venv/bin/activate  # On Windows: venv\Scripts\activate pip install -r requirements.txt ~~~ Your downloaded `Descope-Claude-Agent` directory structure should look like this: ~~~plaintext Descope-Claude-Agent/ ├── get_user_token.py     # OAuth flow to authenticate user with Descope MCP app ├── mcp_server.py         # FastMCP server exposing 3 tools ├── run_claude_agent.py   # Claude agent that calls the MCP server ├── settings.py           # Contains different URLs required for this project ├── requirements.txt      # Dependencies ├── .gitignore            # Git ignore file ├── .env.example          # Environment variables (see below) └── README.md ~~~ ### Add credentials Rename the `.env.example` file as an `.env` file, and add required values there: ~~~plaintext # Change it as per your MCP server URL MCP_SERVER_URL=http://127.0.0.1:8000 # Add relevant credentials below DESCOPE_PROJECT_ID=your_descope_project_id DESCOPE_MANAGEMENT_KEY=your_descope_management_key DESCOPE_MCP_SERVER_CONFIG_URL=your_mcp_server_config_url ~~~ You’ll find the `DESCOPE_MCP_SERVER_CONFIG_URL` value in the "MCP server representation" section below (you can add this later after setting up an MCP server in Descope). Lastly, export the Anthropic key in your terminal: ~~~bash export ANTHROPIC_API_KEY=your_anthropic_api_key ~~~ ## Descope Connections: The credential vault Descope Connections is a credential vault for your MCP server. Instead of storing OAuth tokens or API keys in environment variables, your MCP server retrieves credentials from Connections at runtime. These credentials are centrally managed, never hardcoded, and scoped per user (or tenant). ### Static API key connection In your Descope project (`Descope-Claude-Agent`), go to **Agentic Identity Hub > Connections** and click **+ Connection**. From the Connections library, select **Custom API Key App** and give it a name and ID. For this tutorial, use `weather-api` and `weather-api-key`. You will need this connection ID in your MCP server. ![Fig: Descope weather API key connection]() The MCP tool retrieves this stored API key at runtime with this code snippet: ~~~python token_resp = descope_client.mgmt.outbound_application.fetch_token(     app_id="weather-api-key",     user_id=user_id, ) api_key = token_resp["token"]["accessToken"] ~~~ The `app_id` identifies the correct *Connection*, while `user_id` identifies the user associated with this API key (comes from the bearer JWT). A [Descope-hosted Flow]() is also needed to store this API key value (covered later). **Note:** You might wonder why not just store the API key in an environment variable. The short answer is for **key isolation**. Many APIs are paid services where each user brings their own key (like OpenAI or Claude). A Descope Connection stores those credentials securely on a per-user basis, so each user’s key stays isolated. This becomes even more important for OAuth tokens, which require individual user authorization with the service provider, such as Google or Notion. ### Custom OAuth app (Google Calendar) To connect Google Calendar, you need a **Client ID** and **Client Secret** from Google Cloud. You can refer to [Google Calendar’s quickstart guide]() for more details. Here’s what to set up: - **Create a Google Cloud project** at [console.cloud.google.com]() and enable the **Google Calendar API** under APIs & Services - **Configure an **[**OAuth consent screen**]() with ‘External’ audience and add your email as a test user (keeping the app in Testing mode is fine for this tutorial demo) - **Add the scope** `https://www.googleapis.com/auth/calendar.readonly` under Data Access so the agent can only read calendar events (*No* write access) - **Create a Web Application OAuth client** under Google Auth Platform and add Descope’s callback URL (`https://api.descope.com/v1/outbound/oauth/callback`) as an authorised redirect URI. - **Copy the Client ID and Client Secret**. You’ll paste these into Descope’s Connections vault to complete the Google Calendar connection. Without them, Descope cannot broker the OAuth flow on behalf of your users. Now, in your Descope project, go to **Agentic Identity Hub > Connections** and click **+ Connection**. Select **Google Calendar** from the Connections library, choose **Manual** under connection settings, and paste in your Google Client ID and Client Secret. Under Scopes, add `https://www.googleapis.com/auth/calendar.readonly` and leave everything else as-is. Create the connection and note its ID (`google-calendar`). ![Fig: Descope: Google Calendar Connection]() The **Tokens** tab next to the Connection settings will show stored user tokens once they are in place. The OAuth token is retrieved for a specific user at runtime using this code snippet: ~~~python token_resp = descope_client.mgmt.outbound_application.fetch_token(     app_id="google-calendar",     user_id=user_id, ) access_token = token_resp["token"]["accessToken"] ~~~ The `user_id` comes from the bearer token the agent sends to the MCP server. It identifies which user the agent is currently acting on behalf of. Once stored, Descope handles token refresh automatically. > **Note:** User-scoped tokens are critical here because the agent is not calling Google Calendar for itself. Instead, the agent is calling it on behalf of a specific user. Using a shared or static token would mean every user sees the same calendar data. Scoping the token to a `user_id` ensures the agent only accesses what that particular user has authorised, which is the correct and safe pattern for any agent acting on behalf of real people. ### DCR-registered third-party MCP server (Notion) Setting up Notion is similar to Google Calendar, but noticeably simpler thanks to [Dynamic Client Registration (DCR)](). Because Notion’s MCP server supports DCR, you don’t need to create an OAuth app in Notion or copy over any client credentials. You just need to have a Notion account with the same email ID that is used for agent authorization. Go to **Agentic Identity Hub > Connections** in your Descope project, and click **+ Connection**. Pick **Notion** from the connections library and choose **Dynamic client registration** under connection settings. Descope will automatically populate the MCP or Authorization URL field with `https://mcp.notion.com/sse`. Leave everything else as-is, click **Create and Register**, and note the connection ID (`notion`). ![Fig: Descope: Notion DCR Connection]() Retrieving the user-specific token at runtime follows the same pattern: ~~~python token_resp = descope_client.mgmt.outbound_application.fetch_token(     app_id="notion",     user_id=user_id, ) access_token = token_resp["token"]["accessToken"] ~~~ **What makes Notion setup with DCR so much easier?** With standard OAuth, you’d normally have to manually register a client with the provider, copy over a client ID and secret, and configure redirect URIs before anything works. DCR skips all that. The MCP client (or agent) simply sends a registration request to the MCP server’s registration endpoint at startup, and the server responds with a freshly issued client ID and secret on the spot. From there, the MCP client kicks off a standard OAuth flow, where the user authorizes access to their Notion workspace through a consent screen. Descope then stores that user’s token and brokers it on future requests, so the consent screen only shows up once. For MCP servers that support it, this makes OAuth setup much simpler while still keeping per-user authorization intact. ## Configuring the agent’s identity in Descope Before any agent can authenticate with your MCP server, you need to register that server in Descope, which gives the agent a verifiable identity to operate under. ### MCP server representation In your Descope project, go to **Agentic Identity Hub > MCP Servers** from the left sidebar and click **+ MCP Server**. Configure it as your `mh-agent-tools server`: ![Fig: Descope: MCP server configuration]() Add the following scopes and mark each as mandatory: `mcp:calendar.read` (connection scope: `https://www.googleapis.com/auth/calendar.readonly`), `mcp:weather_key.read`, and `mcp:notion.write`. These scopes enforce what each tool is actually allowed to do, and the agent cannot exceed them regardless of what it is asked. Scroll down to **Connection Information** and copy the **Discovery URL**, which follows this format: ~~~plaintext https://api.descope.com/v1/apps/agentic/{project_id}/{MCP_server_id}/.well-known/openid-configuration ~~~ ![Fig: Descope: MCP server discovery URL]() Set this as `DESCOPE_MCP_SERVER_CONFIG_URL` in your .env file. The agent uses it to dynamically register with Descope at startup and assume an agentic identity on behalf of the authorizing user. Each agent gets its own distinct [agentic identity](). So if ten users run and authorize the agent, you will see ten entries automatically appear under **Agentic Identity Hub > Agentic Identities** in your Descope project. ![Fig: Descope: Agentic identities]() > **Note:** These agentic identities only appear after you have run and authorized the agent for the first time for each user. ## Building the MCP server With the Descope MCP server configuration in place, you can now build the MCP server (`mh-agent-tools`) that exposes three tools: Weather, Google Calendar, and Notion. Each tool follows the same structure: validate the caller’s scope, look up the user’s credential from Descope’s Connections vault, and call the external service. If a credential is not stored yet (that is, if the required service is not connected and authorized), the tool does not fail. It returns an authorization link instead, so the user can connect the service and re-run without any changes to the code. The MCP server itself is built with [FastMCP](), which has native support for Descope as an auth provider. Wiring it up takes just a few lines: ~~~python # Initialize Descope auth provider to validate incoming tokens and identify users auth_provider = DescopeProvider(     config_url=DESCOPE_MCP_SERVER_CONFIG_URL,     base_url=MCP_SERVER_URL, ) # Create the MCP server instance with the Descope auth provider mcp = FastMCP("mh-agent-tools", auth=auth_provider) # ..... mcp.run(transport="http") ~~~ This MCP server uses `http` for transport, so the agent (or any other MCP client) must connect to it over HTTP. The AI agent (built with the Claude Agent SDK) calls these MCP server tools using a bearer [access token]() (a JWT). This token comes from Descope’s OAuth flow, completed once the user authorizes the agent. This MCP server logs the key steps during its execution, including credential retrieval (or a missing credential), and the success or failure of the response from the external service. These logs can then be audited to see exactly which user ran which tool. ### The weather tool Let’s take a look at the weather tool implementation: ~~~python @mcp.tool(auth=require_scopes("mcp:weather_key.read")) async def get_weather(city: str) -> str:     """Get today's weather for a given city using WeatherAPI.com.     Returns current conditions and temperature.     Args:         city: The city to get weather for.     """     logger.info(f"Inside get_weather...")     user_id = current_user_id()     try:         token_resp = descope_client.mgmt.outbound_application.fetch_token(             app_id="weather-api-key",             user_id=user_id,         )         api_key = token_resp["token"]["accessToken"]         logger.info(f"get_weather: Obtained weather API Key for user {user_id}: {api_key[:5]}...")     except Exception as e:         logger.exception(f"get_weather: Error fetching token for user {user_id}: {e}")         return (             "Weather API key not available yet. Open this link to add your "             f"Weather API key: {WEATHER_CONNECT_FLOW_URL}\n\n"             "Then re-run this request."         )     async with httpx.AsyncClient(timeout=CONNECTION_TIMEOUT) as client:         resp = await client.get(             "https://api.weatherapi.com/v1/current.json",             params={"q": city, "key": api_key},         )     if resp.status_code != 200:         logger.error(f"Weather API error for city {city}: {resp.status_code} - {resp.text}")         return f"Weather API error: {resp.status_code}"     data = resp.json()     logger.info(f"Weather data for {city}: {data['current']['condition']['text']}")     return (         f"Weather in {city}, {data['location']['country']}: "         f"{data['current']['condition']['text']}, {data['current']['temp_c']}°C"     ) ~~~ At the top of the function, `require_scopes("mcp:weather_key.read")` enforces that the calling agent’s session token carries the right scope before the tool execution. If the required scope is missing, the tool is hidden from the client’s tool list entirely rather than returning an error, so unauthorized users never even know the tool exists. The tool obtains the current user’s identity from the validated session token. This `user_id` ties the credential lookup in Descope to the right user. ~~~plaintext user_id = current_user_id() ~~~ **Path 1: credential found.** The tool calls Descope’s fetch_token with the connection ID (weather-api-key) and the user_id. If the user has already connected their WeatherAPI key through Descope, this returns it, and the tool proceeds to call the WeatherAPI endpoint directly. ~~~python token_resp = descope_client.mgmt.outbound_application.fetch_token(     app_id="weather-api-key",     user_id=user_id, ) api_key = token_resp["token"]["accessToken"] ~~~ **Path 2: credential not found.** If the user has not connected their WeatherAPI key yet, fetch_token raises an exception. Rather than failing with an error, the tool catches it and returns a Descope connect flow URL. The agent surfaces that link, the user opens it, adds their key, and re-runs the agent. ~~~python except Exception as e:     return (         "Weather API key not available yet. Open this link to add your "         f"Weather API key: {WEATHER_CONNECT_FLOW_URL}\n\n"         "Then re-run this request."     ) ~~~ **Note:** For a hosted flow to store the weather API key, download the [**Descope Weather API Flow**](), and import it into your Descope project’s [flows](). ### The Google Calendar tool The Google Calendar tool follows the same structure as the weather tool, with one key difference: instead of a static API key, it works with a user-specific OAuth token. ~~~python @mcp.tool(auth=require_scopes("mcp:calendar.read")) async def get_calendar_events(date: str) -> str:     """Fetch today's events from the authenticated user's Google Calendar.     Returns a list of upcoming meetings with their titles and start times.     Args:         date: The date for which to fetch events (in `YYYY-MM-DD` format).     """     .... ~~~ The `fetch_token` call looks identical, but because Google Calendar requires individual user authorization, the token is scoped to the user’s Google account. If the token is not available yet, the tool returns a Google OAuth authorization URL rather than a hosted Flow link. Once the user completes the OAuth authorization, Descope stores the token and handles refresh automatically on subsequent calls. You can find the full implementation of [**get_calendar_events(...)**]() in `mcp_server.py`. ### The Notion tool The Notion tool is structurally identical to the other two, but with two distinctions worth noting. First, the credential behind it was obtained through DCR instead of a manually configured OAuth app. Second, unlike the weather and calendar tools, which call REST endpoints directly, this tool connects to Notion’s [MCP server]() to create documents. ~~~python @mcp.tool(auth=require_scopes("mcp:notion.write")) async def create_notion_page(title: str, content: str) -> str:     """Create a page in Notion with a given title and content.     Use this to save a summary or checklist for upcoming meetings.     Args:         title: The title of the Notion page.         content: The body content of the Notion page (in Markdown format).     """     .... ~~~ From the tool’s perspective, the credential handling looks the same. The `fetch_token` call with `app_id="notion"` and the `user_id` returns the token just like the others. If the token is not available yet, the tool returns a Descope-generated OAuth authorization URL that takes the user through Notion’s consent screen. After authorization, Descope brokers the token on every subsequent request, and the agent can create and update Notion pages without ever handling the credential directly. You can find the full implementation of [**create_notion_page(...)**]() in `mcp_server.py`. ## Building the agent with Claude Agent SDK With the Descope Connections and MCP server tools already in place, the agent code itself stays minimal. It comes down to three steps: 1. Authenticate with Descope and obtain an access token for calling the MCP server’s tools. 2. Configure the local MCP server and the tools it exposes. 3. Run the agentic loop with a prompt that has the agent pull together the weather and calendar data and write the plan to Notion. You can examine the complete code implementation for the Claude-based agent here: [**run_claude_agent.py**]() ~~~python from claude_agent_sdk import ClaudeAgentOptions, ResultMessage, query async def main():     args = parse_args()     city_name = args.city     # Authenticate with Descope and get an access token for calling MCP server tools     access_token = await get_access_token()     today: str = datetime.now().strftime("%A, %d %B %Y")     prompt = (         f"Help me plan my day for {today}."         f"First, check the current weather in {city_name}. "         "If the Weather API key is not available, show an appropriate message with the link to add it, and do NOT proceed further.\n\n"         "...."     )  # Long prompt trimmed here for brevity     async for message in query(         prompt=prompt,         options=ClaudeAgentOptions(             mcp_servers={                 "mh-agent-tools": {                     "type": "http",                     "url": MCP_SERVER_ENDPOINT_URL,                     "headers": {"Authorization": f"Bearer {access_token}"},                 }             },             allowed_tools=["mcp__mh-agent-tools__*"],         ),     ):         if isinstance(message, ResultMessage) and message.subtype == "success":             print(message.result) asyncio.run(main()) ~~~ This `main` function ties everything together. The `city` argument comes from the command line and determines which city’s weather gets pulled into the plan. It starts by authenticating with Descope to get the access token your MCP tools will need: ~~~python access_token = await get_access_token() ~~~ The function `get_access_token()` comes from [**get_user_token.py**](), which handles the full DCR registration (client name: `MH-claude-descope-MCP-client`) and PKCE login flow with Descope on the agent’s behalf. The access token has the user identity and scopes embedded in it. Once a token is obtained, it is cached locally and silently refreshed on later runs, so the user only has to go through the browser login once rather than on every invocation. The corresponding agentic identity (representing the user) is created in Descope at this point. The prompt walks the agent through the planning task step by step: check the weather, fetch today’s calendar events, then combine both into a structured Notion page with a weather summary, schedule, focus blocks, and a priority to-do list. The prompt also tells the agent what to do if a credential is missing for any of the three tools: surface the authorization link, wait for the user to complete it, and ask for a re-run. That’s the graceful degradation pattern from the MCP server, reaching all the way up into the agent’s behavior. The query call is where the agent actually runs. The `mcp_servers` configuration points the agent at your local MCP server (running at: `http://127.0.0.1:8000/mcp`) and passes the Descope access token as a Bearer header on every request. This allows the MCP server (using Descope authentication: `mcp = FastMCP("mh-agent-tools", auth=auth_provider)`) to validate the agent’s identity on each tool call. The `allowed_tools` block restricts the agent to only the tools exposed by `mh-agent-tools`, so it cannot reach for anything outside that scope. ~~~python mcp_servers={     "mh-agent-tools": {         "type": "http",         "url": MCP_SERVER_ENDPOINT_URL,         "headers": {"Authorization": f"Bearer {access_token}"},     } }, allowed_tools=["mcp__mh-agent-tools__*"], ~~~ Finally, the agent runs as an async loop over `query`, streaming messages as it works. The code only prints output once it receives a `ResultMessage` with a `success` subtype, which is the final plan along with the Notion page URL. ## Agent demo: Obtaining credentials You need two terminals open in your project folder (`Descope-Claude-Agent`): one for the MCP server, one for the agent. ### Terminal 1 — start the MCP server ~~~bash source .venv/bin/activate python mcp_server.py ~~~ This serves the tools over HTTP at `http://127.0.0.1:8000/mcp` with a message like this: ~~~bash INFO Starting MCP server 'mh-agent-tools' with transport 'http' on http://127.0.0.1:8000/mcp ~~~ ### Terminal 2 — run the agent ~~~bash source .venv/bin/activate python run_claude_agent.py --city "Your City" ~~~ On first launch, `get_user_token.py` opens your browser for a Descope login using PKCE. You authenticate with an OTP sent to your email, then authorize the agent for the requested scopes (all scopes are marked mandatory in the MCP server configuration, so you cannot skip any). The consent screen looks like this: ![Fig: Descope: MCP server authorization]() Once you authorize and complete the login, the token is cached in `.cache/descope_credentials.json`, created automatically in your project folder, and silently refreshed on later runs so you do not have to repeat this step. ### Weather API key With the given prompt, the agent attempts to call the weather tool. Since the API key has not been added yet, the MCP server logs the failed lookup: ~~~bash get_weather: Error fetching token for user : {'status_code': 404, 'error_type': 'server error', 'error_message': '{"errorCode":"E152102","errorDescription":"Outbound app token not found"}'} ~~~ The weather tool returns `WEATHER_CONNECT_FLOW_URL` to the agent, which surfaces it to the user as a message like this: ~~~plaintext Agent Response: ------------------ The Weather API key is not available yet. Please add your Weather API key first before I can proceed with planning your day. **Action needed:** Click the link below to add your Weather API key: [**Add Weather API Key**](https://api.descope.com/login/{Descope-project-id}?flow=connect-weather-api-key) ~~~ Open this link in your browser. It takes you to the hosted Descope flow where you authenticate with your email and OTP, then save your API key. ![Fig: Descope: Store API key]() Once saved, you will see a confirmation: API key saved successfully!. This key is stored separately for each user inside the Descope connection, so even for paid services where every user brings their own key, credentials stay isolated and secure without needing separate environments per user. ### Google Calendar With the Weather API key now connected, re-run the agent. This time, it gets past the weather check but stops at Google Calendar, since that connection has not been authorized yet. The agent surfaces a Google OAuth authorization URL, generated by Descope, which takes you through Google’s own consent screen rather than a Descope-hosted flow. The screen clearly shows what the Descope connection is requesting access to. ![Fig: Google Calendar consent]() Once you complete the authorization, the OAuth token is stored in the corresponding Descope connection, and Descope handles refreshing it automatically whenever needed. ### Notion MCP Re-run the agent once more. With Weather and Calendar both connected, it now goes past those two checks but pauses at Notion, since that connection has not been authorized yet. Just like with Calendar, the agent surfaces an OAuth authorization URL generated by Descope, this time pointing to Notion MCP’s consent screen. The screen shows which workspace is being connected and exactly what permissions api.descope.com is requesting to take actions on your behalf. ![Fig: Notion MCP consent]() Notice the redirect URL on this screen: `https://api.descope.com/v1/outbound/oauth/callback`. This is the same Descope-managed callback pattern used for Google Calendar, just scoped to a different provider. Once you confirm and continue, the OAuth token is stored in the Notion Connection in Descope. Unlike the read-only Calendar scope, this authorizes Descope’s Notion MCP integration broadly. The agent can now create and update pages via Notion MCP in your workspace without ever holding that token itself. > **Note:** Each of these authorizations (Weather, Calendar, and Notion) is a one-time activity for a user. Once a credential is stored in its Descope connection, the MCP server retrieves it automatically on every subsequent run, scoped to the agent’s identity, without prompting you again. From this point on, simply running the agent takes you straight to the end goal: a complete daily plan, pulled together from your weather and calendar data, and written directly to Notion. ## Agent demo: Plan creation With all three credentials connected, a single run of the agent now completes the entire task end to end. Here is what that looks like from both sides. ### MCP server logs The server logs each tool call as it happens, including which user the credential belongs to and the outcome of the external call: ~~~bash 2026-06-19 16:03:11 [INFO] Inside get_weather... 2026-06-19 16:03:11 [INFO] get_weather: Obtained weather API Key for user U3Ot: 7ca... 2026-06-19 16:03:12 [INFO] Weather data for Pune: Partly Cloudy INFO:     127.0.0.1:47780 - "POST /mcp HTTP/1.1" 200 OK 2026-06-19 16:03:14 [INFO] Inside get_calendar_events... 2026-06-19 16:03:14 [INFO] get_calendar_events: Obtained access token for user U3Ot: ya29.a0... 2026-06-19 16:03:14 [INFO] Getting user's calendar events for: 2026-06-19T00:00:00-00:00 2026-06-19 16:03:15 [INFO] Fetched 3 events for user U3Ot. INFO:     127.0.0.1:53426 - "POST /mcp HTTP/1.1" 200 OK 2026-06-19 16:03:36 [INFO] Inside create_notion_page... 2026-06-19 16:03:38 [INFO] create_notion_page: Obtained access token for user U3Ot: 368d872... 2026-06-19 16:03:38 [INFO] Creating Notion page with title: Plan for: Friday, 19 June 2026 2026-06-19 16:03:46 [INFO] Notion page created: Plan for: Friday, 19 June 2026 at https://app.notion.com/p/38d6 ~~~ Three tool calls, three separate credential lookups, all tied to the same `user_id`, and all completing in under 40 seconds combined. ### Agent output On the agent side, the same run produces a complete, structured plan: ~~~plaintext Agent Response: ------------------ Your day plan is ready! Here's a quick summary: ### Weather in Pune **Partly Cloudy, 34.5°C** — It's a hot day. Stay hydrated, wear light cotton clothing, use sunscreen, and avoid the midday sun. ### Today's Schedule - **18:00** — Complete Descope+Claude article - **18:30** — Email Engineering Director about upcoming work - **19:00** — Dinner ### Focus Blocks Your calendar is clear until 18:00 — plenty of room for deep work. Suggested slots: 09:00-11:00, 11:15-12:30, 13:30-15:30, and 15:45-17:45. ### Top Priorities 1. Finish the Descope + Claude article (deadline 18:00) 2. Send the email to the Engineering Director 3. Quick review of next week's priorities 4. Hydrate, take breaks, and unwind by dinner ### Notion Page Your full plan has been saved here: **https://app.notion.com/p/38d6** Have a productive Friday! ~~~ This is what happened end to end: the agent first called `get_weather` for Pune, the tool retrieved the stored API key for this user, and got back a partly cloudy, 34.5°C reading. It then called `get_calendar_events`, this tool fetched the OAuth access token for the same user, and pulled three events for the day. With both pieces of context in hand, Claude reasoned over the gaps in the schedule to suggest focus blocks, then called `create_notion_page` to write the full plan, complete with weather precautions, the day’s timeline, and a prioritized to-do list, to a new Notion page. Every one of these three calls used a different credential type (a static key, an OAuth token, and a DCR-based OAuth token), fetched from Descope at the moment it was needed, and none of them ever touched agent code or configuration. Here is the corresponding Notion page that the agent created: ![Fig: Notion plan page]() This demo covers just one scenario built around three tools, but the underlying pattern is scalable. Once you have the right tools paired with secure, identity-aware access through Descope’s Agentic Identity Hub, agentic applications you build on top of it are only limited by your imagination. ### The audit trail The real payoff here is not the Notion plan itself, it is the *auditability*. In Descope, under **Agentic Identity Hub > Agentic Identities**, you can see the specific identity created for this user. Under **Audit and Troubleshoot**, you can see every authorization that took place, each tied to that identity and to the exact credential used to make the call. Every action the agent took is traceable to a specific user, every credential access is logged, and at no point did the agent code itself need to know or store a single secret. Here is how Descope’s **Audit and Troubleshoot** page looks: ![Fig: Descope: Audit and troubleshoot]() You can expand an individual log entry to examine the details. The screenshot above expands ‘Notion’ authorization, clearly showing the agent and user ID that authorized it. ## Wrapping up In this tutorial, you built a practical demo of a Claude-based AI agent with three tools. The agent operates under a defined identity instead of running anonymously. Secrets live in a vault and get retrieved at runtime instead of being scattered across config files and environment variables. Each tool enforces its own scope, so the agent only ever gets the access a given action needs. Every credential lookup and tool call is logged against a specific user, giving you a full accountability trail. None of this required you to build OAuth infrastructure from scratch or stand up a custom secrets store. Descope handled all of it. Descope is built for exactly this purpose. It is an identity platform for the agentic era, where the same infrastructure that handles human login through no-code [Descope Flows]() also extends cleanly to machine and agent identities. You set up a connect flow for a static key, brokered OAuth tokens for Google Calendar and Notion, and registered an MCP server’s identity, all from the same [Agentic Identity Hub](). As AI agents become more autonomous, unified identity and access control move from nice-to-have to non-negotiable. It is the very reason you can trust an agent in production. If you’re already building with the Claude Agent SDK, add Descope to your agent stack in minutes. [Start for free]() or explore the [Agentic Identity Hub docs](). --- ### [Passkeys vs. Passwords: What’s the Difference?](https://www.descope.com/blog/post/passkeys-vs-passwords) Compare passkeys and passwords on security, privacy, and user experience. Learn the key differences, when to still use passwords, and how to add passkeys. *Full content: [https://www.descope.com/blog/post/passkeys-vs-passwords.md](https://www.descope.com/blog/post/passkeys-vs-passwords.md)* A password is a shared secret you type, something that can be guessed, reused, or phished. A passkey is a cryptographic key pair tied to your device, something that can’t be guessed, reused, or phished the same way, because there’s no secret in transit for an attacker to catch. That’s the core difference between passkeys and passwords, and it’s why more apps are making the switch. In an ironic turn of events, Google announced its rollout of passkeys on World Password Day in 2023, proclaiming the “[beginning of the end of the password]().” Whether it’s because of passkeys or another form of passwordless authentication, experts tend to agree that apps on the internet need to move away from passwords. To understand what this shift means for apps, websites, developers, and end-users, it’s essential to grasp the difference between passwords and passkeys, along with the reasons why passkeys are considered superior. #### Main Points - **Passwords are familiar but flawed:** They remain the default login method because everyone knows how to use them, but they come with serious usability and security weaknesses. - **Passkeys solve those weaknesses:** By replacing memorized strings with device-based cryptography and biometrics, passkeys eliminate phishing risks, reduce user friction, and offer stronger privacy. - **The shift is already underway:** Tech leaders like Apple, Google, and Microsoft are rolling out passkeys as the new standard, meaning organizations and developers need to prepare for a passwordless future. - **Passwords still have a role:** Legacy systems, shared devices, and fallback scenarios mean passwords aren’t disappearing overnight, even as passkeys become the default for everyone else. ## Quick facts | **What a password is** | A shared secret, a string of characters you type, that’s checked against a stored hash on the server. | | **What a passkey is** | A cryptographic key pair tied to your device; the private key never leaves it, and a biometric or screen lock unlocks it. | | **Core difference** | A password is something you know and can be stolen or guessed. A passkey is something you have, and it can’t be phished or reused across sites. | | **Which is more secure** | Passkeys, resistant to phishing, credential stuffing, and brute force since there’s no shared secret to steal. | | **Can they be used together** | Yes; most organizations run both, with passkeys as the primary method and passwords kept as a fallback during the transition. | ## What are passwords? [Passwords]() are the oldest and most common method of logging into digital systems. A user creates a string of characters (letters, numbers, symbols) and provides it alongside a username to access an account. Here’s how it works behind the scenes: - The password is usually stored on the service’s server in hashed form. - At login, the user types their password, which the server hashes and compares against its stored value. - If the two match, access is granted. Passwords are simple and familiar, and that’s their biggest advantage. Everyone knows how to use them, and nearly every system in the world supports them. But they come with major drawbacks: - **Human factors:** Users often pick weak passwords, reuse them across accounts, or forget them entirely. - **Security risks:** Even strong, unique passwords can be stolen in breaches, guessed through [brute force](), or tricked out of users via [phishing](). - **User friction:** Managing dozens of credentials is frustrating and slows down the login process. In short, passwords are easy to implement and familiar to users, but their weaknesses make them one of the riskiest authentication methods still in use today. Unless it’s paired with other requirements in a [multi-factor authentication (MFA)]() flow, that is all a user, or cyber-attacker for that matter, needs to know to access sensitive data. **Read more:** [4 Safest MFA Methods & Flows to Implement]() ## What are passkeys? [Passkeys]() are a new form of [passwordless authentication]() that replace *something you know* (a password) with *something you have* (your device) and *something you are* (your [biometrics]()). A passkey never leaves the device it’s created on and is never sent to the server, which is the single fact that explains why passkeys resist phishing in the first place. Here’s how they work in practice: When a user sets up a passkey, their device (phone, laptop, tablet) generates two linked cryptographic keys: - A **private key** that never leaves the device and is protected by the user’s biometric or screen lock. - A **public key** that is safely stored on the service’s server. When the user tries to log in, the service sends a challenge request. The device uses its private key to sign that challenge, and the server verifies it with the matching public key. Because the private key never leaves the device, there’s nothing for attackers to steal or phish. And because the action usually requires a biometric check (like [facial recognition](), [fingerprint](), or a device PIN), only the rightful user can complete the login. In simple terms: with passkeys, you don’t need to type or remember anything. You just unlock your device as you normally would, and cryptography handles the rest in the background. ![How passkeys work during the authentication ceremony]() ## Passkeys vs. passwords At a surface level, passkeys and passwords serve the same purpose: verifying that the person trying to log in is who they claim to be. But the way they achieve that goal couldn’t be more different, and those differences have big implications for security, user experience, and implementation. Here’s how the two compare across the factors that matter most: | **Factors** | **Passkeys** | **Passwords** | | --- | --- | --- | | **Authentication** | Public key cryptography + biometrics/screen lock | User-entered string of characters | | **Security** | Resistant to phishing, credential theft, and impersonation | Vulnerable to brute force, phishing, reuse, and breaches | | **Convenience** | Fast, no memorization, device-based unlock | Requires remembering/typing, often frustrating | | **Implementation** | Newer, requires dev integration (but resources are growing) | Built-in support across all systems | | **Compatibility** | Moving toward cross-platform standardization | Universally supported today | | **Privacy** | Biometric data stays on device | Passwords stored server-side, at risk in breaches | | **Login Success Rate** | Higher success rates (63.8% in Google trials) | Lower success rates (13.8% in same trials) | ### Security Passwords expose organizations to some of the most common attack vectors, including phishing, credential stuffing, brute force, and large-scale breaches. Passkeys eliminate shared secrets entirely, which means there’s nothing for attackers to steal or reuse. For businesses, this translates directly into fewer breaches, lower remediation costs, and reduced compliance headaches. For example, [PayPal observed]() a 70% drop in ATO attempts after introducing passkeys. **Read More: **[**Using Passkeys to Prevent Fraud**]() ### Privacy With passkeys, biometric data never leaves the device. Only a cryptographic signature travels to the server, limiting exposure. Passwords, on the other hand, must be stored in centralized databases, which are prime targets in data breaches. ### User experience Passwords have long frustrated users with forgotten credentials, resets, and mistyped logins. Passkeys, by contrast, simplify the experience to a single biometric scan or device unlock. And the data is clear: - **Login success rates:** [Microsoft reports]() a 98% success rate with passkeys compared to just 32% for passwords. - **Speed:** Microsoft also found logins with passkeys are up to 8x faster than with passwords. - **Google’s early trials:** In 2023, [Google measured]() passkey logins averaging 14.9 seconds vs. 30.4 seconds for passwords. - **Adoption in practice:** [Authsignal analyzed]() one million authentication attempts and found passkeys used in 62% of flows, surpassing SMS codes. - **User perception:** A [2026 FIDO Alliance survey]() found that 90% of users were aware of passkeys, 75% had enabled passkeys on at least one account, and 40% had enabled passkeys on multiple accounts. For users, this means fewer headaches and faster access. For organizations, it translates into fewer helpdesk tickets, lower abandonment rates, and reduced fraud. The combination of smoother experiences and stronger security is a rare win for both sides. ### Implementation Passwords are nearly effortless to support because they’ve been the default for decades, but that simplicity comes with long-term costs: resets, fraud monitoring, and breach response. Passkeys once required more effort, but that’s changed. Thanks to standardized support across Chrome, Safari, Edge, Android, iOS, and Windows, organizations can now [implement passkeys]() with APIs and SDKs from providers like Apple, Google, Microsoft, and identity platforms like Descope. **Read more:** [Managing Passkeys on Apple, Google, and Microsoft Platforms]() ## When should you use passwords instead of passkeys? Passkeys are the better default, but passwords or a password fallback still make sense in specific situations: | **Scenario** | **Recommended** | **Why** | | --- | --- | --- | | Legacy systems and older browsers | Password (or password + MFA) | Systems that don’t support the WebAuthn standard can’t accept a passkey at all | | Shared or kiosk devices | Password | A device-bound credential is impractical when many people share one machine | | Account recovery and fallback | Password as a backup path | Users need a way back in if they lose the device holding their passkey | | Mid-migration organizations | Both, side by side | Not every user can switch at once, so passwords stay active during rollout | The practical takeaway is that most teams don’t choose one or the other. The ideal path is to offer passkeys as the primary method and keep passwords (or other auth methods) as a fallback until every user, device, and legacy system can support passkeys natively. ## How to add passkeys to your React / NextJS app If you’re searching how to add passkeys to a Next.js app specifically, the short answer is the same as for any modern web app. Passkeys are built on the FIDO2 and WebAuthn standards. In practice, that means a Next.js project, a React single-page app, or something else needs to register a credential when a user signs up and verify an assertion each time they log in. Most teams don’t implement WebAuthn from scratch. A customer identity platform like Descope adds passkeys through drag-and-drop workflows and SDKs, including a [React and Next.js SDK](), so registration and verification are handled without writing raw WebAuthn code. ## Passkeys and passwords together with Descope Passkeys outperform passwords across security, privacy, speed, and user experience. While passwords are familiar, they’ve long outlived their usefulness and the industry momentum behind passkeys makes their replacement inevitable. For organizations and developers, the question is no longer if you’ll adopt passkeys, but *when*. If you’re building an app or modernizing authentication, Descope makes the transition simple. With drag-and-drop workflows, SDKs, and APIs, you can [add passkeys]() (and even [keep passwords for fallback]() if needed) with just a few lines of code—no reinventing the wheel. [Sign up]() for a Free Forever Descope account and simplify your authentication while saving developer time. Have questions? [Book time]() with our experts. ![Fig: Passkeys flow]() ## FAQs --- ### [Descope vs Stytch: Comparisons and Use Cases](https://www.descope.com/blog/post/descope-vs-stytch) Compare Descope and Stytch for customer and agentic identity. See why teams choose Descope for unified B2C/B2B auth, self-service SSO, and predictable pricing. *Full content: [https://www.descope.com/blog/post/descope-vs-stytch.md](https://www.descope.com/blog/post/descope-vs-stytch.md)* Most modern apps need more than one type of authentication. For example, a single product might require an easy login for individual users, enterprise-level SSO and SCIM for business clients, adaptive MFA to prevent account takeovers, and now, a secure way for AI agents and MCP servers to act for users. Building all of this from scratch is a big responsibility. Stytch is a popular option for teams looking for developer-focused authentication tools. It provides strong APIs and SDKs for consumer authentication, B2B authentication, and, more recently, OAuth-based Connected Apps. However, Stytch uses a component-based approach. You get building blocks, and your engineering team puts them together, connects them to your authorization logic, and keeps them updated as your needs change. Descope does things differently. Rather than giving you separate components to connect, Descope offers a no / low-code workflow layer that brings together B2C, B2B, authorization, and agentic identity in one platform. This way, your team can build authentication once and update it through configuration instead of redeploying. In this post, we will compare Descope and Stytch in the areas that matter most as your product grows: consumer user experience, enterprise readiness, security, pricing, and AI-agent identity. **Also Read:** [A Complete Comparison of Descope and Stytch]() ## What to look for in a modern customer auth platform Whether you're serving individual consumers, business tenants, or both, a handful of capabilities separate a platform that scales from one that turns into a maintenance burden: - **Support different login form factors** - embedded, hosted, and native mobile flows, so login, signup, and MFA can match whatever experience your product needs. - **No/low-code workflow orchestration** - the ability to change login methods, MFA logic, and onboarding steps through configuration, not a code change and a deploy. - **Full passkey support with fallback logic** - not just raw WebAuthn, but day-one passkey support with graceful fallback for users or devices that don't support it. - **Adaptive, risk-based MFA**  - step-up authentication driven by real risk signals and pluggable fraud connectors, not just static rules. - **Real multi-tenancy for B2B** - tenant-aware roles, self-service SSO and SCIM setup, and delegated admin so enterprise customers can manage themselves. - **Unified authorization** - RBAC, ABAC, or ReBAC living in the same platform as authentication, not a bolt-on service with its own data model. - **Predictable pricing** - costs that don't spike as MAU, SSO connections, or MFA usage scale. - **Agentic and MCP-ready identity** - a purpose-built way to authenticate and authorize AI agents, not a repurposed OAuth client model. Platforms that check these boxes let you spend engineering time on your product instead of your auth stack. Here's how Descope and Stytch stack up against each one. ## User experience: Flexible journeys vs. code-heavy components ### Descope Descope puts user journey screens directly in your app, so users stay in one place without being sent to another page or encountering any awkward redirects. Alternatively, teams that prefer a dedicated login page can use Descope's hosted option, so the choice comes down to what best fits your product. On mobile, the same smooth experience works for both iOS and Android using an enhanced web view. - Journeys embedded natively in your app, no redirects - Hosted login option available for teams that prefer a dedicated login page - Native mobile flows for a near-native authentication experience - Fully brandable screens that match your product's look and feel **Also Read: **[**Embedded vs Hosted Login in Descope**]() ### Stytch Stytch provides auth components and SDKs rather than complete user journeys. That gives developers granular control, but without low-code flows or built-in orchestration, every UX iteration (a new step, a design tweak, a conditional path) becomes an engineering task. - Auth components and SDKs, not pre-built journeys - No low-code flow builder for assembling multi-step experiences - UX changes typically require frontend code changes and a deploy **Bottom line:** Stytch gives developers the building blocks to create a custom experience. Descope, on the other hand, provides a complete, embedded journey right away and lets you keep improving it without having to redeploy your app. ## User journeys & workflows: No / Low code orchestration vs. manual engineering ### Descope Descope lets you set up authentication as a configurable workflow rather than fixed code. With its visual[ Flows]() builder, teams can design, test, and update login, MFA, and onboarding journeys, including A/B tests, without touching backend code. - No-code visual workflows for auth, MFA, and onboarding - [A/B test auth methods](), onboarding paths, and geo-based logic without custom code - Add conditional branching based on user, device, or risk context - Modify journeys without redeploying your application - Broad SDK and API support for teams that prefer to build and manage auth in code ![Fig: Descope Flow Builder]() ### Stytch Stytch offers flexible login options through its SDKs and APIs, but it does not have a separate workflow layer. You need to build the full journey in your own application code. - Flexible login patterns via SDK/API - No visual workflow builder or orchestration layer - Multi-step journeys and conditional logic built and maintained in application code **Bottom Line:** Stytch enables flexible auth patterns, but teams still hand-build the journey around them. Descope's workflow builder turns that same work into configuration your team can change in minutes. ## Passkeys: Day-one native support vs. SDK-based WebAuthn ### Descope Descope has offered [passkey support]() from the start, with features like autofill, fallback logic, and A/B testing for adoption. You can use passkeys as either a first or second factor with any other authentication method. - Passkey support from day one, including autofill - Passkeys as a first or second factor with any other auth method - A/B test passkey rollout across your user base - Automatic fallback to another method if a device isn't passkey-compatible ### Stytch Stytch supports WebAuthn-based passkeys, but its SDK-based setup can be cumbersome and does not include built-in fallback logic. Development teams need to create the full passkey experience themselves, including checking device compatibility and setting up fallback options. - WebAuthn passkey support via SDK - No built-in fallback orchestration for incompatible devices - Full passkey UX and edge-case handling built by the development team **Bottom Line:** Both platforms support passkeys, but Descope treats fallback handling and rollout testing as first-class features. With Stytch, that logic is on you to build.[ Branch]() is a good example of how much that orchestration matters in practice — more on that below. ## MFA & fraud prevention: Adaptive, connector-driven vs. fingerprinting only ### Descope Every Descope plan includes MFA, with phishing-resistant options such as magic links and passkeys.[ Adaptive MFA]() relies on risk signals and third-party fraud connectors to determine when extra authentication is needed. All of this is managed in the same workflow builder used for login and onboarding. - MFA available on all plans, including phishing-resistant factors - Risk-based, adaptive MFA driven by real signals - Pluggable fraud connectors, including[ reCAPTCHA](), AbuseIPDB, [Forter](), and [Fingerprint]() - MFA logic lives in the same workflow as the rest of the auth journey ### Stytch Stytch provides several MFA options and built-in device fingerprinting. However, it does not support adaptive MFA or allow you to use external fraud or risk signals in its authentication flow. To use fraud signals for authentication decisions, you need custom integrations and manual setup. - Multiple MFA factors and device fingerprinting - No adaptive, risk-based MFA out of the box - No native fraud-connector ecosystem; external signals require custom integration **Bottom Line:** Stytch gives you MFA factors and fingerprinting signals; turning those into adaptive, risk-based decisions is custom work. Descope ships that logic and the connector ecosystem to power it. ## Multi-tenancy & enterprise SSO: One platform vs. a separate product ### Descope Descope is built tenant-first, so multi-tenancy, roles, SSO, and SCIM are core to the same platform used for consumer auth. The[ SSO Setup Suite]() lets tenant admins configure their own SAML/OIDC connections and SCIM provisioning, removing engineering from enterprise onboarding. - Tenant-first architecture built into the same platform as B2C auth - Self-service SSO and SCIM setup for tenant administrators - Tenant-aware roles and delegated admin controls - [Tenant-isolated users]() to support MSSP and white-label reseller models - Support for multiple identity providers per enterprise tenant ![SSO Setup Suite IdP selection]() ### Stytch Stytch's B2B authentication is a distinct product from its Consumer Authentication offering. Teams that need both must implement and maintain each separately, then stitch them together at the application layer. - B2B and Consumer Auth offered as separate products - Enterprise SSO and SCIM available, but as part of a distinct product surface - Teams needing unified B2C/B2B auth must integrate both products themselves **Bottom Line:** Stytch requires teams to run two products side by side for B2C and B2B. Descope unifies both in a single platform, so enterprise readiness doesn't mean a second integration. **Also Read:** [A Primer on B2B Authentication With Descope]() ## Authorization: Unified with auth vs. a separate concern ### Descope Descope unifies authentication and authorization on a single platform. Teams can manage [RBAC](), [ABAC](), and [ReBAC]() models, assign roles dynamically within authentication workflows, and enforce permissions using a low-latency [FGA cache](). No separate authorization service is required. - Built-in RBAC, ABAC, and ReBAC authorization models - Roles and permissions assignable directly from auth workflows - High-performance FGA cache for low-latency authorization checks - Centralized identity and authorization management ### Stytch Stytch supports RBAC, but authorization is not unified with journey orchestration. Assigning roles and permissions to specific authentication flows or conditional logic must be handled in application code. - RBAC available through the platform - Not integrated with a workflow/orchestration layer - Connecting authorization decisions to auth flows requires custom logic **Bottom Line:** Stytch offers authorization primitives; Descope ties authorization directly into the same workflows that handle login, onboarding, and MFA. ## Agentic identity & MCP auth: Purpose-built hub vs. a separate product surface ### Descope The[ Agentic Identity Hub]() provides AI agents and MCP servers with an OAuth-compliant identity layer, so you do not need to rewrite your downstream services. It covers all required features such as PKCE, client registration, consent, and token issuance, and allows agents to use the same sign-in flow as your users. - OAuth 2.1-compliant authorization layer purpose-built for agents and MCP servers - Handles PKCE, client registration, consent, and token issuance out of the box - Layers on top of your existing workforce / customer IdPs–no need to rebuild your identity stack - Unified with the same tenant, role, and authorization model as human users ### Stytch Stytch offers Connected Apps, which allow an application to act as an OAuth/OIDC authorization server for both first- and third-party clients, including AI agents. This is a strong building block, but it is separate from Consumer and B2B Auth. Connected Apps has its own client, scope, and consent model, which you need to integrate separately.  - Connected Apps supports OAuth/OIDC-based client and agent access - Implemented as a separate product surface from core auth - Requires its own integration for clients, scopes, and consent flows **Bottom Line:** Both platforms support agent-facing OAuth flows, but Descope's Agentic Identity Hub shares the same tenant and authorization model as your human users, while Stytch's Connected Apps is a separate surface to integrate on its own. ## Global compliance & enterprise readiness: Broad certifications vs. a narrower baseline ### Descope Descope is built to meet the compliance and deployment requirements of regulated industries and government agencies out of the box, without requiring a separate infrastructure project. - [FedRAMP High Authorized](), listed on the FedRAMP Marketplace - Multi-region data residency, including dedicated EU, Australia, and Canada data centers - SOC 2 Type 2 and ISO 27001 certified - HIPAA and GDPR compliant, plus CSA STAR Level 2 and PCI DSS certified ### Stytch Stytch covers foundational compliance certifications, but FedRAMP authorization and multi-region data residency aren't part of the platform today. - No FedRAMP authorization - No shipped multi-region data residency - SOC 2 and ISO 27001 certified - HIPAA/BAA available, but only on the Enterprise plan **Bottom Line:** Both platforms cover the compliance basics, but Descope's FedRAMP High Authorization and live multi-region data residency matter for regulated industries and government use cases where Stytch doesn't yet have an equivalent. ## Future-proofing: One platform vs. multiple products ### Descope Descope brings together B2C authentication, B2B enterprise features, authorization, and AI identity in one platform. When new needs arise, like a new authentication method or tenant type, you usually just adjust workflows instead of adding new integrations. - Unified platform for B2C, B2B, authorization, and AI identity - Workflow-driven architecture makes future changes low-risk - Extend capabilities without introducing new systems ### Stytch Stytch is up-to-date and easy for developers, but its B2C and B2B products are separate. New features like Connected Apps are also managed on their own. As your needs grow, your team may have to integrate and maintain several different products instead of just configuring one. - Strong, modern APIs across distinct product lines - B2C, B2B, and Connected Apps managed as separate products - Expanding identity needs typically mean additional integrations **Bottom Line:** Stytch's modular product lineup means your identity stack grows by addition. Descope's unified platform means it grows by configuration. ## Descope vs Stytch: At-a-Glance | | **Descope** | **Stytch** | | --- | --- | --- | | **User experience** | Embedded, native journeys + hosted login | Auth components, redirect-based | | **User journeys** | No-code visual workflows + A/B testing | Manually engineered flows | | **Passkeys** | Native, day-one, with fallback logic | SDK-based WebAuthn, no fallback orchestration | | **MFA & fraud** | Adaptive MFA + fraud connectors, all plans | Device fingerprinting, no adaptive logic | | **Multi-tenancy / SSO** | Unified platform, self-service SSO + SCIM | Separate B2B product | | **Authorization** | Unified RBAC/ABAC/ReBAC | Available, not unified with workflows | | **Agentic / MCP identity** | Agentic Identity Hub, shared tenant model | Connected Apps, separate product surface | | **Compliance & data residency** | FedRAMP High Authorized, multi-region residency, SOC 2/ISO 27001 | No FedRAMP, no shipped multi-region residency | ## Customer stories: Teams that chose Descope over Stytch Teams tend to move off Stytch when they need one platform to cover consumer UX, enterprise readiness, and increasingly, agent identity instead of three separate integrations.  ### You.com: B2C, B2B, and MCP auth under one roof You.com is an AI-powered productivity platform used by individual consumers, developer teams building on its API, and enterprises with strict security requirements. As the company grew, it needed to support consumer-grade sign-in and enterprise SSO without running them as two separate systems. Also, as its MCP server matured, it needed a way to bring AI agents onto the same identity layer. Descope let [You.com unify B2C authentication, self-service enterprise SSO, and fine-grained authorization (ReBAC) in one platform](), while migrating 6.5 million users with zero downtime and all user IDs preserved, using a custom migration script that processed 1,000 users every 1.5 seconds. You.com's MCP server now runs on Descope's [Agentic Identity Hub](), which handles OAuth 2.1, PKCE, consent, and token issuance so AI agents authenticate through the same sign-in flow as human users without requiring You.com to rewrite its API-key-based backend services. ### Branch: Drag-and-drop passkey auth that cut support tickets in half Branch Insurance, a cloud-native home and auto insurer, wanted to move to phishing-resistant MFA without ripping out its existing auth provider or user store, while meeting strict compliance requirements in a regulated industry. Descope's [workflow-based approach let Branch layer in passkeys]() alongside its existing authentication, with conditional logic that routed users to passkeys when their device supported it and to fallback MFA when it didn't, all without significant code changes. The results: 25% passkey adoption, a 50% reduction in auth-related support tickets, and steady login failure rates throughout the rollout. ### Fullbay: Enterprise-ready auth for the leading fleet repair platform Fullbay is the number one heavy-duty truck and trailer repair shop management platform in North America, serving repair shops, private fleets, and heavy-equipment service providers with a cloud-based system for managing service orders, technicians, and parts inventory.  Fullbay moved from Stytch to Descope for its authentication needs because they were seeking a platform that supported multi-tenancy as a first class primitive, had FGA capabilities, and provided native identity infrastructure for AI agents and MCP servers.  ## Migration: Moving from Stytch without disruption Migrating authentication infrastructure can feel risky, especially for applications spanning both consumer and enterprise users, where a login interruption or a broken SSO connection has an immediate, visible impact. A well-planned migration prioritizes continuity first, allowing teams to modernize identity without disrupting existing users or enterprise tenants. Descope supports both full replacement and phased migration for teams transitioning from Stytch. You can switch completely or implement Descope incrementally for features such as[ passwordless authentication](),[ adaptive MFA](), or enterprise SSO, while maintaining existing Stytch flows. - Replace Stytch fully or augment selectively based on your roadmap - Use the AI-powered[ Stytch-to-Descope migration skill]() to analyze your codebase, identify which Stytch surfaces are in use, and generate a reviewed migration plan for full or hybrid migrations - Use[ Session Migration]() to switch from Stytch without disrupting logged-in users - Use[ SSO Migration]() to move existing enterprise SSO connections to Descope without re-onboarding tenants - Use Descope as an OIDC Provider to augment Stytch deployments By using phased rollouts and standards-based federation, teams can avoid forcing users to re-authenticate or reset credentials during migration. Existing sessions remain stable, and authentication continues to function throughout the transition. ## Conclusion Stytch is a solid choice for teams that want granular, developer-first control and are comfortable assembling auth journeys, tying in authorization, and maintaining separate B2C and B2B products themselves. However, as products grow, that flexibility can become challenging. Users expect better experiences, enterprise customers want self-service SSO and SCIM, security standards require adaptive MFA, and AI agents need their own identity layer. Combining different Stytch products and custom code to cover all these needs can become complex and time-consuming. Descope is built to handle all of it from a single platform: B2C auth, B2B enterprise readiness, authorization, and agentic identity, with predictable pricing and a guided path to migrate. If you're evaluating Stytch or wondering whether your current auth stack can keep up with where your product is headed, now's a good time to take a look at Descope. [Book a demo]() with our auth experts, or [sign up for a Free Forever account]() and start building today. ## FAQs on Descope vs Stytch --- ### [The Descope MCP Server Is Available On Claude and ChatGPT](https://www.descope.com/blog/post/descope-mcp-server-claude-chatgpt) The Descope MCP Server is now available as a Claude Connector and a ChatGPT Plugin. Learn how to build and manage identity through an AI agent. *Full content: [https://www.descope.com/blog/post/descope-mcp-server-claude-chatgpt.md](https://www.descope.com/blog/post/descope-mcp-server-claude-chatgpt.md)* Hey Descopers! Earlier this year, we announced the [Descope MCP Server](), a hosted MCP server that gives agents the ability to read documentation, inspect your project configuration, manage users and tenants, configure authentication flows, review audit logs, and make changes to your identity infrastructure, all through natural language. Today, we're excited to share that the Descope MCP Server is now available as a [Claude Connector]() and a [ChatGPT Plugin]()! These listings give you a native way to connect to the Descope MCP Server using Claude and ChatGPT, saving you time and allowing your admin to configure the Descope MCP Server organization-wide. ## Bringing Descope to your AI agents Under the hood, the Descope MCP Server exposes **23 tools**, each named for the identity object or function it operates on.  By default, access is read-only, and Claude and ChatGPT can natively escalate and ask the user to elevate their permissions when needed.  | **Tool** | **Purpose** | **Access** | | --- | --- | --- | | **list_operations** | Discover the full operation catalog; list all operations by bucket, or fetch the input/output schema for a specific operation | Not applicable | | **session** | Manage session context: switch projects, check current identity, generate onboarding plans, and elevate to write mode | Not applicable | | **project_read** | View project configuration including JWT templates, lists, snapshots, and messaging localization | Read | | **project_write** | Update project settings, clone projects, manage JWT templates, lists, Descopers, and messaging localization | Write | | **access_control_read** | Query FGA schemas, roles, permissions, ReBAC relations, and run authorization checks and dry-runs | Read | | **access_control_write** | Create and update FGA schemas, roles, permissions, and relations; manage backups and resource details | Write | | **agentic_read** | View MCP server definitions, clients, and client secrets | Read | | **agentic_write** | Create, update, and delete MCP servers and clients; rotate client secrets | Write | | **audits_read** | Search audit events and analytics | Read | | **auth_keys_read** | View access key details and password settings | Read | | **auth_keys_write** | Create, search, and manage access keys; configure password settings; update JWTs; and impersonate users | Write | | **flows_read** | View flows, flow templates, themes, flow localization, and widgets | Read | | **flows_write** | Import and manage flows, themes, and flow localization; apply project themes | Write | | **tenants_read** | View tenants, tenant settings and SSO admin link state | Read | | **tenants_write** | Create and manage tenants, tenant settings, default roles and SSO admin links | Write | | **connect_read** | View SSO settings, IDP apps, inbound apps, outbound apps, and third-party apps | Read | | **connect_write** | Create and manage SSO applications (OIDC, SAML, WS-Fed), inbound/outbound apps, and SSO tenant settings | Write | | **tests_read** | Search test users | Read | | **tests_write** | Create and delete test users; generate test OTPs, magic links, and enchanted links | Write | | **users_read** | View user records, custom attributes, group membership, trusted devices, and auth history | Read | | **users_write** | Create, update, and delete users; manage credentials (passwords, passkeys, TOTP), and custom attributes | Write | | **docs_search** | Semantic search across Descope documentation and SDK references | Read | | **docs_ask_question** | Ask natural-language questions about Descope and get answers grounded in official documentation | Read | ## Supported platforms The Descope MCP Server listings currently support the following products natively: ### Anthropic - Claude.ai (Web Client) - Claude Desktop - Claude Cowork - Claude Code - Claude Mobile To add the Descope Connector for Claude, create a new conversation, then click the “Plus” button -> Connectors -> Add connector -> Browse connectors -> Search “Descope” to find the **Descope for Claude** connector. ![Descope Claude Connector]() ### OpenAI Connecting with OpenAI requires a valid Plus, Pro, or Team ChatGPT plan. The Descope MCP Server is available on: - ChatGPT.com (Web Client) - ChatGPT Mobile - ChatGPT Desktop - ChatGPT Work - Codex To add the Descope Plugin for ChatGPT, Go into Settings -> Plugins -> Browse Plugins -> Search “Descope”. To complete your MCP server connection with either Claude or ChatGPT, you’ll be directed through auth and consent journeys. If you already have a Descope account, you can select which tenant to grant access for. If you don’t have an existing Descope account, you can create one while you connect with the MCP server. ![ChatGPT Plugin MCP consent]() Outside of these native integrations, you can always connect the Descope MCP Server to an agent with ease. See our [documentation]() on specific guidance for agents outside of the Anthropic and OpenAI ecosystems. ## What’s next As an agent-ready identity provider, we’re always looking for ways to best enable AI agents on our platform. We’ll continue exploring native integrations, skills, and improvements to our MCP Server to best enable agents to help you continue to build moderns, smooth, and secure user and agent journeys in your applications. ## FAQs --- ### [Descope Named in the 2026 Gartner® Hype Cycle™ for Fraud and Financial Crime Prevention](https://www.descope.com/blog/post/2026-gartner-hype-cycle-fraud-financial-crime-prevention) Descope is a Sample Vendor in the 2026 Gartner Hype Cycle for Fraud and Financial Crime Prevention for CIAM for AI Agents and Journey-Time Orchestration. *Full content: [https://www.descope.com/blog/post/2026-gartner-hype-cycle-fraud-financial-crime-prevention.md](https://www.descope.com/blog/post/2026-gartner-hype-cycle-fraud-financial-crime-prevention.md)* On July 27, 2026, Gartner published its [Hype Cycle for Fraud and Financial Crime Prevention, 2026](), a research note that helps bank CIOs and fraud-prevention leaders prioritize the technologies shaping how they detect and stop financial crime. We're proud to share that Descope is listed as a Sample Vendor in two categories: CIAM for AI Agents and Journey-Time Orchestration. This is the second 2026 Gartner Hype Cycle to name Descope in both of these categories, following the[ 2026 Hype Cycle for Digital Identity]() published on July 6, 2026. Seeing the same two capabilities recognized in a report written for banking and fraud teams points to where the market is heading. In our view, agentic identity and journey-time orchestration are becoming central to how financial institutions fight fraud. Here is where Descope appears on this year's Hype Cycle: - Gartner places CIAM for AI Agents in the On the Rise phase, with an Emerging maturity level and a High benefit rating. - Journey-Time Orchestration sits at Early mainstream maturity, also with a High benefit rating. This inclusion follows [Descope’s Honorable Mention in the 2025 Gartner Magic Quadrant for Access Management](), continuing a year in which we have closely tracked Gartner’s guidance on agentic identity.  This blog will share our reflections on the two categories in which Descope is named, what the report says about each, and how we believe Descope continues to align with the direction charted by Gartner. ## How AI agents are reshaping fraud and financial crime The report frames a shift that we see across our own customer base. Real-time payments have raised transaction velocity, customers are beginning to experiment with agentic payments, and fraudsters are using the same AI tools that everyone else is. Bank CIOs now have to tell legitimate customers apart from bad actors in a world where a growing share of activity is initiated by software rather than a person at a keyboard. Gartner groups the report's innovations into four themes, and agentic AI is one of them. The report says: > "Banks must address the rise of autonomous AI agents that can initiate and execute payments and account actions on behalf of customers. They must secure the agentic transaction life cycle through tailored customer identity and access management (CIAM) for agents, strong authentication and authorization, device attestation, and continuous monitoring to detect compromised or malicious agents in real time." We believe the two categories where Descope is named map directly onto that guidance. CIAM for AI Agents covers the identity of the agent and the customer behind it, and [Journey-Time Orchestration]() is how banks assess and act on risk at each step of a session. Our reading is that the two reinforce each other. Stopping[ account takeover]() in an agentic world depends on securing agent identity, and securing agent identity at scale depends on orchestrating risk across the journey. Nowhere is this better explained than the OWASP Top 10 for Agentic Applications: each threat description cites at least one identity-related mitigation. [Read our full analysis of the OWASP recommendations]() and see how Descope addresses every threat to agentic applications. ![OWASP Agentic Top 10 Screenshot]() ## CIAM for AI Agents in a fraud-prevention context CIAM for AI Agents is a new entrant on this year's Hype Cycle, with a High benefit rating and Emerging maturity. The category name is Gartner's, and in our view it describes the extension of[ customer identity and access management (CIAM)]() beyond human users to the AI agents acting on their behalf. Gartner defines the category this way: > "Customer IAM solutions are engineered to manage diverse, large-scale customer identities and ensure a frictionless digital experience. Cybersecurity leaders must adopt IAM capabilities to securely manage AI agent identities in customer-facing contexts given the emergence of use cases where customers send AI agents to interact with organizations." For a banking or fraud audience, the stakes are concrete. The report ties weak agent controls straight to fraud loss and data exposure. Gartner says: > "CIAM for AI agents ensures that businesses stay competitive as customers increasingly expect engaging UX such as AI-agent-based chatbots and shopping assistants. Furthermore, as customers begin to use their own AI agents for tasks such as purchases or account management, businesses that cannot securely and seamlessly support this agent activity risk missing out. A lack of effective CIAM controls for AI agents exposes businesses to account takeover risks, theft of sensitive data and poor CX." The core technical challenge, according to the report, is delegation with binding. Gartner says: > "Use of AI agents in customer-facing scenarios presents a range of cybersecurity challenges that will need to be addressed using CIAM for AI agents. These include managing authentication and authorization mechanisms, delegating access from customers to AI agents, and verifying the identity of customers behind AI agents and being able to bind the two securely. Prevention of account takeover will be a key priority in a customer agentic context." We built the[ Descope Agentic Identity Hub]() to solve exactly this. Customers authorize agents through[ OAuth 2.1-based]() consent flows, each agent receives its own short-lived, scoped credentials linked back to the authorizing user, and the credential vault ([Descope Connections]()) keeps raw user credentials out of the agent's hands. Because every agent action traces back to the customer who authorized it, a bank can scope, audit, and revoke that access, which is the foundation for preventing account takeover in agentic sessions. ![AI agent connection templates for credential management and storage]() Consent is a first-class concern in the report, and the example Gartner uses lands squarely in financial services. Gartner says: > "As AI agents from service providers begin to interact with customers, these systems must incorporate consent management models that allow users to maintain trust by determining the scope and limits of an agent's actions. For example, a user might grant an AI agent permission to access certain customer data for personalized recommendations but restrict it from handling sensitive financial information." The report is candid that fine-grained authorization at scale is still hard. Gartner says: > "The challenge of balancing trust, cybersecurity, and CX is complex. Managing the fine-grained authorization needed for customer interactions (e.g., 'You can book flights to here, but not to there') without constant prompts to users for permission has yet to be demonstrated at customer scale." These are the problems the Agentic Identity Hub was designed around. Agents are managed as first-class identities with their own attributes, including their associated user, tenant, and granted scopes. Teams get flexible agent registration through pre-registration,[ Dynamic Client Registration (DCR)](), and[ Client ID Metadata Documents (CIMD)](), a[ policy engine]() that reads user, tenant, and JWT claim context, per-agent and per-tool scopes, and[ scope-aware step-up authentication]() for sensitive operations. That combination is how "book flights here but not there" becomes a policy rather than a prompt on every action.  **Read more: **[**AI Agent Credential Management Best Practices**]() ![Agentic Identity Management with the Descope Agentic Identity Hub]() On the build-versus-buy question, the report's recommendation is direct. Gartner says: > "Look to vendor-provided capabilities rather than attempt to build CIAM tooling in-house in order to manage costs and demands on resources. In the first instance, evaluate whether your existing CIAM vendors can meet requirements to support agent interactions. If your incumbent CIAM vendor is incapable, look for a dedicated vendor that can manage the agent interactions and integrate with your incumbent platform." Alongside familiar CIAM requirements, banks now face niche infrastructure like DCR, CIMD, consent management, per-agent scopes, and[ Model Context Protocol (MCP)]() authorization flows. In our experience, few teams want to become an identity company on top of running a bank, and the agentic era raises that bar further. ### Production-ready agentic identity Gartner places CIAM for AI Agents early in its journey, but the Agentic Identity Hub is already production infrastructure. It powers hundreds of MCP servers and millions of agentic transactions today. A few of the teams running Descope agentic identity in production: - [You.com]() protects their MCP server with OAuth 2.1, secure client registration, and token management, without rewriting their backend APIs. - [WisdomAI]() took MCP auth from concept to production in roughly a day and a half, freeing their team to focus on core AI capabilities. - [Token Security]() extended the same roles and tenants that govern human access to control what AI clients can do on their MCP server. That work is why Descope was named a Leader in the[ 2025 Frost Radar for Non-Human Identity Solutions](), and why we remain one of the few CIAM platforms with native MCP and AI agent identity support built in rather than bolted on. ## Journey-Time Orchestration for risk across the customer journey Journey-Time Orchestration (JTO) appears at Early mainstream maturity with a High benefit rating, which reflects a discipline that has proven its value and is heading toward broader adoption. This is familiar territory for us. Descope was also named for its JTO capabilities in the[ 2025 Hype Cycle for Fraud and Financial Crime Prevention](), so this is a category where we have tracked Gartner's guidance across multiple reports. Gartner defines JTO this way: > "Journey-time orchestration (JTO) solutions improve risk management along digital user journeys and deliver optimized user experience (UX). Most organizations manage multiple identity verification, authentication and account takeover (ATO) prevention tools, and adjacent capabilities such as user registration. A JTO solution manages the integration of these tools, simplifies assessment of risk at each event in the journey, and facilitates tailored and risk-appropriate UX delivery." Most identity stacks accumulate separate tools for identity verification, authentication, account takeover (ATO) prevention, and registration, and by default none of them talk to each other. Risk gets assessed at isolated checkpoints instead of as a continuous stream, with one blunt threshold applied to every user. Gartner describes why that becomes a problem for fraud teams: > "Securing digital user journeys and offering strong UX is the foundation on which digital transformation is built. Organizations without available developers struggle to manage the broad range of capabilities that this requires, including identity verification, user authentication, user registration, ATO prevention, service resilience and A/B testing." [Descope Flows](), our visual workflow builder, is Journey-Time Orchestration plugged natively into a CIAM platform. In our view, this is one of the main drivers behind our inclusion as a Sample Vendor. ![Creating a New/Existing User condition on the flow canvas]() The report describes the JTO layer as the connection between risk analytics and the user interface: > "Security teams and app developers are both seeking more tailored, risk-appropriate UX, which is easier to achieve with a JTO solution due to the fine-grained user journey control intrinsic to such solutions. The JTO solution optimally acts as the connective thread between the analytics solutions and the UI layer to reduce fraud risk while enabling a great UX." Flows weaves risk data from[ 50+ third-party connectors]() directly into the journey, including signals from[ Forter](),[ Fingerprint](), and[ reCAPTCHA](), so a suspicious session can be challenged or blocked on combined intelligence rather than a single vendor's score. Because Flows is a cornerstone of the platform rather than an acquired add-on, journey logic, risk assessment, and auth methods share one control plane. The report also calls out A/B testing as a driver of JTO adoption. Gartner says: > "The need to facilitate A/B testing in DevOps is pushing the adoption of JTO. Optimization of a risk management strategy is facilitated by a strong JTO platform in the form of A/B testing. For example, traffic could be split across two different identity verification vendors to assess which delivers better conversion rates." Descope Flows lets teams[ visually A/B test user journeys]() with phased rollouts, so a bank can measure which verification path delivers better conversion and lower fraud before committing to it.  ![Fig: A/B testing flow]() The report's final user recommendation on JTO says: > "Distill the complexity of managing multiple vendor integrations by leveraging a JTO solution to deliver a marketplace of readymade connections to identity verification, authentication and ATO prevention solutions." Descope ships[ 100+ best-practice journey templates]() and the connector ecosystem to back them, so teams assemble journeys from ready-made building blocks instead of custom integration code. Teams can modify user journeys without touching their codebase, all while staying in sync through CI/CD integrations ([GitHub](), [GitLab](), [Terraform](), [Pulumi]()) for software development life cycle (SDLC) alignment. ### Orchestration at consumer scale Descope Flows is proven in the market; thousands of organizations run Descope in production, managing hundreds of millions of identities. The vast majority of them use Flows to orchestrate their user journeys.  Two examples from financial services and adjacent sectors: - [Branch Insurance](), a cloud-native home and auto insurer, augmented its existing auth with phishing-resistant passkeys using Flows, routing users to passkeys where their hardware supported them and to fallback MFA where it did not. Branch reduced authentication-related support tickets by 50% while meeting compliance requirements for its 12,000+ independent agents. - [GoFundMe](), which processes tens of millions of donations a year, moved from a homegrown system to workflow-based journeys, wiring in reCAPTCHA for login risk detection and migrating millions of users with no disruption through just-in-time migration. ![GoFundMe Login Screen 2026]() ## How Descope aligns The table below maps themes from the two categories where Descope is listed to the platform capabilities that, in our view, address them. | **Hype Cycle Theme** | **How Descope Aligns** | | --- | --- | | Delegating access from customers to AI agents and binding the two securely | • OAuth-based consent and delegation • Agents receive short-lived, scoped credentials tied to the authorizing user, with raw tokens kept in Descope Connections | | Managing authentication and authorization mechanisms for agents | • AI agents managed as first-class identities with their own attributes: associated user, tenant, and granted scopes • Flexible agent registration (pre-registration, DCR, CIMD) and grant support (authorization code, client credentials, JWT bearer) • Per-agent and per-tool scopes • Policy engine with user, tenant, and JWT claim context | | Account takeover prevention across agentic and human contexts | • Adaptive MFA based on journey logic • Native risk factors like impossible traveler and trusted device • Third-party risk connectors (Forter, Fingerprint, reCAPTCHA) | | Reducing the complexity of multiple vendor integrations along the user journey | • Native Journey-Time Orchestration implementation (Descope Flows) unifying actions across frontend and backend • 100+ journey templates • 50+ third-party connectors | | A / B testing to optimize risk strategy and conversion | • Visual A / B testing of user journeys with phased rollouts • Journey-time analytics dashboard to show step-by-step conversions and dropoffs • CI / CD integrations for SDLC alignment | ## What the Hype Cycle for Fraud and Financial Crime Prevention means for Descope We feel this Hype Cycle is a valuable resource for banking and fraud leaders deciding where to invest as AI agents reshape financial crime. Being listed as a Sample Vendor in both an emerging category and a maturing one is, in our view, a signal that Descope's approach fits where financial services is heading: build for the customer agentic era that is arriving, on orchestration foundations that are already proven in production. That production track record matters most in regulated environments. More than 1,000 organizations run Descope today, and the platform is backed by SOC 2 Type II, ISO 27001, and FedRAMP High authorization, the kind of assurance a bank CIO needs before moving auth off custom code. If you're interested in trying out Descope, sign up for a Free Forever account. If you have an active project for[ fraud prevention](), customer identity, or agentic AI and MCP systems,[ book a demo]() with our auth experts to learn more. ## FAQs --- *Gartner, Hype Cycle for Fraud and Financial Crime Prevention, 2026, By Vatsal Sharma, 27 July 2026.* *GARTNER is a registered trademark and service mark of Gartner, Inc., and/or its affiliates in the U.S. and internationally, and HYPE CYCLE is a registered trademark of Gartner, Inc. and/or its affiliates, and are used herein with permission. All rights reserved.* *Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner's business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.* --- ## Customer Stories ### [Elementor Customer Story | Descope](https://www.descope.com/customers/elementor) Learn how Elementor, the world’s leading WordPress website builder, uses Descope to deliver managed authentication while preserving their pixel perfect design. *Full content: [https://www.descope.com/customers/elementor.md](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](). --- ### [Linktree Customer Story | Descope](https://www.descope.com/customers/linktree) Learn why the category-leading link-in-bio platform chose Descope to modernize and scale authentication for over 70 million users. *Full content: [https://www.descope.com/customers/linktree.md](https://www.descope.com/customers/linktree.md)* **[*Linktree*]()* is the category-leading link-in-bio platform with a global community of over 70 million Linkers including content creators, businesses, and influencers sharing everything they are in one simple link. Seeking an identity solution that better aligned with their scaling needs, Linktree’s engineering team began a path toward migration. Here’s how Descope helped Linktree migrate tens of millions of users while freeing their developers to focus on what really matters: empowering creators and businesses.* --- ## About Linktree Founded in 2016, Linktree is the platform that solved social media’s most frustrating challenge: only having one link in your bio. Today, with over 70 million users worldwide, Linktree helps creators, businesses, publishers, influencers, and artists better control their online presence, making their content more shareable, discoverable, and more likely to convert. ## The challenge of stagnant identity Linktree desired an identity solution that could meet their scaling needs. As Linktree’s user base grew, they faced the following challenges: - **Pricing not aligned with value: **The cost for Linktree’s burgeoning user population had escalated well beyond what their team felt they were getting in return. - **Rate limits impacting creators: **Despite the premium they paid, Linktree hit rate limits regularly, causing authentication failures that affected real creators and businesses and their audiences. - **Building and maintaining custom auth: **Linktree previously had to build and maintain their own user management layer, construct outbound connections for social platforms manually, and write custom rules to handle authentication logic. Zachary Lin, Senior Software Developer at Linktree, said: > “Obviously, hitting rate limits that affected users led us to reassess our strategy. The bigger issue was building and maintaining custom auth infrastructure—tying up engineering resources and leading to a highly complex architecture.” ## The Descope experience Linktree was initially drawn to Descope by a shared “builder philosophy”: both valued developer-first experiences, believing that tools made for engineers shouldn’t stagnate or fall into a holding pattern. ### Zero-downtime migration at scale With tens of millions of users and years of homegrown workarounds, Linktree’s migration called for thoughtful implementation. Descope was replacing an entire identity stack that Linktree had been investing in for years, and it was essential to retain their investment. Highlights of the migration: - **Bring Your Own Screen (BYOS) **allowed Linktree to keep the authentication UX they’d put so much time and effort into. Using Descope’s[ BYOS]() approach, their user-facing screens remained identical while the backend was replaced with[ Descope Flows](). - **Flows replaced custom rules **in a move that gave Linktree the flexibility of visual, drag-and-drop workflows. The custom JavaScript logic previously required would no longer slow their engineering-heavy team down; they could iterate faster, without touching application code. - **Full user migration **took place gradually, transitioning their entire user pool to Descope and eliminating the parallel user management layer they’d previously maintained. - **Arkose Labs fraud prevention **was a service Linktree had previously leveraged. Descope built an[ Arkose Labs connector](), enabling Linktree integrate fraud signals derived from the service directly into their Flows and trigger actions based on risk scores. - **The auth methods and flows users knew **were recreated in Descope,** **matching their former provider (but with all the advantages of the Descope ecosystem). Creators and businesses authenticate on Linktree using a variety of methods: passwords (which can be securely reset using[ magic links]()), passwordless[ OAuth social login](), and[ email one-time passwords (OTPs)](). - **Multi-factor authentication **with SMS OTPs and[ authenticator app TOTPs]() allow creators and businesses to add an extra layer of security to their accounts. Users can choose between text-message based OTPs or use the authenticator app of their choice (Google Authenticator, Authy, 2FAS). ![Linktree login page]() Zachary Lin, Senior Software Developer at Linktree, said: > “We were skeptical about Descope Flows at first. Many dev-focused tools can limit velocity for more experienced teams. But when we saw how fast it can move, without any unnecessary hand-holding, we were fully bought in.” ### Outbound connections and token management Beyond the core migration and authentication use case, Linktree is using Descope’s[ Outbound Apps]() to manage the token lifecycle for connections to third-party applications. Because Linktree helps creators and businesses share everything they do across the internet, that means connecting external platforms like YouTube, Instagram, X, and TikTok so they can pull in their latest content automatically. Each connection requires OAuth token management: consent flows, token exchange, secure storage, and refresh. Linktree had built all of this themselves, one provider at a time, and maintaining it as APIs changed became a constant drain on developer time. As an out-of-the-box capability for Descope, it replaces yet another piece of homegrown infrastructure Linktree had been obligated to create. ## Building better identity experiences for creators and businesses Linktree’s Descope implementation meets all the goals that drove the migration: - **Engineering time reclaimed: **Linktree no longer maintains parallel user management, custom OAuth connections, or JavaScript rules. That identity infrastructure now lives in Descope, where it can be maintained with fewer resources than before. - **Reliability at massive scale: **The rate limit issues that caused consistent authentication failures for end users are no longer a concern. - **Preserved frontend/UX investment: **BYOS let Linktree keep the authentication experience they’d worked so hard to build while completely replacing the backend. Zachary Lin, Senior Software Developer at Linktree, said: > “We had immediate, real-time access to engineers with Descope’s team, who were already ready to resolve edge cases quickly. Descope made support easy, and they were responsive whenever we reached out.” As Linktree continues empowering creators and businesses to share everything they are with the world in a single link, Descope provides the identity infrastructure that empowers their engineering team to deliver the best experience possible. Moving forward, their developers can focus on building the things that make Linktree great, rather than on maintaining authentication workarounds. Robert Erdin, VP of Engineering at Linktree, said: > “Descope is a true design partner to our CIAM team. We value the simplicity of their platform, the speed at which they ship product innovations, and their responsive, hands-on support. Their ability to move quickly and collaborate closely has helped us accelerate product development without compromising on quality.” --- Descope is a flexible [drag & drop CIAM 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](). --- ### [You.com Customer Story | Descope](https://www.descope.com/customers/you-com) You.com needed a solution to simultaneously meet their B2C, B2B, and MCP authentication needs, and this is how Descope helped them build it. *Full content: [https://www.descope.com/customers/you-com.md](https://www.descope.com/customers/you-com.md)* **[*You.com*]()* is an AI-powered productivity assistant used by millions of consumers and businesses. As the company evolved from a personalized search engine into a multifaceted GenAI platform, they faced a dilemma: How do you deliver the experience individual developers and users crave while enforcing the security that enterprises demand? You.com needed a solution to simultaneously meet their B2C and B2B authentication needs, and this is how Descope helped them build it.* --- ## About You.com Founded in 2020 by Salesforce veterans, You.com has consistently pushed the AI envelope. The company began with the idea for a more personalized search platform, one that more readily understood user intent and preferences. Seeking to solve the problem of both AI hallucinations and restrictive knowledge cutoffs (both of which result in unreliable output), You.com connected LLMs to live web data with verifiable citations. In September 2025, You.com [closed a Series C funding round of $100 million at a $1.5 billion valuation](), cementing the market’s appetite for an accurate, AI-powered search and productivity engine. Saurabh Sharma, You.com Chief Product Officer, said: > “You.com is an AI-powered productivity engine that anyone—individuals and organizations—can use to tailor the latest LLMs (Large Language Models) for any task. Our customizable AI assistants support countless use cases, from personal research projects to large-scale content generation.” The company serves diverse stakeholders through their platform: - Individual users who directly access the You.com chat interface for AI-powered web search - Developers and teams who leverage the API to build agents and applications - Partners and enterprises with You.com AI solutions who need robust security options Creating a personalized experience for every type of user was paramount. Yet, because You.com served such distinct audiences, they needed an authentication solution that could cater to expectations that are often at odds: strong, fully featured security and a frictionless user experience.  As their platform continued to evolve in the B2B space, their need for enterprise-grade authentication features grew. Implementing single sign-on (SSO), multi-tenancy, and more robust security quickly became core concerns as they sought a new, comprehensive solution. They also sought fine-grained authorization (FGA) to provide more complex permission models, which would allow their business customers to moderate access to tools and data with unparalleled specificity. ### When the worlds of B2B and B2C collide Now equal parts consumer product and enterprise solution, You.com found themselves straddling two worlds, each with distinct authentication needs. Individual users were looking for a quickfire, friction-free experience, and enterprise clients required ironclad security with robust SSO capabilities. Saurabh said: > "We wanted B2B and B2C authentication as a combined solution, not two separate products—similar to how You.com supports both businesses and individuals. We needed strong security and SSO for enterprise customers, and we wanted to maintain our existing consumer authentication experience for consumers. However, the real challenge was achieving all of this without disrupting our current user base." The evaluation criteria for a new solution became clear: seamless B2C and B2B integration, advanced security features like bot protection, easy migration capabilities, and developer-friendly implementation with top-tier support. Most importantly, You.com needed a platform that could maintain their carefully crafted user experiences while adding enterprise-grade security. Their existing auth provider could only support both B2C and B2B use cases as totally separate products, requiring a complete rebuild of the You.com authentication stack. However, the company wasn't willing to redo their auth from the ground up—which is what led them to Descope. ## The Descope experience Descope offered You.com enterprise-ready and consumer-friendly options that ticked crucial boxes: a [drag & drop workflow editor](), [self-configurable SSO]() for enterprise customers, adaptive MFA, and hands-on support. By unifying both sides of their authentication, they could significantly lower the total cost of ownership and reduce the engineering cycles spent on identity management. You.com wanted to keep their existing B2C identity journey intact, including branding and auth methods. Thanks to Descope's limitlessly customizable styles and broad authentication options—including those You.com previously deployed for B2C customers—they were able to migrate 6.5 million users without disrupting or changing the end-user experience. ![You.com Login]() ### Seamless migration to Descope The implementation process proved surprisingly simple for such a complex challenge. Descope's support team provided a custom migration script template that enabled batch processing from their previous provider, achieving a migration speed of 1,000 users every 1.5 seconds. More importantly, You.com maintained all user IDs and experienced zero downtime during the entire process. The technical implementation delivered immediate results: - Flows for email OTP and social login with Apple/Google - Self-service SSO configuration for enterprise clients - Seamless integration with Next.js 14 infrastructure - FGA in the form of [ReBAC (Relationship-Based Access Control)]() David Li, You.com Senior Software Engineer, said: > "The migration went remarkably smoothly. We maintained all user IDs and experienced no downtime during the bulk migration. Descope's support was engaged with our team from the start, making what could have been a months-long project into a straightforward operation." ### Fine-grained authorization at scale The platform includes AI assistants and projects that must be accessible to different users at different permission levels, all within the context of organizations, users, teams.  Using ReBAC, You.com can define access based on how users relate to these resources and to each other: - A user who created an assistant or project owns it and has full control - Teams exist within organizations, and a project can be shared with an entire team - Organization-level super admins inherit administrative access across the teams beneath them - Permissions are inherited through relationships: if a team has edit access to a project, its members do, too With RBAC alone, You.com would need to create roles for every combination of user type, team, and resource. Instead of granting all members of a team access based on their relationship to the *team*, RBAC roles would have to be designated with specific permissions.  ReBAC lets You.com model these access controls as relationships (ownership, team membership, organizational hierarchy) without setting up countless roles before query time. ### AI agents on the same identity layer You.com’s MCP server gives AI agents a standardized way to tap into the platform’s search, content extraction, and research tools. The initial remote server supported API key authentication, which was functional but required each user to manually provision and distribute keys. You.com wanted to add OAuth 2.1 as an automated option. However, because You.com’s API tier expects API keys, their team would need to rewrite every service to accept OAuth tokens.  [Descope’s Agentic Identity Hub]() sits in front as the OAuth-compliant authorization layer, handling the [spec-mandated pieces]() like PKCE, client registration, consent, and token issuance. On the back end, Descope provisions and stores an API key per user in [Descope Connections](). When a tool call arrives, the MCP server validates the user’s OAuth token, retrieves the associated key from Connections, and calls the downstream API. The agent only ever holds an OAuth token, which makes consent revocation simple. Agents now connect to the You.com MCP server through the same sign-in flow that users see on the website, and any MCP client that supports OAuth 2.1 handles the authorization automatically.  ### To unifying authentication, and beyond! The impact on You.com operations has been significant. Enterprise customer onboarding that usually requires extensive engineering support now happens through self-service workflows, dramatically reducing both implementation time and support overhead.  Processes that typically chiseled time from the engineering roadmap could now be accomplished in a single call, with You.com business customers configuring their own SSO through a guided interface. Built-in OAuth and bot protection meant they enjoyed resilient security out of the box, while Descope Styles allowed You.com to offer a fully customizable, white-labeled experience for each enterprise customer. David said: > "We love Descope SSO flows from a CX standpoint. A customer we onboarded just told us it was the fastest implementation ever. It usually takes weeks but we were done in 15 minutes— small talk included!" Today, organizations readily leverage the FGA options available in the You.com platform for granular, relationship-based access. Over a million You.com FGA queries are processed every day, securely enforcing user permissions for an increasing number of enterprises. Moreover, the simplified authentication process has improved the experience for both individual users, developers using the API, and business customers—a win-win that perfectly aligns with their mission. Saurabh said: > "By unifying our B2C, B2B, and MCP identity under Descope, we've built a foundation that can scale with enterprise customers while maintaining the simplicity and AI-readiness consumers expect. We now have an authentication system that aligns with the unique security and UX needs of businesses, individuals, and AI agents." --- Descope is a flexible [drag & drop CIAM 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 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 --- ### [Descope Named to Rising in Cyber 2026 List of Top Cybersecurity Startups](https://www.descope.com/press-release/rising-in-cyber-2026) CISO-Voted List Recognizes the 30 Private Cybersecurity Companies Shaping Enterprise Security in the Age of AI. *Full content: [https://www.descope.com/press-release/rising-in-cyber-2026.md](https://www.descope.com/press-release/rising-in-cyber-2026.md)* ***Los Altos, CA***** — May 12, 2026 —**[Descope]()*, *a leading customer and agentic identity platform, today announced its inclusion in Rising in Cyber 2026, an independent annual list launched by Notable Capital to recognize the 30 most promising private cybersecurity startups. Now in its third year, Rising in Cyber has become a trusted signal of what is actually moving the needle in enterprise security. Unlike traditional rankings, Rising in Cyber honorees are selected through voting by 150 active CISOs and senior security executives; the result is a reliable signal of what security teams are actually adopting to address their most urgent challenges. Descope* *joins a cohort that has collectively raised over $6.9 billion, according to PitchBook, and is defining the next generation of cybersecurity across critical areas, including identity and access management, agentic AI security, security operations, and application defense. "Security is now moving from a constraint to an enabler on how fast AI can actually scale inside the enterprise. The 150 CISOs who voted on this list understand that better than anyone,” said Oren Yunger, Managing Partner, Notable Capital. “Congratulations to this year's Rising in Cyber honorees for earning their trust." Honorees will be recognized at a private event on May 12 at the New York Stock Exchange in San Francisco alongside top security leaders and investors. "We’re honored to be named to Rising in Cyber for the third year in a row,” said Slavik Markovich, Co-Founder and CEO, Descope. “Identity is critical to securing and scaling AI inside the enterprise. This recognition from the CISO community is powerful validation of the need for purpose-built infrastructure for agentic identities. Congratulations to the other security innovators named to Rising in Cyber!" Descope was founded in 2022 by a team of serial cybersecurity entrepreneurs that previously founded Demisto, a leader in the Security Orchestration, Automation and Response (SOAR) space acquired by Palo Alto Networks. The company [launched from stealth in Feb 2023]() with $53M in seed funding, [expanding]() and closing the round in 2025 with $88M in total funding. Thousands of organizations including GoFundMe, GoodRx, Databricks, Navan, and Linktree use Descope to simplify and secure customer, partner, and agentic identity journeys. To learn more about Rising in Cyber 2026, [view the full list and report](). ### About Descope Descope is a drag & drop identity provider for customer apps and AI agents. Our no / low code solution helps organizations easily create and modify authentication and authorization journeys for customers, partners, AI agents, and MCP servers without writing custom code. Thousands of organizations use Descope to improve customer experience, prevent account takeover, and securely adopt agentic AI and MCP with identity controls built-in. ### About Rising in Cyber Rising in Cyber is an annual list and research initiative that recognizes the most promising private cybersecurity companies, as selected by nearly 150 practicing CISOs and cybersecurity executives. For more information about the Rising in Cyber list, report, and methodology, visit[ www.risingincyber.com](). ### About Notable Capital Notable Capital is named for the founders we invest with, the ideas they pursue, and the companies they build. An early-stage venture capital firm headquartered in the U.S., Notable brings a global perspective to cloud infrastructure, cybersecurity, fintech, commerce, and AI, investing across the U.S., Israel, Europe, and select go-global markets. Notable Capital's portfolio companies include Affirm, Airbnb, Anthropic, Browserbase, Drata, fal, Handshake, Quince, Slack, Square, Vercel, Wispr, and more. More information at www.notablecap.com. #### Media Contacts Erica Anderson Offleash for Descope descope@offleashpr.com Christine Hinton, Notable Capital Email: chinton@notablecap.com Mobile: +1 415.939.0139 --- ### [Descope Unveils Agentic Identity Hub 2.0, the Most Comprehensive Identity Platform for AI Agents and MCP Servers](https://www.descope.com/press-release/agentic-identity-hub-2.0) Organizations can now use Descope as a dedicated auth and access control layer for AI agents and MCP servers with ephemeral credentials, tool-level access control, and enterprise-grade policy controls. *Full content: [https://www.descope.com/press-release/agentic-identity-hub-2.0.md](https://www.descope.com/press-release/agentic-identity-hub-2.0.md)* **Los Altos, CA, January 26, 2026** – [Descope](), the no-code identity provider for customers and AI agents, today announced major updates to its [Agentic Identity Hub]() to provide 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 AI agents as first-class identities alongside human users, add OAuth 2.1 and tool-level scopes to their internal and external MCP servers, and govern agent access to MCP servers with enterprise-grade policy enforcement. 2025 was the year AI agents began to go mainstream, but identity continues to be a bottleneck for both developers and security teams. MCP builders and AI agent developers struggle to meet the production-readiness needs of enterprise security teams, with a recent [Descope survey of 400+ identity decision-makers]() finding that while 88% were using or planning to use AI agents, only 37% had progressed past pilots. At the same time, security teams struggle to secure agentic AI initiatives without stifling innovation. With every threat on the [OWASP Top 10 for Agentic Applications]() citing identity-related remediations, the need for a dedicated identity provider for AI agents is clear. Moreover, the rapid growth of protocols like MCP has led to security gaps–with [2000 MCP servers possessing no security]()–and an increased engineering burden as MCP developers are expected to implement OAuth 2.1, PKCE, DCR, CIMD, and other recommendations laid out in the MCP specification. The Descope no-code identity platform helps organizations easily create and modify identity journeys for their customers, partners, AI agents, and MCP servers using visual workflows. Over 1000 organizations including [GoFundMe](), [Databricks](), [GoodRx](), [Navan](), and [You.com]() use Descope to enhance customer experience, prevent account takeover, and get a 360 view of their customer and machine identities. The new Descope Agentic Identity Hub is designed with both builders and security teams in mind–providing developers with secure, easy to use identity infrastructure and helping security teams with policy-based governance and AI agent lifecycle management. Capabilities announced today in the Descope Agentic Identity Hub include: - **Agentic identity management, **which provides a centralized view of all agentic identities–dynamically created or manually registered–connecting to an organization’s applications, APIs, and MCP servers. Each agent gets a dedicated identity and attributes such as the associated user, tenant, tool-level scopes granted, and OAuth client ID. ![Agentic Identity Management with the Descope Agentic Identity Hub]() - **Comprehensive MCP auth, **which helps MCP server developers add protocol-compliant auth and access control to their internal and external-facing MCP servers. Organizations can support user consent flows, hardened DCR, CIMD, per-agent and per-tool authorization scopes, and tenant-level isolation for B2B MCP use cases. - **Credential vault, **which manages, stores, and refreshes credentials (OAuth tokens and API keys) that AI agents can use to access third-party systems. AI agent builders can choose from 50+ prebuilt connection templates and utilize DCR presets to dynamically connect their AI agents to third-party MCP servers and securely call external APIs on users’ behalf. ![AI agent connection templates for credential management and storage]() - **Enterprise-grade policy controls, **which help organizations define granular authorization controls to govern which AI agents can access their MCP servers and which tool-level scopes they are allowed to invoke. Policies can be created based on user roles, JWT claims, tenants, and agent types, among other attributes. - **AI agent logging and auditing, **which provides organizations with comprehensive visibility into every AI agent action. Organizations can monitor what agents are accessing and when, identify access control misconfigurations, revoke access for potentially rogue agents, and stream audit events to third-party SIEM platforms. “AI agents are breaking traditional identity systems,” said Slavik Markovich, Co-founder and CEO of Descope. “They're autonomous, scalable, and non-deterministic, meaning they can't be managed like human users or service accounts. The Descope Agentic Identity Hub is a dedicated identity provider for AI agents, giving developers the abstraction layers they need to securely take their AI systems to market while ensuring least privilege access and ongoing protocol compliance. We’re grateful to the several customers already using the Agentic Identity Hub and are excited to be a part of the infrastructure layer needed for secure AI adoption.” “The Descope Agentic Identity Hub frees up our developers from tooling and integration work so they can spend more time shipping core features instead,” said Soham Mazumdar, Co-founder and CEO of [WisdomAI](), a Descope customer. “Our customer-facing MCP server uses Descope as the auth layer–this MCP server is used by Fortune 500 customers and helps us show the value of our AI-powered analytics platform while having the confidence that identity controls are baked-in.” “Descope is a key under-the-hood component of the Cequence AI Gateway,” said Shreyans Mehta, co-founder and CTO of [Cequence Security](), a Descope customer. “Descope’s flexible, developer-friendly handling of MCP auth has played an important role in helping Cequence AI Gateway customers securely connect their applications, APIs, and data to AI agents.” ### Resources - AI Launch Week: [https://www.descope.com/ai-launch-week-jan-2026]() - Website: [https://www.descope.com/use-cases/ai]() - Blog: [https://www.descope.com/blog/post/agentic-identity-hub]() - Demo site: [https://descope.ai]() ### About Descope Descope is a drag & drop customer and agentic identity platform. Our no / low code solution helps organizations easily create and modify authentication and authorization journeys for customers, partners, AI agents, and MCP servers. Over 1000 organizations use Descope to improve customer experience, prevent account takeover, and securely adopt agentic AI and MCP with identity controls built-in. #### Descope Media Contact Erica Anderson Offleash for Descope descope@offleashpr.com --- ### [Descope Survey Shows 82% of Organizations Experience Negative Business Impact Due to Customer Identity Issues](https://www.descope.com/press-release/2025-state-of-customer-identity) Third-party survey of 400+ decision makers finds CIAM in a state of transformation as organizations navigate password struggles, overworked developers, and agentic identity. *Full content: [https://www.descope.com/press-release/2025-state-of-customer-identity.md](https://www.descope.com/press-release/2025-state-of-customer-identity.md)* **Los Altos, CA, November 20, 2025** – [Descope](), the drag & drop external IAM platform, commissioned a survey of 416 individuals with technical and / or budgetary responsibility for Customer Identity and Access Management (CIAM) solutions. The State of Customer Identity study found organizations struggling with subpar authentication methods and legacy systems, but not being able to find the time or budget to move towards methods and systems better suited to their users. Readers interested in studying the complete survey report can download a copy [here](). Notably, the study found that while 87% of organizations use password-based authentication for their customer-facing applications, only 2% felt it was the most effective method to balance security and user experience. The same theme of remorse came across in the solutions used to implement CIAM: while 51% of organizations use their existing workforce IAM to implement customer auth, only 8% would choose to do the same if they were to start from scratch. ![State of CIAM workforce IAM]() These patchwork implementations end up affecting the bottom line, with 82% of survey respondents citing at least some negative business impact. Around 52% faced high costs related to auth support tickets, 37% delayed product launches due to identity-related development tasks, and 30% suffered user dropoffs due to complex onboarding. “This study puts quantitative weight behind what we’ve been hearing from hundreds of organizations,” said Rishi Bhargava, co-founder of Descope. “Engineering and identity teams are trying to fit square pegs into round holes when it comes to customer identity. Maintaining homegrown or workforce-based solutions with overstretched development teams is a recipe for falling behind as user needs evolve, new product needs arise, or AI agents are added to the mix.” ### Overstretched developers The survey responses shed light on how organizations are tasking already overburdened developers with CIAM responsibilities without the required supporting systems in place, causing the business and security ramifications highlighted above. ![State of CIAM overworked developers]() - 51% of organizations task developers with minimal to no authentication experience to build and manage CIAM - Only 28% of organizations report having dedicated CIAM engineers - 46% of organizations cite delaying identity-related projects due to competing product priorities ### The true cost of open-source CIAM Using open-source solutions to implement CIAM is a popular choice for flexibility and low surface-level costs, but survey results highlighted the ongoing cost of relying on open-source solutions. ![State of CIAM open source CIAM]() - 50% of organizations using open-source CIAM faced revenue losses / user dropoffs due to strict authentication, compared to 26% of organizations that used commercial CIAM - 51% of organizations using open-source CIAM experienced security incidents after implementing low-friction authentication, compared to 39% of organizations that used commercial CIAM - 55% of organizations using open-source CIAM have cancelled or delayed CIAM upgrades due to competing product and engineering priorities ### The importance of agentic identity controls Most organizations are exploring the idea of adopting AI agents or MCP servers, but the need for identity guardrails are often stopping these projects from reaching full production. Security concerns about over-permissioned AI agents and lack of governance controls continue to rise. - 88% of respondents are using or planning to use AI agents, but only 37% have progressed beyond pilot programs - 57% of respondents are concerned about AI agents accessing unauthorized data or sharing data with unauthorized users - 46% of respondents cite their engineering teams not having the required time or expertise to build and manage agentic identity systems Readers interested in studying the complete survey report can download a copy [here](). ### Methodology The survey was commissioned by Descope and conducted by Dimensional Research. Independent sources of technology stakeholders were invited to participate in an online survey. A variety of questions were asked on current approaches and experiences with customer identities and authentication. Responses were captured between June 6 – 24, 2025.  The survey was fielded in English. A total of 416 qualified individuals completed the survey. All had decision making responsibility (technical and/or budget) for Customer Identity and Access Management (CIAM) solutions at a company with more than 500 employees. ### About Descope Descope is a drag & drop platform to help organizations manage all their external identities. Our no / low code solution helps organizations create, modify, and secure authentication and authorization journeys for customers, partners, AI agents, and MCP servers. Over a thousand organizations use Descope to improve customer experience, prevent account takeover, and securely adopt agentic AI and MCP. #### Descope Media Contact Erica Anderson Offleash for Descope descope@offleashpr.com ---