Descope vs Stytch for the consumer login you edit, and the session that follows
Descope when a Flow, a client SDK, or a backend SDK should own the journey. Stytch when the Dashboard, a pre-built login, a headless SDK, or the API should own it. The 30-minute reset email is one path.
Stytch’s consumer Password Reset by Email Start still sends a magic link that defaults to 30 minutes. That email is one recovery path. Both products also ship project settings or a Dashboard, SDKs, passkeys, MFA, and a session.
Descope edits the journey as a Flow, including hosted login, or through client SDKs (Web JS, React, Vue, Angular, Next.js) and backend SDKs when the app draws the screen. Stytch creates the Consumer project in the Dashboard, can mount a pre-built login, and also offers a headless frontend SDK and a backend API. Neither product is only an API.
The order is which of those surfaces you will change when login has to add a passkey, a second factor, or a session brought over from the old provider. The mailbox comes after those controls.
Overview
| Primary use case | Customer identity journeys in a Flow, a client SDK, or a backend SDK | Consumer authentication from the Dashboard, pre-built login, a headless SDK, or the API |
|---|---|---|
| What you hand it | A project, then a Flow or an SDK, plus the email or phone the user can open | A Consumer project, a public token or API secret, and either a mounted login or a redirect your app hosts |
| Day-to-day workflow | Change a Flow screen or an SDK call when a method has to be added | Change Dashboard SDK settings, the mounted login config, or an API call |
| License/pricing | Published monthly prices, billed annually on Pro and Growth. See Editions | Pay as you go from a free monthly base. The extra user rate is more than one figure. See Editions |
| Who operates it | Your team edits the Flow or SDK. Descope hosts the identity service | Your team uses the Dashboard and the SDK or API. Stytch hosts auth and can send the email or SMS |
| Main buying consideration | Will the next method, including passkey signup or MFA, change in a Flow? | Will your app enforce MFA itself, and can a passkey wait until a verified email or phone exists? |
We read Descope’s pricing page, client SDK reference, passkey guide, MFA guide, sessions overview, and session-migration guide, plus Stytch’s pricing page, consumer authentication page, passkey login guide, passkey overview, MFA overview, session docs, migration overview, password-reset docs, and changelog, on 3 Oct 2026. We did not create a user, send a reset email, or open either product signed in, so this is not a hands-on bake-off. Both are product pages.
Descope
Stytch
Stytch’s post dated 30 Oct 2025 announced the deal. Twilio’s post, updated 14 Nov 2025, says the acquisition closed that day. Stytch’s changelog the same day says Stytch, Inc. remains the contracted service provider. The consumer page checked 3 Oct 2026 still titles the product Stytch. The logo on that page adds an owner line. Descope’s site and pricing page still sell Descope. No closed acquisition of Descope turned up on the company pages checked the same day.
Editions and pricing
Dollar figures below are the ones printed on the pricing pages opened 3 Oct 2026. Stytch’s extra monthly active user rate is the exception: that page lists more than one figure, so this page does not print either figure as the overage.
| How you buy it now | Free Forever is self-serve. Pro has a Buy button. Growth’s button is Speak with us even though a starting price is printed. A Hello World startup application can waive Pro for one year | Consumer pay as you go is self-serve from the pricing page. Enterprise is contact sales. Auth methods are not gated behind a higher plan on that page |
|---|---|---|
| Public price (3 Oct 2026) | Free Forever is $0 per month with 7,500 monthly active users and no overages. Exceeding that limit requires an upgrade. Pro starts at $249 per month, billed annually, with 10,000 monthly active users included and $0.05 per additional user. Growth starts at $799 per month, billed annually, with 25,000 included and the same $0.05 overage. Enterprise is contact | $0 per month base with 10,000 monthly active users included. Full email customization and Stytch brand removal is listed as an add-on, and that page does not state a billing period for it. The consumer pricing data and an SMS example on the same page do not agree on the extra-user figure. This page does not pick one and call it the overage |
| What the public site lists | Free, Pro, Growth, and Enterprise. The comparison block also prices tenants, SSO connections, and machine exchanges. Those are separate from the user price above | Consumer and B2B pay as you go, plus Enterprise. Fraud tools are an add-on. The consumer block does not print a fingerprint dollar next to the $0 base |
| Main buying consideration | Pro is the self-serve paid plan. Growth publishes a price and still routes the button to a conversation | Do not sign an overage from the page until the order names one rate. Brand removal is an add-on, not a per-user charge, and the page still does not name a month or a year |
SDKs and hosted login
The client SDK reference on Descope is the path for teams that are not using Flows. Stytch’s passkey login guide is the path that mounts a UI component. Both still have a backend.
| Where you change the screen | A Flow, including hosted login. If you skip Flows, the client SDK reference names Web JS, React, Vue, Angular, and Next.js. Your app then implements the screens and the errors | The Dashboard creates the Consumer project, holds the public token, and has an Enable SDK control on the Frontend SDK page. Pre-built login mounts with the vanilla JavaScript, React, or Next.js frontend SDK. Headless methods and the backend API are the other paths |
|---|---|---|
| What the hosted UI includes | Flow actions for the methods in the passkey, MFA, and magic-link guides, including sign up, sign in, and sign up or in | Stytch Login can mix products. The passkey guide’s example mounts OTP and passkeys together, because passkeys cannot be the only product in that UI |
| Backend path | Backend SDKs are a documented path for passkey ceremonies and for MFA after a first JWT | Backend APIs authenticate the session and the factors. The passkey overview also shows the WebAuthn register start call |
| Main buying consideration | Do you want the next screen in the Flow editor, or in the client you ship? | Do you want the pre-built component, or headless UI because MFA is not in that component? |
That comment describes one Stytch integration: an API adapter. It does not describe the pre-built login or the Dashboard. A Descope Flow edit is not that file either.
Passkeys, MFA, and sessions
These three decide the order. A late reset email is a separate failure, in the next section.
| Passkey | WebAuthn passkeys are domain-specific. A passkey created on one domain is not treated as present on another domain in the same project. Flow actions include Sign Up / Passkeys, so a passkey can be the first registration. A user can hold more than one passkey | Passkeys are scoped to one relying party, so the user creates one per website. The login guide says passkeys can be used for login and not signup, and the user needs a verified email or phone from a magic link, OTP, or OAuth before registration. The WebAuthn start call takes a domain. After a passkey exists, the MFA overview says it can be a primary or a secondary factor |
|---|---|---|
| MFA | Flows, client SDKs, or backend SDKs. After MFA, the JWT amr claim includes mfa. The MFA guide says the same channel cannot be used twice, such as an email magic link plus an email OTP. Examples on that guide include a password then TOTP, social login then SMS OTP, and a passkey then an email magic link | The MFA overview says pre-built frontend UI does not currently support MFA. Use the headless frontend SDK or the backend, then enforce it by reading authentication_factors on the session. TOTP is a secondary factor only. A password user needs a verified email before a secondary factor, or a password reset is required. Email magic link plus email OTP is called out as the same factor, not a secure pair |
| Session | A short-lived session JWT and a longer-lived refresh JWT. The client or mobile SDK stores them: an HttpOnly cookie on the web, Keychain or EncryptedSharedPreferences on mobile. Timeouts, refresh rotation, and cookie delivery are set in Project Settings, under Session Management. The sessions overview does not print a default lifetime in minutes. The session ends on logout, refresh expiry, inactivity timeout, or a server revoke | session_duration_minutes is at least 5 and at most 527040 minutes (366 days), and it cannot exceed the maximum on the Frontend SDK page in the Dashboard. The session JWT lifetime is five minutes, and the frontend SDK refreshes that JWT. The SDK does not automatically extend the underlying session. An opaque session token is checked with an API call. Storage is a browser cookie, or the iOS Keychain or Android SharedPreferences on the mobile SDKs. The passkey guide logs out with session.revoke() |
| Step-up | The sessions overview says a sensitive action can require a fresh step, and Descope issues a short-lived step-up token | The MFA overview says you can require MFA at every login or only before a sensitive action. The app chooses. The guide points at the session for that step |
What a migration keeps
Both vendors publish a way to move an existing login. The guides do not describe the same token, and this page does not fill the gap with a guess.
| What the guide covers | Session migration, marked beta, from Auth0, Okta including Okta Customer Identity Solution, or a custom token issuer. The client sends the existing token. Descope checks it and issues a Descope session | Consumer migration for an in-house build and for Auth0, AWS Cognito, and Google Firebase. Zero-downtime session migration mints a Stytch session from an external OIDC JWT, with Auth0 named as the example. The overview says other deployment notes exist for in-house or non-OIDC providers. That second guide was not the page used here |
|---|---|---|
| Users already in the new project | Users must already be imported. Just-in-time creation is not supported. A valid external token still fails if the user is missing | The overview recommends a backfill, and a dual-write so creates during the backfill land in both systems. A small user base can backfill without the dual-write. Just-in-time creation is not what that page describes |
| What does not come along | Legacy claims such as roles and groups are not copied. The flow applies to token sessions, and it may not work with an opaque session cookie unless the old provider decodes it. Client SDKs named for the exchange include React, Next.js, Web JS, Kotlin, and Swift | The OIDC session exchange is the part this page read. How a non-OIDC session is cut over was not on that overview, so it is not described here |
| Main buying consideration | Can you import users before the first exchanged token, and rebuild claims yourself? | Is the current session an OIDC JWT you can exchange, or a provider whose cutover you still have to read? |
What the reset email does
The lifetimes below are Stytch’s, from the consumer docs opened 3 Oct 2026. Descope’s magic-link guide describes the message and the tab. It does not print a default lifetime in minutes. This is the edge case, after the controls above.
| What gets sent | A single-use magic link by email or SMS. The URI field sets where the user lands to have the token checked | Password reset is an email magic link. Login and signup can be email magic links too. The consumer page also lists SMS and email provider failover |
|---|---|---|
| Default lifetime | Not printed on the magic-link guide opened 3 Oct 2026 | Password reset defaults to 30 minutes. A login magic link defaults to 1 hour. A signup magic link defaults to 1 week. Each can be set from 5 minutes to 7 days (10080 minutes) |
| Where the click lands | A new browser tab. Enchanted Link is the documented way to finish in the tab that started login | The redirect URL on the start call, or the Dashboard default. If neither is set, the API returns an error |
| Same device | Enchanted Link is the same-tab option in the magic-link guide. It is not described there as a code challenge | The reset and magic-link start calls accept a code challenge, a hash of a one-time secret, so the finish can be tied to the device that started the request |
| Main buying consideration | If the mailbox fails, can the Flow offer a passkey or a code without a new deploy? | Who sets the lifetime, and which provider sends the message when the first one does not arrive? |
Where they overlap
Consumer login on either product can still depend on a mailbox. Passkeys and a one-time message to a phone are on both. The difference is whether a passkey can be the first signup, and whether MFA is inside the pre-built UI or left to your authorization check.
On 30 Sep 2026 Descope posted Family Accounts. Dependent profiles are identity records without credentials, reached through a guardian’s session. That does not replace a password reset for the guardian who still has a password.
On 16 Jan 2026 Stytch’s changelog put an Email Risk API in beta, using signals on the address such as disposable mailboxes. That is a check on the address, not a second way into the account.
When to use both
Use two projects only when they do not share one user pool. A consumer app on Stytch and a newer app on Descope can coexist if each session and each reset template names the app. Pointing both products at the same users, so either one might own the session, is a migration window. Pick the project that issues the session before that window ends.
Choose Descope when the next consumer login change, including passkey signup or MFA, should happen in a Flow, and the order matches Free, Pro, or a Growth conversation at the published monthly price. Choose Stytch when the app should use the Dashboard, pre-built login, or the SDK and API, set the session length in minutes, and enforce MFA in its own session check. Get the Stytch overage in writing. The pricing page lists more than one figure.
FAQs
Is either product only an API?
No. Descope has Flows, including hosted login, plus client and backend SDKs. Stytch has a Dashboard, pre-built login, a headless frontend SDK, and a backend API. The Hacker News comment describes one API adapter. It is not the whole product.
Can a passkey be the first signup?
On Descope, Sign Up / Passkeys is a Flow action, and the passkey is domain-specific. On Stytch, the passkey login guide says passkeys are for login and not signup, and the user needs a verified email or phone first. After that, Stytch’s MFA overview says the passkey can be a primary or secondary factor.
Does the pre-built UI do MFA?
A Descope Flow can. Stytch’s MFA overview says the pre-built UI does not currently support MFA. The headless SDK or the backend does, and your app has to read authentication_factors on the session. A failed check there is your code, not a toggle inside the mounted login.
Which dollar figure should the order use?
Editions is the only place the monthly prices appear. Descope’s paid plans name an additional-user rate there. Stytch’s pricing page lists more than one extra-user figure, so this page does not call either one the overage. Brand removal stays an add-on with no billing period on that page.
Are these still the names on the order?
Yes. The consumer page still uses Stytch, and Stytch, Inc. remains the contracted provider after Twilio closed the acquisition. Descope’s site still uses Descope. Neither column has been renamed.
Is this a hands-on bake-off?
No. The comparison uses Descope and Stytch pages opened 3 Oct 2026, including pricing, SDK, passkey, MFA, session, and migration docs, plus one Hacker News comment from 19 Dec 2025. Nobody created a user or sent a reset email.
