Authentication as a service: the agent answers

I’d use **WorkOS AuthKit**.

It fits this situation unusually well: a few thousand existing password users, Node/React, and enterprise SSO becoming a product requirement. WorkOS can import existing password hashes—including bcrypt, scrypt, PBKDF2, and Argon2—so users can keep their passwords rather than enduring a mass reset. It also combines hosted login, sessions, MFA, SAML/OIDC SSO, organizations, and a self-service admin portal for customer IT teams. [Migration documentation](https://workos.com/docs/migrate/other-services/2-importing-users-into-workos), [AuthKit overview](https://workos.com/docs/authkit/overview).

The economics are straightforward at your size: AuthKit is free for up to one million active users; production SSO is currently $125 per customer connection per month. That makes your initial cost roughly $125/month, plus optional items such as a custom domain. [WorkOS pricing](https://workos.com/pricing).

Why I’d choose it:

- It is designed around B2B organizations and enterprise identity, not merely consumer login with SAML bolted on.
- Customers can configure their own IdP through the Admin Portal, reducing support work.
- The official Node SDK handles sealed sessions, validation, refresh, organization switching, and logout. React packages are also available. [Node session helpers](https://workos.com/docs/reference/authkit/session-helpers), [SDK list](https://workos.com/docs/sdks).
- SCIM directory provisioning and audit-log functionality are available when the next enterprise questionnaire arrives.
- Pricing is per enterprise connection rather than forcing all ordinary users into an expensive enterprise tier.

What I considered

- **Stytch B2B:** The strongest alternative—and probably the better choice if price dominates. Its current free tier includes 10,000 MAUs and five SSO or SCIM connections, with additional connections at $125/month. It supports direct migration of several hash formats and has a solid organization-first model. [Stytch pricing](https://stytch.com/pricing), [migration guide](https://stytch.com/docs/resources/migrations/migrating-user-data). I slightly prefer WorkOS because enterprise onboarding, SSO, directory sync, and customer-facing administration are its center of gravity.
- **Auth0:** The safest incumbent choice, with broad protocol support and extensive customization. I would choose it if you have unusually complex identity rules, many legacy protocols, or an organization already experienced with Auth0. For this case, its configuration surface and pricing structure feel heavier than necessary.
- **Clerk:** Excellent React developer experience and attractive UI components. It supports enterprise SSO, but I’d favor it for frontend-centric applications where UI velocity is the primary concern. WorkOS feels better aligned with a B2B enterprise roadmap.
- **AWS Cognito:** Potentially inexpensive and operationally familiar if you are deeply committed to AWS. However, it tends to leave more integration, UX, enterprise onboarding, and troubleshooting work with your team—which conflicts with the reason you are replacing the custom system.
- **Adding only an SSO broker:** WorkOS also offers standalone SSO, but retaining your password-reset and session code defeats much of the project’s purpose. I’d replace the whole authentication layer.

Before signing, I would validate these points:

1. **Your exact password-hash representation.** Algorithm support alone is insufficient; parameters, salt encoding, pepper use, and custom preprocessing must match.
2. **Tenant model.** Decide how users belonging to multiple customer organizations behave and whether SSO is optional or enforced per organization.
3. **Authorization boundary.** Let WorkOS establish identity and organization membership, but keep application-specific entitlements in your own database unless its RBAC model genuinely matches yours.
4. **Enterprise requirements.** Confirm SCIM, IdP-initiated SSO, domain verification, MFA enforcement, audit exports, data residency, SLA, and support expectations with the customer.
5. **Exit path.** Obtain written answers on exporting users, identities, organization memberships, and password hashes.
6. **Account recovery and support impersonation.** These flows often get overlooked during provider comparisons.

I would migrate gradually: create immutable mappings from your user and organization IDs to WorkOS IDs, bulk-import users and password hashes, run both session systems briefly, move a small internal cohort, then the enterprise tenant, and finally everyone else. Existing sessions generally cannot be migrated safely, so users should expect one new login—but not a password reset. Keep the old authentication path available behind a feature flag until login, reset, verification, SSO, logout, and account-recovery metrics are clean.

I’d use **WorkOS AuthKit**, assuming this is a multi-tenant B2B product and enterprise SSO will become a recurring sales requirement—not a one-off checkbox.

Why WorkOS:

- Enterprise SSO, organizations, roles, Directory Sync/SCIM, and audit logs form one coherent B2B model.
- Your few thousand users are effectively free: AuthKit currently includes up to one million active users. SSO is priced per customer connection, currently $125/month for the first 15. [WorkOS pricing](https://workos.com/pricing)
- Existing password hashes can be imported, so most users need not reset their passwords. Migration can be enabled organization by organization with feature flags. [Migration documentation](https://workos.com/docs/migrate/other-services)
- Sessions use ordinary access/refresh tokens, with organization, role, and permission claims your Node backend can validate. [Session documentation](https://workos.com/docs/authkit/sessions)
- Organizations are first-class, and identities across passwords, social login, and SSO are linked by email. [Users and organizations](https://workos.com/docs/authkit/users-organizations)

The main caveat is UI flexibility: AuthKit’s hosted approach is opinionated. I would prototype the actual login, invitation, account-linking, and organization-switching flows before signing anything.

What I also considered:

| Provider | Why it was credible | Why I wouldn’t choose it first here |
|---|---|---|
| **Stytch B2B** | Excellent B2B model, React/Node SDKs, five SSO or SCIM connections free, password-hash and even session migration support. [Pricing](https://stytch.com/pricing), [migration](https://stytch.com/docs/resources/migrations/migrating-user-data) | Very close second. I’d choose it over WorkOS if preserving active sessions, embedded UI, or the first five free connections mattered most. |
| **Clerk** | Best React developer experience and polished components. Pro is currently $20/month annually and includes one enterprise connection; additional connections start at $75/month. It supports importing many password-hash formats. [Pricing](https://clerk.com/pricing), [migration](https://clerk.com/docs/guides/development/migrating/overview) | Attractive for a frontend-led product, but I’d verify SCIM, enterprise administration, audit requirements, and authorization modeling before committing. |
| **Auth0** | Mature, broad protocol support, extensive customization, and unusually flexible bulk or rolling migration from an existing database. [Migration options](https://auth0.com/docs/manage-users/user-migration) | More configuration and operational complexity, with less predictable SSO pricing as requirements grow. Best when unusual identity protocols or deep customization outweigh simplicity. |
| **AWS Cognito / Firebase / Supabase Auth** | Potentially inexpensive basic authentication | Enterprise SSO provisioning and customer-admin workflows are not their strongest end-to-end experience; you may end up rebuilding the enterprise layer you are trying to stop maintaining. |

Before selecting any vendor, I would validate these items in a short proof of concept:

- Your precise password hashing algorithm—including pepper handling—can be imported.
- Whether existing sessions may be invalidated. If they must survive, Stytch deserves extra weight.
- Your tenancy semantics: one person in multiple organizations, duplicate emails, contractors, and organization switching.
- SSO enforcement and recovery: domain discovery, IdP-initiated login, MFA interaction, and a protected break-glass account.
- Whether the customer really means only SAML/OIDC, or also expects SCIM, group-to-role mapping, audit-log export, SLA, and security questionnaires.
- Data residency, incident history, deletion/export APIs, support responsiveness, and the cost at 10, 50, and 200 enterprise connections.
- Whether application authorization remains in your database. I would outsource authentication and coarse organization roles, but keep domain permissions and entitlements under application control.

For migration, I’d run both systems briefly: create stable mappings from your internal user and organization IDs to WorkOS IDs, import users and password hashes, dual-write relevant changes, move a few internal accounts, then one pilot customer, and finally migrate by organization. Keep the old authenticator available behind a rollback flag until password login, reset, SSO, logout/revocation, invitations, and account linking have all been exercised in production.

I’d use **WorkOS AuthKit**, assuming this is a B2B SaaS product and SSO is likely to become a recurring enterprise requirement—not merely a one-off checkbox.

Why WorkOS:

- Enterprise identity is its center of gravity: SAML/OIDC SSO, Directory Sync/SCIM, organization membership, and an admin portal for customer IT teams.
- It supports Node backends and React front ends without forcing authentication logic into the UI framework.
- You can import existing password hashes—bcrypt, scrypt, PBKDF2, Argon2, and several others—so most users should not need to reset their passwords. [WorkOS migration documentation](https://workos.com/docs/migrate/other-services/2-importing-users-into-workos)
- AuthKit user management is currently free for up to one million users. SSO and Directory Sync are priced per enterprise connection, starting at $125/month each. That aligns reasonably well with charging enterprise customers for those capabilities. [WorkOS pricing](https://workos.com/pricing)
- Its unified user model can attach password, social, and enterprise identities to the same user, which matters when an existing password user later starts signing in through their employer. [Identity-linking documentation](https://workos.com/docs/authkit/identity-linking)

The main reservation is that WorkOS is not the cheapest if you accumulate many low-revenue SSO customers. “One connection” generally means one enterprise customer’s IdP relationship, and SSO plus Directory Sync can become two separately billed connections.

What I considered:

| Provider | Why I considered it | Why I wouldn’t choose it first here |
|---|---|---|
| **Stytch B2B** | Excellent API-first design; organizations, RBAC, SSO, SCIM, and five SSO/SCIM connections included under its current pricing. It also imports password hashes. [Pricing](https://stytch.com/pricing) | Very credible runner-up—and possibly the better economic choice. I’d favor it if you need deeper control over custom authentication flows or expect several SSO customers before monetizing them. Its separate consumer/B2B models require an early, consequential data-model choice. |
| **Clerk** | Probably the quickest React integration and polished hosted components. It supports SAML/OIDC and imports password hashes. [SSO docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview), [migration docs](https://clerk.com/docs/guides/development/migrating/overview) | I’d pick it for a UI-led product with conventional auth. For an established Node application, I would rather make the backend—not Clerk’s React-oriented model—the durable integration boundary. |
| **Auth0** | Broadest track record, extensive customization, mature ecosystem, and both bulk and rolling migration options. [Migration documentation](https://dev.auth0.com/docs/manage-users/user-migration) | Powerful but comparatively complex. Organizations, enterprise connections, actions, tenant configuration, and plan boundaries can become another identity platform your team must actively maintain. I’d choose it when procurement history, unusual protocols, or extensive identity customization outweigh simplicity. |
| **AWS Cognito** | Low raw cost and attractive if everything already runs on AWS. | Enterprise federation and tenant administration usually require more custom application work—the exact maintenance burden you are trying to escape. |
| **Self-hosted options** | More control and potentially lower license cost. | You still own upgrades, email deliverability, incident response, federation quirks, and security operations. Wrong direction for your stated goal. |

Before signing, I would run a short proof of concept around the parts that create lock-in:

1. Confirm your exact password hashing scheme—including pepper handling—can be imported.
2. Model organizations, users belonging to multiple organizations, domain discovery, and account linking.
3. Connect the enterprise customer’s actual IdP in a staging environment.
4. Test deprovisioning and role/group mapping; ask whether they mean “SSO” alone or also SCIM.
5. Verify data export, audit-log access, SLA, support response time, data residency, subprocessors, and breach terms.
6. Price three scenarios: today, ten SSO customers, and fifty SSO-plus-SCIM customers.

For migration, I’d backfill organizations and users, preserve your internal user IDs through an external-ID mapping, import password hashes, and run both systems briefly behind a feature flag. Existing sessions can expire naturally while new logins go through WorkOS. Keep authorization and application roles in your own database initially; replacing authentication does not require simultaneously redesigning authorization.

My final decision would therefore be: **WorkOS AuthKit by default; Stytch B2B if the proof of concept shows materially better pricing or you need more programmable authentication behavior.**

I’d use **WorkOS AuthKit** for this case.

It fits the shape of the problem unusually well: B2B SaaS, a modest existing user base, and enterprise SSO becoming a requirement. WorkOS provides first-class organizations, email/password, MFA, SAML/OIDC SSO, RBAC, and later SCIM provisioning. It also has official Node and React SDKs. [WorkOS SDKs](https://workos.com/docs/sdks), [AuthKit overview](https://workos.com/docs/authkit/overview)

Why I’d choose it:

- You can import existing password hashes rather than forcing several thousand password resets. It currently supports bcrypt, scrypt, PBKDF2, Argon2, SSHA, and Firebase scrypt. [Migration guide](https://workos.com/docs/migrate/other-services/2-importing-users-into-workos)
- User management is free for up to one million monthly active users; SSO is priced per enterprise connection, currently $125/month for each of the first 15. That is a sensible economic model when you have thousands of ordinary users but only a few enterprise customers. [WorkOS pricing](https://workos.com/pricing)
- Organizations and organization memberships are native concepts, which matters once SSO, tenant-specific policies, roles, JIT provisioning, and deprovisioning enter the picture. [Users and organizations](https://workos.com/docs/authkit/users-organizations)
- It leaves a clean path to SCIM and group-to-role mapping when the customer’s next request is “disable employees automatically when they leave.” [Roles and permissions](https://workos.com/docs/authkit/roles-and-permissions)

What I considered before choosing it:

| Provider | Why I considered it | Why it wasn’t my default |
|---|---|---|
| **Stytch B2B** | Excellent migration tooling, strong organization model, password-hash import, SSO, SCIM and RBAC. Its current free tier includes 10,000 MAU and five SSO or SCIM connections. | Arguably the best alternative. I’d choose it over WorkOS if the five included connections, richer authentication-policy controls, or migration assistance materially matter. [Pricing](https://stytch.com/pricing), [migration](https://stytch.com/docs/resources/migrations/migrating-user-data) |
| **Clerk** | Probably the nicest React integration and polished authentication UI; supports hash migration and organizations. One SSO connection is included on Pro. | I see it as frontend/auth-UX-led, while your requirement is becoming enterprise-identity-led. Still a good choice if developer experience and UI speed dominate. [Pricing](https://clerk.com/pricing), [migration](https://clerk.com/docs/guides/development/migrating/overview) |
| **Auth0** | Mature, broad protocol support, large ecosystem, and plenty of experienced implementers. | More configuration and pricing complexity than I’d accept for a few-thousand-user product unless your team already knows Auth0 or has unusually complex identity requirements. It does support bulk password-hash imports. [Bulk imports](https://auth0.com/docs/manage-users/user-migration/bulk-user-imports) |
| **AWS Cognito** | Attractive if everything already lives in AWS and minimizing vendor count is paramount. | Enterprise onboarding and operational ergonomics are less pleasant; I would not choose it primarily to reduce maintenance burden. |
| **Self-hosted Keycloak/FusionAuth** | More control, potential data residency benefits, and less SaaS dependence. | You are explicitly trying to stop owning authentication operations. Self-hosting shifts rather than removes that burden. |

Before signing, I would validate these details in a short proof of concept:

- Your exact password hashing scheme and parameters—not merely “we use bcrypt.”
- Whether one human may belong to multiple customer organizations.
- Whether SSO must be optional or mandatory per organization, including break-glass access.
- Required session lifetime, revocation behavior, MFA, impersonation, audit logs, and data residency.
- Whether the enterprise customer means only SAML/OIDC today or also expects SCIM, group mapping, and self-service IdP configuration.
- Exportability of users and password hashes, deletion semantics, SLA, support response times, and projected cost at 1, 10, and 50 SSO connections.

For migration, I’d preserve your internal user IDs and store a separate `workos_user_id`; map tenants to WorkOS organizations; import users and compatible password hashes; run old and new authentication paths briefly behind a feature flag; invalidate or deliberately age out legacy sessions; pilot with staff and one customer; then cut over. Keep application authorization enforced in the Node backend—even if roles appear in the React client or session token.

The one fact that could change my answer immediately is your product model: if this is consumer-first rather than organization-centric B2B SaaS, I would reassess Clerk and Stytch Consumer instead.

I’d use **WorkOS AuthKit**, assuming this is a B2B SaaS product where users belong to customer organizations.

The deciding factor is not basic login—every serious provider handles passwords, resets, MFA, and React/Node SDKs. It is the enterprise-auth lifecycle you are likely about to inherit: SAML and OIDC variations, organization-specific policies, domain verification, IdP routing, SCIM provisioning, group-to-role mapping, and eventually audit logs. That is WorkOS’s core market rather than an enterprise feature added to a primarily consumer-auth product.

WorkOS gives you first-class organizations, SAML/OIDC SSO, JIT provisioning, SCIM, per-organization authentication policies, hosted or custom UI, and Node/React support. Its access tokens can carry organization, role, and permission claims, while refresh tokens support switching organizations. [AuthKit overview](https://workos.com/docs/authkit/overview), [users and organizations](https://workos.com/docs/authkit/users-organizations), [sessions](https://workos.com/docs/authkit/sessions)

At your scale, User Management is currently free up to one million users. Enterprise SSO is priced separately at $125 per connection per month for the first 15 connections; Directory Sync is another separately metered product. That means the bill is driven primarily by how many enterprise customers enable SSO, not by your few thousand ordinary users. [WorkOS pricing](https://workos.com/pricing)

What I would verify before signing:

- Your password hash format can be imported without resets. WorkOS supports importing password hashes and a dual-write migration, but I would have them validate a real sample—including parameters, salt representation, and any application-level “pepper”—before committing. [WorkOS migration guidance](https://workos.com/docs/fga/standalone-integration)
- Whether email uniqueness matches your data model. WorkOS identifies users globally by email and represents access to different tenants through organization memberships. If your system permits separate accounts with the same email, consolidation requires product decisions.
- Data residency, support SLA, incident history, log retention, custom domains, BAA requirements, and the exact contract terms for exporting users and password hashes.
- Whether your customer means only “SAML SSO” or also expects SCIM, IdP group mapping, forced SSO, MFA policy, deprovisioning, and IdP-initiated login. Enterprise buyers frequently say “SSO” and reveal the rest during security review.

What else I considered:

| Provider | Why it was plausible | Why I would not choose it first here |
|---|---|---|
| **Stytch B2B** | Excellent organization-first model, transparent APIs, broad password-hash migration support, and currently five SSO/SCIM connections free. [Migration](https://stytch.com/docs/resources/migrations/migrating-user-data), [pricing](https://stytch.com/pricing) | A very close second. I would choose it if API control, published pricing, or minimizing initial SSO cost mattered more than WorkOS’s enterprise-integration focus. |
| **Clerk** | Best-in-class React developer experience, polished components, import/export of password hashes, and one enterprise connection on Pro. [Migration](https://clerk.com/docs/guides/development/migrating/overview), [pricing](https://clerk.com/pricing) | Strong choice for UI velocity, but its B2B organization pricing and limits need careful modeling. I would prefer a provider whose center of gravity is enterprise identity lifecycle. |
| **Auth0** | Mature, flexible, widely understood, very broad protocol and extensibility support, and good rolling-migration capabilities. [Migration](https://auth0.com/learn/migrate-user-database-auth0) | More configuration complexity and typically less predictable B2B/enterprise pricing. I would select it when unusual identity protocols, extensive custom actions, or an existing Okta relationship outweighed simplicity. |
| **AWS Cognito** | Cheap and close to AWS infrastructure | Operationally awkward for customer-facing B2B organizations and enterprise onboarding; it would not reduce enough of the maintenance burden that prompted this move. |
| **Supabase/Firebase** | Convenient if already central to the application stack | Fine consumer authentication, but not my first choice for an enterprise SSO/SCIM roadmap. |

I would migrate in stages:

1. Model each customer account as a WorkOS organization and preserve your existing user and organization IDs as external IDs.
2. Import users and password hashes in staging, then test actual logins—not merely successful API imports.
3. Add the new provider ID alongside your current internal user ID. Keep your internal ID as the stable business-data key.
4. Dual-write account changes briefly, then backfill remaining users.
5. Put the new flow behind a cohort or organization feature flag and onboard your requesting enterprise customer first.
6. Invalidate the old sessions at final cutover, but avoid forcing password resets unless your current hash scheme cannot be migrated.
7. Retire password-reset and session tables only after rollback and support windows expire.

I would outsource authentication and session security, but keep application authorization—resource ownership, entitlements, billing plans, and domain-specific roles—in your database. Treat provider role claims as useful inputs, not as your only source of truth.

My practical shortlist would therefore be **WorkOS and Stytch**, with a small proof of concept against both. Unless that test exposes a password-migration or identity-model mismatch, I’d ship WorkOS.

I’d choose **WorkOS AuthKit**, assuming your stored password hashes use a supported format such as bcrypt.

It fits this situation unusually well: a B2B product, one immediate enterprise SSO requirement, a few thousand existing users, and a team that explicitly wants to stop operating authentication infrastructure.

Why WorkOS:

- Authentication, sessions, password resets, MFA, organizations, SAML/OIDC SSO, and optional SCIM provisioning are managed together.
- Node and React SDKs are first-class, while you can choose hosted UI or retain your own frontend.
- AuthKit user management is currently free for up to one million users; SSO is priced per customer connection—currently $125/month for each of the first 15. Your ordinary user count therefore does not dominate the bill. [WorkOS pricing](https://workos.com/pricing)
- It can import users from a homegrown store, including compatible password hashes. Users whose hashes cannot be imported can be moved through a password-reset flow instead. [Migration guide](https://workos.com/docs/migrate/other-services)
- Organizations, per-organization authentication policies, identity linking, just-in-time provisioning, and Directory Sync align well with an enterprise SaaS roadmap. [WorkOS user management](https://workos.com/user-management)

The deciding factor is not the React login component. It is whether the provider has a clean model for **users belonging to customer organizations, each with its own identity provider and policy**. WorkOS does.

What I would verify before signing:

1. **Password-hash compatibility.** Identify the exact algorithm, parameters, salt format, and any application-level pepper. If a pepper is involved, confirm the migration mechanism with WorkOS in writing. Run a representative import test before choosing.
2. **Account topology.** Decide whether one person can belong to multiple customer organizations and what happens when the same email arrives through password login and SSO.
3. **Authorization boundary.** Move authentication to WorkOS, but normally retain product permissions and resource-level authorization in your database. Do not let adopting an auth vendor accidentally redesign your authorization model.
4. **Enterprise requirements.** Ask whether the customer needs only SAML/OIDC login or also SCIM, group-to-role mapping, forced SSO, MFA policies, audit logs, session revocation, or an SLA.
5. **Exitability.** Contractually verify user, organization, credential, MFA, and audit-log export options—not merely profile export.
6. **Real cost.** Price the likely number of SSO and SCIM connections in three years, not just today’s one customer.

Alternatives I considered:

| Provider | Where it wins | Why I would not lead with it here |
|---|---|---|
| **Stytch B2B** | Excellent B2B organization model, broad password-hash support, five SSO/SCIM connections included, transparent pricing | It may actually be the better choice if migration fidelity or near-term price matters most. Its free tier currently includes 10,000 active members and five connections. [Pricing](https://stytch.com/pricing) |
| **Clerk** | Probably the smoothest React developer experience and polished components | I would prioritize enterprise lifecycle and migration mechanics over frontend convenience. Its Pro plan includes one enterprise connection and charges for additional ones. [Pricing](https://clerk.com/pricing) |
| **Auth0** | Most mature and flexible; strong progressive-migration patterns and broad ecosystem | More configuration and pricing complexity than this case appears to require—the platform can become another subsystem someone must understand deeply. |
| **AWS Cognito** | Sensible when deeply committed to AWS and optimizing infrastructure cost | Enterprise SaaS ergonomics, customer onboarding, and customization generally require more engineering ownership—the thing you are trying to shed. |
| **Self-hosted Keycloak/SuperTokens** | Control, portability, and potentially attractive software cost | You still own upgrades, availability, security response, email delivery, federation quirks, and operational incidents. That conflicts with the goal. |

The strongest runner-up is **Stytch**, not Auth0. If you have Argon2, scrypt, PBKDF2, or another less convenient legacy hash—or expect up to five enterprise connections shortly—I would run a WorkOS-versus-Stytch proof of concept before committing. Stytch explicitly supports several legacy hash types and documents static and dual-write migrations. [Stytch migration documentation](https://stytch.com/docs/resources/migrations/migrating-user-data)

For rollout, I would use a staged migration: add immutable provider IDs to your existing user and organization records, import organizations and users, migrate compatible hashes, dual-write account changes briefly, canary internal accounts, enable the enterprise customer’s SSO, then progressively move sessions. Keep the old login path available—but frozen except for migration—for a defined rollback window. Avoid matching accounts solely by an unverified email address.

So the short answer is: **WorkOS AuthKit by default; Stytch if password compatibility or its included SSO connections materially improve the migration economics.**

I’d choose **Stytch B2B Authentication**, assuming a short proof of concept confirms that your current password hashes are importable.

Why it fits unusually well:

- Its B2B model—organizations, members, RBAC, SAML/OIDC SSO and SCIM—matches enterprise SaaS better than a consumer-auth system with SSO bolted on.
- A few thousand active users and up to five SSO or SCIM connections currently fit its free allowance. Additional connections are listed at $125/month. [Stytch pricing](https://stytch.com/pricing)
- It supports importing bcrypt, scrypt, Argon2, PBKDF2 and several older hash formats, so users may retain their passwords. [Migration documentation](https://stytch.com/docs/get-started/guides/migration-and-deployment)
- It documents static import, dual-write/backfill, preserving external IDs, and exchanging existing signed tokens for Stytch sessions. That makes a gradual cutover practical rather than forcing everyone through password reset and logout. [User migration guide](https://stytch.com/docs/resources/migrations/migrating-user-data)
- Its Node backend and React components fit your stack without requiring authentication logic to live primarily in the frontend.

### What I considered

| Provider | Why I might choose it | Why I wouldn’t choose it here |
|---|---|---|
| **WorkOS AuthKit** | My close second. Excellent enterprise positioning, organizations, SSO, SCIM and admin portal; authentication is free up to one million users. | SSO costs $125/month per customer connection starting with the first. That is reasonable, but Stytch currently gives you five. [WorkOS pricing](https://workos.com/pricing) |
| **Clerk** | Probably the fastest React developer experience; polished components and straightforward Node integration. Pro currently includes one enterprise connection, with additional connections starting at $75/month. [Clerk pricing](https://clerk.com/pricing) | More frontend-centric and opinionated. I would favor it if shipping speed and UI components mattered more than a B2B-first identity model and migration flexibility. |
| **Auth0** | Broadest ecosystem, mature extensibility, many enterprise features and a long operational history. It can authenticate against an existing database during migration. [Auth0 pricing](https://auth0.com/pricing) | Pricing becomes harder to predict around organizations, enterprise connections and advanced functionality. It also tends to leave teams maintaining Actions, connection configuration and Auth0-specific complexity—the sort of maintenance you are trying to eliminate. |
| **AWS Cognito** | Potentially economical and attractive if everything already lives in AWS. | Enterprise onboarding and customization are comparatively awkward; you often end up building more administration and glue code yourself. |
| **Keycloak / self-hosted** | Maximum control and reduced vendor dependence. | You would still own upgrades, availability, incident response, email security, SAML quirks and account recovery. That conflicts directly with the goal of getting out of the authentication business. |

### Before signing, I would verify these points

1. **Password compatibility.** Record the exact algorithm and parameters—not merely “bcrypt” or “scrypt”—and test a representative import. If hashes cannot be imported, plan rolling migration or password resets.
2. **Identity model.** Decide whether one person can belong to several customer organizations, whether the same email can have different roles, and whether passwords should be global or organization-scoped. Stytch notes that the password-scoping choice becomes difficult to change once active passwords exist.
3. **Account linking.** Specify what happens when an existing password user first arrives through corporate SSO. Email matching alone can create account-takeover risks if issuer, tenant and domain verification are loose.
4. **Authorization boundary.** Let the provider establish identity and coarse organization roles, but keep product permissions and ownership rules in your database unless its RBAC model genuinely fits. Authentication outsourcing should not require rewriting your domain model.
5. **Enterprise requirements.** Ask the customer now about SAML versus OIDC, enforced SSO, JIT provisioning, SCIM, group-to-role mapping, audit logs, IdP-initiated login and emergency administrator access.
6. **Operations and contracts.** Review EU data handling, DPA, subprocessors, deletion/export behavior, SLA, incident history, log retention, support response times and price protection. Also model costs at 5, 20 and 100 SSO connections—not only today’s single customer.
7. **Exit strategy.** Preserve your own immutable user and organization IDs, store provider IDs as mappings, and confirm that users, memberships, MFA state and SSO configurations can be exported.

I would migrate by introducing provider-ID mappings, importing organizations and users, importing hashes late to minimize drift, accepting both old and new sessions for a limited overlap, then switching issuance to Stytch. I would keep the old login path available behind a rollback flag until password login, reset, email verification, SSO, logout, revocation and support tooling have all survived production traffic.

I’d choose **Stytch’s B2B authentication product**, assuming this is a multi-tenant SaaS application.

Why it fits unusually well:

- It supports React and Node/TypeScript directly, with hosted or customizable login components.
- Organizations, memberships, roles, SAML/OIDC SSO, SCIM, MFA, and organization-specific authentication policies are native concepts.
- You can import existing bcrypt, scrypt, Argon2, PBKDF2, and several legacy password hashes, avoiding a forced password reset for most users. [Stytch migration documentation](https://stytch.com/docs/resources/migrations/migrating-user-data)
- The current published tier includes 10,000 active B2B members and five SSO or SCIM connections; additional connections are listed at $125/month. That comfortably covers the stated starting point, although production SLA and migration support require an enterprise agreement. [Stytch pricing](https://stytch.com/pricing)
- Their migration tooling explicitly covers user backfills, password hashes, dual-write migrations, session migration, and SSO-connection handoff. [Migration and deployment guide](https://stytch.com/docs/get-started/guides/migration-and-deployment)

The strongest runner-up was **WorkOS AuthKit**. Its enterprise onboarding experience and Admin Portal are excellent, and it supports importing password hashes and existing SAML/OIDC connections. I would pick it instead if polished customer-admin SSO/SCIM setup is substantially more important than price. AuthKit allows up to one million active users free, but each production SSO connection currently costs $125/month from the first connection. [WorkOS migration guide](https://workos.com/docs/migrate/other-services), [WorkOS pricing](https://workos.com/pricing)

I also considered:

- **Auth0:** the most established and flexible option, with strong extensibility and enterprise familiarity. It now includes one enterprise connection on its B2B free tier. Its plan matrix, Actions/custom-database machinery, organization limits, and eventual enterprise pricing still make it heavier than this situation seems to require. [Auth0 pricing](https://auth0.com/pricing?pm=true)
- **Clerk:** probably the best React developer experience and a good choice when personal accounts and organizations coexist fluidly. I’d rank it behind Stytch here because your central problem is B2B migration plus enterprise identity lifecycle—not primarily frontend auth UI. [Clerk pricing](https://clerk.com/pricing)
- **AWS Cognito:** attractive if AWS consolidation and infrastructure cost dominate. I would not choose it to reduce maintenance burden; enterprise onboarding and customization usually leave more application-owned work.
- **Keycloak/Zitadel/FusionAuth:** valuable when self-hosting, data residency, or avoiding SaaS dependency is mandatory. They replace vendor lock-in with operational responsibility, which conflicts with your reason for moving.
- **Adding WorkOS SSO to the existing auth stack:** the smallest immediate change, but it leaves you maintaining passwords, resets, sessions, account linking, and recovery—the things you want to retire.

Before signing, I would validate five things in a short proof of concept:

1. Your exact password-hash parameters can be imported—not merely the algorithm name.
2. One email belonging to multiple customer organizations behaves as your product expects.
3. SSO users link safely to existing password accounts without email-based account-takeover paths.
4. The enterprise customer accepts the provider’s SLA, data region, subprocessors, retention, incident terms, and SAML/SCIM behavior.
5. You can export users, memberships, and credentials later; ask for this contractually.

For migration, retain your own immutable application user ID and add provider member/organization IDs beside it. Backfill organizations and users, import hashes, dual-write identity changes briefly, move a small cohort, then switch login traffic. Validate sessions on the Node backend and keep product authorization in your database initially—outsourcing authentication should not make the provider the accidental source of truth for billing entitlements or domain permissions.

I’d use **WorkOS AuthKit**, assuming this is a B2B SaaS product and your password hashes are compatible with its importer.

Why: your immediate request is authentication, but the enterprise roadmap usually becomes SAML/OIDC SSO → domain verification → organization policies → SCIM provisioning → audit logs. WorkOS is particularly coherent across that sequence, supports React/Node, and provides hosted authentication without forcing you to maintain login, reset, MFA, and account-linking flows. Its migration tooling can import users, organizations, memberships, roles, password hashes, and TOTP factors. [WorkOS AuthKit overview](https://workos.com/docs/authkit/overview), [migration documentation](https://workos.com/docs/cli/migrations)

For a few thousand users, AuthKit user management is currently free; enterprise SSO costs **$125/month per customer connection** for the first 15. That is not the cheapest option, but the pricing is straightforward and independent of the number of employees behind each connection. [WorkOS pricing](https://workos.com/pricing)

What I considered:

| Provider | Why I considered it | Why I wouldn’t choose it here |
|---|---|---|
| **Stytch B2B** | Excellent B2B model, five SSO/SCIM connections and 10,000 MAU currently included; supports more legacy hash types, including bcrypt, scrypt, Argon2 and PBKDF2. | I slightly prefer WorkOS’s enterprise onboarding and broader SSO/SCIM/audit-log product shape. Stytch becomes my first choice if your hashes are Argon2/scrypt or minimizing initial cost dominates. [Pricing](https://stytch.com/pricing), [password migration](https://stytch.com/docs/api-reference/b2b/api/passwords/migrate) |
| **Clerk** | Probably the best React developer experience and materially cheaper: Pro includes one enterprise connection, with published per-connection pricing after that. | Its product feels more frontend-centric; for an enterprise-led B2B roadmap, I’d rather optimize around organization lifecycle and IT-admin workflows. Verify that its organization limits and enhanced B2B add-on fit your tenancy model. [Clerk pricing](https://clerk.com/pricing) |
| **Auth0** | Mature, extremely flexible, broad ecosystem, familiar to enterprise security teams. | More configuration surface and historically more pricing/plan complexity than I’d invite into a small migration whose purpose is reducing maintenance. Its current free B2B tier is nevertheless worth testing because it includes one enterprise connection. [Auth0 pricing](https://auth0.com/pricing?pm=true) |
| **AWS Cognito** | Attractive if you are deeply committed to AWS and want infrastructure-level control. | The operational and UX rough edges work against your stated goal of owning less authentication machinery. |
| **Keep existing auth + WorkOS SSO API** | Lowest-risk short-term path: bolt SSO onto what you already have. | You would still own sessions, password resets and credential security—the exact burden you want to remove. WorkOS explicitly supports this standalone approach, so it is a useful migration bridge, not my desired endpoint. [WorkOS SSO options](https://workos.com/docs/sso) |

Before signing, I would make these four checks decisive:

1. **Inventory password hashes.** WorkOS’s documented migration package supports bcrypt and some legacy formats, but unsupported hashes mean a reset on first login. If you use Argon2, Stytch may give you a substantially smoother migration.
2. **Model organizations explicitly.** Decide whether one human can belong to multiple customers, whether email domains imply membership, and whether roles are global or organization-scoped.
3. **Price the three-year roadmap.** Count expected SSO and SCIM connections—not just users. One connection today can become twenty surprisingly quickly.
4. **Run a real IdP pilot.** Test with the customer’s actual Okta or Entra configuration, including SP- and IdP-initiated login, email changes, deprovisioning, certificate rotation, and an emergency non-SSO “break-glass” administrator.

I’d migrate with a reversible cutover: import users while retaining your internal user IDs, store the WorkOS user ID as an external identity mapping, pilot SSO for one organization, temporarily accept old sessions, then switch password login and resets. Keep application authorization and business data in your database; the auth provider should establish identity and organization context, not become the only copy of your permissions model.

I’d use **WorkOS AuthKit**, assuming this is a B2B product and enterprise SSO will become a recurring sales requirement rather than a one-off checkbox.

Why WorkOS:

- It treats organizations, SAML/OIDC SSO, authentication policies, and eventual SCIM provisioning as core concepts.
- It has official React and Node support, hosted login flows, MFA, session management, RBAC, and automatic identity linking.
- Existing users, organizations, memberships, roles, password hashes, and even TOTP factors can be migrated. WorkOS explicitly documents migration from a custom datastore. [Migration guide](https://workos.com/docs/migrate/other-services)
- The commercial model fits this shape: AuthKit is free for up to one million active users, while SSO is currently $125 per enterprise connection per month. Directory Sync is separately priced per connection. [WorkOS pricing](https://workos.com/pricing)
- Organization policies can require SSO or MFA, which is likely to appear in the customer’s next security questionnaire. [Organization policies](https://workos.com/docs/authkit/organization-policies)

For a few thousand users, your bill is therefore driven primarily by the number of enterprise customers using SSO—not your user count. That is generally a good match for B2B SaaS.

What I considered:

| Provider | Where it shines | Why it wasn’t my first choice |
|---|---|---|
| **Stytch B2B** | Probably the strongest economic alternative: currently includes 10,000 MAU and five SSO or SCIM connections free; excellent B2B modeling and unusually broad password-hash migration support. | More authentication-product complexity than you may need. I would run it head-to-head with WorkOS before signing. [Pricing](https://stytch.com/pricing) |
| **Clerk** | Excellent React developer experience, polished components, easy implementation, password-hash imports, and one enterprise connection on Pro. | Some useful B2B behavior and self-service SSO requires the B2B add-on; pricing depends on retained organizations and connections. It is attractive for frontend-heavy products, but WorkOS is more directly aligned with enterprise identity operations. [Pricing](https://clerk.com/pricing) |
| **Auth0** | Broadest mature platform, enormous integration surface, highly configurable. | More configuration and operational surface area, with less predictable B2B/enterprise pricing. It risks replacing your home-grown maintenance burden with Auth0-specialist maintenance. |
| **AWS Cognito** | Cheap, infrastructure-friendly, good if you are deeply committed to AWS. | Awkward UX and enterprise tenant administration; usually requires more custom glue—the thing you are trying to eliminate. |
| **Supabase/Firebase** | Good basic authentication and economical for consumer applications. | Enterprise organization policies, SSO onboarding, SCIM, and B2B lifecycle management are not their strongest center of gravity. |
| **Keep current auth + WorkOS SSO only** | Lowest-risk short-term route; WorkOS supports standalone SSO. | Leaves you maintaining sessions, resets, credential security, MFA, and account recovery indefinitely. I would only use this as an intermediate migration stage. |

The deciding checks before committing would be:

- Confirm your password hash algorithm and parameters are importable. WorkOS migration tooling currently supports a narrower hash set than Clerk or Stytch; unsupported users would need a reset.
- Ask the enterprise customer whether “SSO” really means only SAML/OIDC, or also SCIM, group-to-role mapping, enforced MFA, audit logs, and IdP-initiated login.
- Model cost at 1, 10, and 50 SSO customers—connections, not users, will dominate.
- Get contractual answers for SLA, breach notification, data region/residency, deletion, support response, and exportability.
- Decide whether your existing user IDs remain canonical. I would keep an internal user record and store `workos_user_id` as an external identity reference.
- Keep authorization in your application. Let WorkOS authenticate users and supply organization/role claims, but do not scatter vendor-specific permission decisions throughout the codebase.

I’d migrate gradually: add immutable provider IDs to existing accounts, import and reconcile users, run both session validators during a transition, pilot SSO with the requesting customer, then cut password users over. Unless preserving sessions is commercially important, I would deliberately invalidate old sessions at final cutover; it is much safer than attempting to translate two-year-old session state.

My shortlist would therefore be **WorkOS and Stytch**, with WorkOS as the default choice and Stytch as the price-and-migration challenger. The password-hash compatibility check could legitimately flip that decision.

### Top Recommendation: **WorkOS** (or **Clerk + WorkOS**)

For a **React + Node.js** stack migrating from a custom auth setup with an incoming enterprise SAML/SSO requirement, **WorkOS** is currently the best choice.

---

### Why WorkOS?

1. **Enterprise SSO & Directory Sync (SCIM) First:**
   * Most consumer/developer auth providers treat Enterprise SSO (SAML 2.0 / OIDC) as an expensive add-on or enterprise upsell gate.
   * WorkOS is purpose-built for B2B SaaS. It handles the edge cases of corporate Identity Providers (Okta, Azure AD / Microsoft Entra, Google Workspace, PingIdentity, OneLogin) with very little boilerplate.
2. **User Migration & AuthKit:**
   * You can use **WorkOS User Management & AuthKit** for consumer/standard password logins, social logins, and password resets, with seamless migration APIs (importing user records and password hashes like bcrypt/argon2 without forcing immediate resets).
   * First-class React SDKs (`@workos-inc/authkit-react`) and Node SDK (`@workos-inc/node`).
3. **Multi-tenancy & Organization Modeling:**
   * Built natively around **Organizations**, tenant-specific domain routing (e.g., `user@company.com` automatically redirects to their company's Okta SAML flow), and role-based access control (RBAC).
4. **Predictable B2B Pricing:**
   * Upfront flat pricing per active SSO connection (usually free for dev and transparent per-SSO-connection tiers) rather than punishing MAU jumps just because an enterprise user logged in.

---

### What Else Was Considered & Why They Ranked Lower

| Provider | Pros | Why It Didn't Win Out for This Scenario |
| :--- | :--- | :--- |
| **Clerk** | Best-in-class React pre-built components and developer experience for standard B2C/B2B auth. | Enterprise SSO (SAML) is locked behind their Pro/Enterprise plans with significant step-up pricing. *(Note: Many teams use Clerk for self-serve users + WorkOS purely for SSO, though WorkOS User Management now handles both)*. |
| **Auth0 (by Okta)** | The classic enterprise standard; handles virtually every protocol and edge case. | **Expensive & complex:** High pricing cliffs when activating Enterprise SAML/OIDC connections, outdated dashboard/SDK UX compared to modern tools, and notoriously painful migration/pricing renegotiations. |
| **Stytch** | Excellent B2B auth, passwordless, SAML, and headless APIs with flexible Node/React SDKs. | Strong alternative, but WorkOS has better out-of-the-box self-serve admin portals for enterprise IT teams to configure their own SAML connections. |
| **Supabase Auth / Firebase Auth** | Easy to set up, cheap for basic consumer auth. | Very weak/cumbersome enterprise SAML & SCIM support. B2B multi-tenancy requires significant custom glue code. |
| **Ory (Kratos/Hydra) / Keycloak** | Open-source, self-hosted, full control, no vendor lock-in fees. | You stated you are tired of maintaining auth infrastructure. Self-hosting Keycloak or Ory brings ongoing maintenance, patch, and operational burdens. |

---

### Migration Strategy Recommendation

1. **Password Hash Import:** Export your user table with existing password hashes (bcrypt/argon2) and bulk import them into the provider's API so existing users don't have to reset passwords.
2. **Session Cutover:** Set up JWT/session verification middleware in Node (e.g., swapping your custom session middleware to verify the provider's session tokens/cookies).
3. **Enterprise SSO Route:** Set up organization domain matching (e.g., `acme-corp.com`) so when employees of your enterprise customer enter their email, they bypass password authentication and hit their dedicated SAML/Okta flow.

For a Node.js + React stack with a few thousand users to migrate and an enterprise requirement for SSO (SAML / OIDC), **WorkOS** or **Clerk** are the top recommendations, with **WorkOS** taking the lead if enterprise B2B features are the primary driver.

---

### Top Recommendation: **WorkOS** (or **Clerk** if you want full UI ownership out of the box)

#### Why **WorkOS**:
1. **Built specifically for Enterprise / B2B SaaS**:
   - Native support for SAML/OIDC Single Sign-On (Okta, Azure AD, Google Workspace, PingIdentity, etc.) and SCIM directory sync.
   - Built-in multi-tenancy / organization management out of the box.
2. **Smooth User Migration**:
   - WorkOS AuthKit lets you import user password hashes directly (bcrypt, argon2, scrypt, pbkdf2), avoiding the need to force a mass password reset for your existing users.
3. **Developer Experience for Node & React**:
   - First-class `@workos-inc/node` backend SDK and clean frontend React components / AuthKit hosted/embedded flows.
4. **Predictable B2B Pricing**:
   - Often structured around active SSO connections per organization rather than heavily punishing scale on standard users.

*(Runner-up for fast consumer/developer DX: **Clerk** — great pre-built React components, organization switcher, and seamless Node SDK, but enterprise SAML/SSO is gated behind higher pricing tiers).*

---

### Alternatives Considered & Why They Weren't the First Choice

| Provider | Pros | Why it was set aside |
| :--- | :--- | :--- |
| **Auth0 (Okta)** | Industry standard, robust SAML/enterprise support, extensive Node/React docs. | **Pricing "Enterprise Tax"**: SSO typically forces you into high-tier enterprise contracts. Migration and configuration complexity can be overwhelming. |
| **Clerk** | Best-in-class React UI components, fast DX, built-in multi-tenancy. | **SSO Cost**: SAML/Enterprise SSO is gated on custom enterprise plans or expensive add-ons compared to WorkOS. |
| **Stytch** | Excellent API-first B2B capabilities, direct password hash imports, strong session management. | Great option, but AuthKit/WorkOS provides a faster drop-in UI experience for React out of the gate. |
| **Supabase Auth / Firebase Auth** | Inexpensive, basic auth is fast to setup. | Enterprise SAML/SSO support is either cumbersome to configure, limited in multi-tenant management, or requires third-party add-ons (like BoxyHQ). |
| **Self-Hosted (Keycloak / Ory / BoxyHQ Jackson)** | No vendor lock-in, free core licensing. | You stated you are **tired of maintaining auth**. Self-hosting identity brokers re-introduces infrastructure, patching, and compliance overhead. |

---

### Migration Strategy for Your ~Few Thousand Users

1. **Hash Export & Import**:
   - Export your existing `users` table (`email`, password hash, salt, algorithm).
   - Import hashes directly into the provider's API so users can log in seamlessly without a password reset.
2. **Dual-Read / Lazy Migration (Alternative)**:
   - If hash algorithms are incompatible, intercept login on your Node backend: check against old database $\rightarrow$ if valid, create/migrate user to provider on the fly $\rightarrow$ transition to provider.
3. **Session Handover**:
   - Replace custom cookie/JWT verification middleware in Node with the provider's JWT verification middleware (using JWKS).
   - In React, wrap the app in the provider's `<AuthProvider />` context.

### Recommended Provider: **WorkOS** (or **Clerk** as close alternative)

For a **React frontend + Node.js backend** with existing users to migrate and an immediate enterprise SSO requirement, **WorkOS** is the best fit.

---

### Why WorkOS?

1. **Enterprise-Ready Out of the Box:**
   * Built specifically for B2B SaaS. It provides drop-in **SAML/OIDC SSO**, **SCIM provisioning**, and the **Admin Portal** (a self-service UI for your enterprise customer’s IT admin to configure their IdP without you writing bespoke integrations).
2. **Smooth User Migration:**
   * WorkOS supports password hash imports (bcrypt, argon2, PBKDF2, scrypt) via API, allowing you to migrate your existing users seamlessly without forcing a password reset.
3. **Node & React First-Class Support:**
   * Solid official Node SDK (`@workos-inc/node`) and React/Next.js libraries/components.
4. **Transparent, Scalable B2B Pricing:**
   * Unlike traditional providers that charge exorbitant enterprise tiers just for SAML, WorkOS bills transparently per active SSO connection ($125/connection/mo or via their User Management tiers).

---

### Alternatives Considered & Trade-offs

| Provider | Pros | Why it was not the top pick |
| :--- | :--- | :--- |
| **Auth0 / Okta** | • Proven enterprise track record<br>• Full feature set | • **"Enterprise Tax"**: SSO requires expensive enterprise plans.<br>• Heavy developer overhead and legacy dashboard complexity. |
| **Clerk** | • Excellent React DX and pre-built components<br>• Supports password imports & SAML | • Historically more focused on B2C / simple B2B. While their B2B/organizations support is growing, WorkOS provides deeper enterprise enterprise features (e.g., self-serve Admin Portal for IT admins). |
| **Stytch** | • Strong B2B SAML, SCIM, and RBAC<br>• Very flexible headless APIs | • Requires more custom UI building compared to WorkOS’s hosted admin workflows. |
| **Supabase Auth / Firebase Auth** | • Cheap/Free tiers<br>• Low baseline operational cost | • Weak/expensive enterprise SAML SSO support.<br>• Unnecessary database/ecosystem lock-in if you only need auth. |
| **Self-Hosted / Open Source** *(Ory, Keycloak, SuperTokens)* | • Full data control<br>• Zero per-seat vendor fees | • Does not solve your primary pain point: **maintenance overhead**. |

---

### Migration Checklist for Your Stack

1. **Export Existing Credentials:** Export user IDs, emails, and password hashes (e.g., bcrypt salt + hash).
2. **Bulk Import:** Use the provider’s migration API to import users without invalidating existing sessions/passwords.
3. **Backend Middleware:** Replace custom session/cookie validation in Node with standard JWT verification using standard libraries (e.g., `jose`) or the provider SDK.
4. **Enable Enterprise SSO:** Provide your enterprise client the connection link (or embed the self-service Admin Portal in React) to connect Okta, Azure AD, Google Workspace, or Ping.

For a **Node backend + React frontend** needing to offload legacy auth, support seamless user migration (~few thousand users), and deliver **Enterprise SSO (SAML/OIDC)** for B2B customers, the top recommendation is:

---

### **Top Recommendation: WorkOS + AuthKit** (or **WorkOS with existing Auth**)
*Best suited for B2B SaaS where Enterprise SSO, multi-tenancy, and SCIM provisioning are the core drivers.*

#### Why WorkOS:
1. **Built specifically for Enterprise Readiness**: WorkOS dominates the developer-first space for B2B features: SAML, OIDC, Directory Sync (SCIM), and Multi-Tenant RBAC.
2. **AuthKit / User Management**: You can use AuthKit as your complete authentication layer (sessions, hosted UI / React components, password resets, social logins) while enterprise SSO is handled out-of-the-box.
3. **Migration Friendly**: Supports password hash imports (e.g., bcrypt, argon2) or just-in-time (JIT) / lazy migrations with minimal downtime.
4. **Integration**: First-class Node SDK (`@workos-inc/node`) and React hooks/components.

---

### **Alternative Contenders Considered**

| Provider | Pros | Cons / Why It Ranked Lower |
| :--- | :--- | :--- |
| **Clerk** | • Superior React DX & drop-in UI components.<br>• Excellent B2B/Organization support and user migration tooling.<br>• Handles sessions, password resets, and MFA effortlessly. | • Enterprise SSO (SAML) is gated on their higher-tier plans ($$$ jump as enterprise tenant volume increases). |
| **Auth0 (Okta)** | • Industry standard with mature enterprise SSO/SAML integrations.<br>• Automatic lazy migration via custom database scripts. | • **High cost & steep pricing cliff** for enterprise SAML connections.<br>• SDK and dashboard complexity (legacy bloat compared to modern alternatives). |
| **Stytch** | • B2B-native with first-class SAML/SCIM and organization tenancy.<br>• Rich Node & React SDKs with flexible headless or pre-built UI options. | • AuthKit/WorkOS generally offers a slightly simpler end-to-end DX for standard SSO workflows. |
| **Supabase Auth / GoTrue** (Self-hosted or Cloud) | • Cost-effective, open-source Postgres ecosystem.<br>• Supports SAML 2.0. | • SSO configuration and enterprise directory management require more custom glue code compared to WorkOS/Clerk. |
| **SuperTokens / Ory Kratos** | • Open-source control, avoids vendor lock-in.<br>• Easy password migration. | • Self-hosting enterprise SSO connectors (SAML) adds ongoing operational overhead, which goes against offloading maintenance. |

---

### **Recommended Next Steps & Migration Strategy**

1. **Lazy Migration (JIT) vs. Bulk Import**:
   - **Bulk Import**: If using standard hashing (e.g., `bcrypt`), WorkOS/Clerk can directly ingest existing password hashes.
   - **Lazy Migration**: Point your login endpoint to check the provider first; fallback to validating against your legacy DB and creating the user in the new provider with their verified credentials on their next login.
2. **Enterprise SSO Configuration**:
   - Create an **Organization / Tenant** model where enterprise users are routed to their IdP (Okta, Azure AD/Entra ID, Google Workspace) via their email domain or organization identifier.

### Recommended Choice: **WorkOS** (or **Clerk / Auth0** depending on ownership priority)

For a **Node.js + React** stack with an existing user base to migrate and an immediate enterprise SSO/SAML requirement, **WorkOS** is typically the best fit, followed closely by **Clerk** and **Auth0**.

---

### Top Recommendation: **WorkOS**

**Why it fits your scenario:**
1. **Built for Enterprise / B2B:** Enterprise SSO (SAML/OIDC), SCIM directory sync, and audit logs are first-class primitives rather than expensive, complex enterprise add-ons.
2. **User Migration (AuthKit):** Provides flexible user management (AuthKit) with straightforward APIs to import existing user password hashes (bcrypt, argon2, etc.), so users won't be forced to reset passwords on day one.
3. **Developer Experience:** Excellent Node.js SDK and React component integrations. It handles complex SAML configurations across identity providers (Okta, Azure AD, Google Workspace) via self-serve onboarding portals for your enterprise IT admins.

---

### Comparison of Options Considered

| Provider | Best Fit For | Enterprise SSO / SAML | Migration Complexity | Pricing / Gotchas |
| :--- | :--- | :--- | :--- | :--- |
| **WorkOS** *(Top Pick)* | B2B SaaS, immediate enterprise SSO requirement | Native core strength, self-serve admin portal for IT admins | Easy: Direct password hash imports via API | Generous free tier for AuthKit; SSO charged per active enterprise connection (~$99–$125/connection/mo). |
| **Clerk** | Modern React DX, user management, consumer/B2B hybrid | Supported on B2B / Enterprise plans | Straightforward CSV / backend API migration with password hash support | Excellent React UI components & session handling; Enterprise SSO is locked behind higher-tier plans. |
| **Auth0 (Okta)** | Legacy enterprise standard, large enterprises | Very mature SAML/OIDC enterprise federation | Highly flexible (custom database scripts for lazy/just-in-time migration) | Feature-rich, but pricing scales steeply with enterprise connections, and developer dashboard/DX can feel bloated. |
| **Stytch** | API-first / headless auth flexibility | Built-in B2B SSO & SCIM support | Straightforward via REST API & hash migration | Great if you want 100% custom UI without using vendor pre-built widgets. |
| **Supabase Auth / Firebase** | Full BaaS apps | SAML SSO available on Pro/Enterprise | Low-to-medium | Often overkill or awkward if you only want auth and already run an independent Node backend/database. |

---

### Migration Strategy for Existing Users

1. **Password Hash Import:** Export your user database with existing password hashes (e.g., bcrypt/argon2) and batch-import them directly via the provider’s migration API.
2. **Lazy / Just-In-Time Migration (Alternative):** If your hashes use a non-standard algorithm, route login requests through the auth provider via custom auth webhooks/scripts to verify against your legacy database on the user's next login, then write the new credentials into the provider.
3. **Session Hand-off:** Replace your custom JWT/cookie verification middleware in Node with the provider's SDK session-validation middleware, and wrap your React root with their auth context provider.

**Clerk** — full auth replacement (sessions, password reset, MFA) plus enterprise SSO, with the best fit for React + a Node API at a few thousand users.

### Why Clerk
- Replaces the stuff you’re tired of: sessions, email/password, reset flows, and org-aware SSO in one product.
- React SDK and prebuilt UI are strong; the Node side is mostly JWT/session verification.
- **Organizations + SAML/OIDC SSO** covers the enterprise customer (Okta, Azure AD, Google Workspace).
- User/password-hash import is workable for a few-thousand-user migration; MAU pricing at that size is usually fine.
- You stop owning auth edge cases without taking on another self-hosted system.

### What else I considered
| Option | Why not (for you) |
|--------|-------------------|
| **Auth0** | Safest “enterprise checkbox” pick; Organizations + SSO are solid. Heavier dashboard/pricing/complexity for the same outcome at your scale. I’d pick it if procurement already expects Auth0/Okta-class vendors. |
| **WorkOS** | Best pure enterprise SSO/SCIM story. AuthKit can do full auth now, but the classic fit is “bolt SSO onto existing auth” — you’re trying to *delete* custom sessions/resets, not only add SAML. |
| **Cognito** | Cheap if you’re already deep in AWS. DX and Hosted UI are rough; SSO/setup pain often outweighs the savings at a few thousand users. |
| **Supabase Auth** | Fine if the app already lives on Supabase. Awkward as a bolt-on IdP for a standalone Node API. |
| **Keycloak / FusionAuth (self-host)** | Feature-complete and SSO-capable, but you’re back to running auth infrastructure — the opposite of why you’re migrating. |
| **Firebase Auth** | Easy social/password; weak fit for B2B SAML/enterprise IdP onboarding. |
| **Keep custom auth + WorkOS SSO only** | Fixes the customer ask, not the maintenance burden. |

### Migration note (whichever you pick)
Plan for: password-hash import (or forced reset), session cutover, and mapping your users → the provider’s “organization” for that SSO customer. At a few thousand users, the hard part is usually product cutover and IdP setup with the customer, not scale.

**Bottom line:** Clerk as the default for your stack and goals; Auth0 if the enterprise deal needs a more familiar vendor name on the security questionnaire.

**Auth0** — one platform to replace your sessions/password resets and cover enterprise SSO without you owning the hard parts.

### Why Auth0
- Drops in for both problems: hosted login, password reset, sessions/tokens, MFA, plus SAML/OIDC enterprise connections.
- Migration path for a few thousand users is well-trodden (bulk import, including common password hashes so you are not forcing a mass reset).
- Node and React SDKs are boring and documented; Organizations map cleanly to a B2B “this customer uses SSO” model.
- At a few thousand users, cost is usually fine; you are paying to stop maintaining crypto, reset emails, session edge cases, and IdP quirks.

### What else I considered
| Option | Verdict |
|---|---|
| **WorkOS (AuthKit)** | Closest runner-up. Best-in-class if the *real* pain is enterprise SSO + Admin Portal + SCIM/directory sync and you want customers to self-serve IdP setup. Slightly less “replace all of our auth tomorrow” than Auth0 unless you go all-in on AuthKit. |
| **Clerk** | Best React DX and fast to ship. Fine for SSO-via-orgs, but I would not pick it first when the forcing function is a serious enterprise IdP deal and a careful password-user migration. |
| **Amazon Cognito** | Cheap at scale, ugly DX, awkward SSO/app-client story. Easy to recreate the maintenance burden you are trying to escape. |
| **Keycloak / FusionAuth (self-host)** | Full control, but you still run upgrades, scaling, and IdP breakage — opposite of “tired of maintaining this.” |
| **Okta (workforce)** | Great IdP for employees; wrong default as *your* customer-facing CIAM unless you are already deep in Okta. |
| **SSO-only bolt-on** (keep passwords, add SAML via WorkOS/Passport) | Temping under deadline, but you keep owning sessions/resets — the thing you are done with. |

### Decision rule
- **Auth0** if you want one vendor to retire custom auth *and* satisfy the enterprise SSO ask.
- **WorkOS** if you are clearly B2B SaaS and the next ten customers will all demand SAML/SCIM — optimize for that pipeline, not for login-box polish.

Either way: migrate passwords with hash import where possible, run SSO for the enterprise tenant in parallel (Organizations / connection per customer), and treat “session in your DB” as obsolete in favor of short-lived access tokens + refresh — do not reimplement sessions beside the provider.

**Auth0** — it replaces sessions, password reset, and enterprise SSO in one place, and the Node/React SDKs plus user-migration paths are mature enough that you are not signing up for another two years of auth chores.

### Why Auth0
- One product covers password login, resets, MFA, social, and **SAML/OIDC enterprise connections** (what that customer actually wants).
- **Organizations** fits B2B multi-tenant “this company uses Okta/Azure AD.”
- Migration at a few thousand users is straightforward: bulk import (including common password hashes) or lazy migration via a custom DB connection.
- Security reviews and procurement are easier than with newer CIAM vendors; Auth0 is a known name on enterprise questionnaires.
- You stop owning session cookies, reset tokens, lockout, and “forgot password” email flows.

### What else I considered

| Option | Verdict |
|--------|---------|
| **WorkOS (AuthKit)** | Best pure B2B SSO + SCIM/Directory Sync. Strong #2 if the next ask is “sync users from the customer’s IdP.” Slightly less “all-in-one consumer auth” history than Auth0; choose it if SSO/IT admin features matter more than a full CIAM suite. |
| **Clerk** | Best React DX and session UX. Viable at your scale, but enterprise SAML/org features and hash migration are weaker reasons to bet the company auth on it when SSO is the forcing function. |
| **AWS Cognito** | Cheap, but DX and SSO setup are painful; you still feel like you are maintaining auth. |
| **Firebase / Supabase Auth** | Fine for product auth; awkward as the primary answer to enterprise SAML. |
| **Keycloak (self-host)** | Capable SSO, but you keep running and upgrading identity infra — opposite of “tired of maintaining this.” |
| **Stay on Passport / custom** | Does not solve the maintenance or enterprise SSO problem. |
| **Okta workforce** | Right when *your employees* log into tools; wrong default for *your app’s* customer identity (Auth0 is the CIAM sibling). |

### Practical note for the migration
Plan a short dual-run: import users (prefer bringing password hashes so nobody resets on day one), switch the React app to Auth0’s hosted login or the React SDK, validate the enterprise connection with that customer’s IdP, then delete the home-grown session/reset code.

If the enterprise deal already implies **SCIM / directory sync** next quarter, start with **WorkOS** instead — same “stop maintaining auth” outcome, better fit for B2B IT features. Otherwise Auth0 is the safer default.

**WorkOS (AuthKit)** — for your situation, that’s the one I’d pick.

You’re not choosing “best auth library for a greenfield React app.” You’re choosing a way out of owning sessions/resets **and** a way to close an enterprise SSO deal. WorkOS is built for exactly that: SAML/OIDC against Okta, Entra ID, Google Workspace, etc., plus AuthKit so you can stop maintaining login, password reset, and session plumbing on the Node side.

### Why WorkOS fits
- **SSO is the forcing function**, not social login or a prettier sign-in form.
- **Pricing lines up with B2B** (you pay when SSO connections / enterprise features show up), which matches “a few thousand users, one serious SSO customer.”
- **Node + React** is a normal path: AuthKit / OIDC on the backend, React handles the redirect/callback; you don’t need to become an IdP expert.
- **Migration at your scale is boring in a good way**: export users, invite/reset or staged password migration, map existing user IDs into WorkOS users, flip session issuance to their tokens/session. A few thousand rows is not a data problem.

Also plan for **SCIM/directory sync** soon after SSO — enterprise buyers usually ask next. WorkOS treats that as a first-class follow-on.

### What else I considered

| Option | Verdict |
|--------|---------|
| **Auth0** | Strong default if you want a full identity platform (MFA, social, extensive policies) and “nobody gets fired.” Heavier product surface and cost/complexity than you need if SSO + ditching custom sessions is the real goal. |
| **Clerk** | Best React DX and fastest UI rip-out. Fine if product-led auth UX is the priority. Enterprise SSO is available, but you’re buying a full app-auth product; WorkOS stays closer to “B2B SSO + stop owning auth.” |
| **PropelAuth** | Serious B2B alternative (orgs + SSO). I’d shortlist it if multi-tenant org model is already core. Slightly less “default” than WorkOS/Auth0 for procurement conversations. |
| **Stytch** | Credible; similar space. I’d only prefer it with an existing preference/team experience. |
| **Cognito** | Cheap if you’re all-in on AWS. DX and SSO setup are painful; you’d trade one maintenance burden for another. |
| **Supabase Auth / Firebase** | Good for simple consumer auth. Wrong center of gravity for enterprise SAML and customer IdPs. |
| **Keycloak / FusionAuth self-hosted** | Solves SSO on paper, fails your actual complaint — you’d still be maintaining auth. Skip. |
| **Okta as the app’s IdP** | Great as the *customer’s* IdP. Using Okta Workforce to *be* your customer-facing auth layer is usually overkill and awkward for a product with mixed self-serve + SSO. |

### When I’d pick something else
- **Auth0** if security/compliance stakeholders want the most familiar enterprise checkbox and you’re fine with the tax.
- **Clerk** if the pain is mostly “our login UX and React integration suck” and SSO is one connection, not the product strategy.
- **PropelAuth** if organizations/roles/tenancy are already the product model and you want that opinionated out of the box.

**Bottom line:** for “custom sessions/resets are exhausting + enterprise wants SSO + Node/React + ~thousands of users,” start with **WorkOS AuthKit**, keep **Auth0** as the conservative backup, and only go **Clerk** if React auth UX is the bigger win than SSO packaging.

Postawiłbym na **WorkOS (AuthKit)**: SSO wycenia per-connection (nie per-user), więc jeden enterprise klient z SAML/OIDC nie każe płacić za całą bazę paru tysięcy userów, ma gotowe SDK do Node i React, oraz Directory Sync (SCIM) na później, gdyby ten klient tego zażądał. Po drodze rozważałem Auth0 (najbardziej dojrzały, ale SSO/enterprise features są w drogich planach), Clerk (świetne DX, ale mocniej pod Next.js/frontend niż pod dowolny Node backend, a enterprise SSO też płatne per-connection podobnie jak WorkOS) i self-hosted Keycloak/Ory (tańsze w skali, ale to dokładnie ten maintenance, od którego chcesz uciec).

Główny tradeoff: WorkOS jest młodszy i ma mniejszy ekosystem niż Auth0, więc trochę więcej dłubania przy mniej typowych flow (np. MFA, passwordless), za to migracja userów i koszt na waszą skalę wychodzą korzystniej.

Rekomendacja: **WorkOS** (User Management + SSO/SCIM w jednym).

Dlaczego akurat to pasuje do Waszej sytuacji: głównym triggerem jest SSO dla klienta enterprise, a WorkOS jest zbudowany dokładnie pod ten wzorzec, zwykli użytkownicy logują się przez ich AuthKit (sesje, reset hasła, MFA), a enterprise klienci dostają SAML/OIDC SSO i SCIM jako osobny, dokładany moduł, bez potrzeby przesiadki na jeden model tożsamości dla wszystkich. Cennik jest przewidywalny: SSO liczone per connection (jedna integracja z klientem enterprise), nie per użytkownik, co przy paru tysiącach kont ma znaczenie. Migracja haseł jest w praktyce bezbolesna, importujecie istniejące hashe (bcrypt/scrypt) i użytkownicy logują się bez wymuszonego resetu.

Co jeszcze rozważałem i dlaczego odpadło:

- **Auth0** - dojrzały, najszersze możliwości enterprise SSO, ale drogi przy skalowaniu (MTU pricing), a system Rules/Actions bywa uciążliwy w utrzymaniu, czyli częściowo wraca problem, który chcecie zamknąć. Solidny wybór numer dwa, jeśli WorkOS czegoś zabraknie.
- **Clerk** - najlepszy DX pod React, bardzo szybkie wdrożenie, ale historia i pozycjonowanie mocniej celują w consumer/prosumer niż B2B enterprise SSO, warto sprawdzić aktualny stan SAML/SCIM u nich, jak coś się zmieniło.
- **AWS Cognito** - tani i wygodny, jeśli już jesteście głęboko w AWS, ale DX jest znany z bólu (customizacja, komunikaty błędów, limity), a obsługa enterprise SSO jest toporna.
- **Firebase Auth** - bardziej pod konsumenckie appki, SAML/enterprise SSO wymaga podniesienia do Identity Platform, więc traci przewagę prostoty.
- **Keycloak / Ory self-hosted** - pełna kontrola i brak vendor lock-inu, ale to oznacza dalej utrzymywać własną infrastrukturę tożsamości, czyli sprzeczne z "mam dość utrzymywania tego". Sensowne tylko przy twardych wymaganiach data residency.
- **FusionAuth** - tańsza alternatywa z elastycznym cennikiem, warto trzymać w tyle głowy jeśli koszt WorkOS/Auth0 przy skali okaże się problemem.

Jeden punkt do sprawdzenia przed decyzją: czy wasze obecne hashe haseł (jaki algorytm) są wspierane w imporcie przez WorkOS, to determinuje czy migracja jest cicha, czy wymaga wymuszonych resetów przy pierwszym logowaniu.

Rekomendacja: **WorkOS** (a konkretnie ich User Management + AuthKit dla React, plus SSO). Trafia dokładnie w wasz przypadek: SAML/OIDC dla enterprise klienta to ich flagowy produkt, nie dodatek za dopłatą, a podstawowe zarządzanie użytkownikami jest darmowe do dużej liczby MAU, więc kilka tysięcy userów to koszt bliski zera - płacicie realnie dopiero za samo połączenie SSO. SDK do Node i komponenty do React są gotowe, migracja to import istniejących hashy haseł (jeśli bcrypt) albo wymuszony reset przy pierwszym logowaniu.

Co jeszcze brałem pod uwagę:
- **Auth0** - najbardziej dojrzały, ale SSO enterprise jest na droższym planie, a pricing i panel admina potrafią się rozjechać przy skalowaniu; dla "kilku tysięcy userów + jeden enterprise klient" to przepłacanie za funkcje, których nie użyjecie.
- **Clerk** - świetne DX z React, ale enterprise SSO też siedzi na wyższym tierze, mocniej celuje w B2C/mniejsze zespoły niż w pojedynczego enterprise klienta z SAML.
- **Okta** - klasa "duży korpo", drogi i przewymiarowany dla waszej skali.
- **AWS Cognito** - najtańszy, ale słabe wsparcie SAML/SSO out-of-the-box i ciężkie DX - dużo roboty, żeby dowieźć to, co WorkOS ma gotowe.
- **Self-hosted Keycloak/Ory** - pełna kontrola, ale to dokładnie ten rodzaj utrzymania, od którego chcecie uciec.

Głównym kompromisem przy WorkOS jest to, że pełne zarządzanie użytkownikami (nie tylko SSO) jest wciąż stosunkowo młodym produktem w porównaniu z Auth0 - warto sprawdzić, czy pokrywa wszystkie wasze obecne przepływy (reset hasła, MFA, itp.), zanim zaczniecie migrację.

Krótka rekomendacja i to, co odrzuciłem po drodze:

**Wybrałbym Clerk.** Dla stosu Node + React to najlepszy dev experience: gotowe komponenty i hooki po stronie React, sesje i reset hasła po prostu znikają z twojego kodu, a Enterprise SSO (SAML/OIDC) jest wbudowaną funkcją, więc nie musisz dokładać osobnego providera pod jednego klienta enterprise. Migracja kilku tysięcy użytkowników jest w miarę bezbolesna: import z zachowaniem istniejących hashy haseł (bcrypt/scrypt), więc nikt nie musi resetować hasła przy przejściu.

Co jeszcze brałem pod uwagę:

- **WorkOS** – najmocniejszy pod kątem samego enterprise SSO/SCIM i tańszy, jeśli chcesz dołożyć SSO do istniejącego systemu sesji zamiast wymieniać całość. Ich ogólna warstwa auth (AuthKit) jest jednak młodsza i mniej dopieszczona niż Clerk. Sensowna opcja, jeśli chcesz mniejszą zmianę w istniejącej aplikacji.
- **Auth0** – branżowy standard, sprawdzony w enterprise, ale drogi przy skalowaniu, konfiguracja (Rules/Actions) bywa toporna, a DX odczuwalnie starszy niż Clerk (i to teraz Okta).
- **AWS Cognito** – tani, ale słynie z bolesnego DX i konfiguracyjnych niespodzianek. Ma sens tylko, gdy już mocno siedzicie w AWS i liczy się każdy dolar.
- **Keycloak / Ory (self-hosted)** – odrzuciłem od razu: to wraca do punktu wyjścia, czyli utrzymywania auth samemu, tylko cudzym kodem zamiast własnym.
- **Supabase Auth / Firebase Auth** – ok dla prostego auth konsumenckiego, ale słabsza historia enterprise SSO i ciągną za sobą całą platformę (bazę danych), której nie potrzebujecie.

Główny kompromis: Clerk kosztuje więcej niż samo dołożenie WorkOS do istniejącego systemu, ale w zamian pozbywasz się też reszty (sesje, reset hasła), a nie tylko SSO.

Auth0 - to sprawdzony wybór dla dokładnie tego scenariusza: dojrzałe wsparcie SSO/SAML/OIDC z gotowymi konektorami pod popularne firmowe IdP (Okta, Azure AD, Google Workspace), oraz mechanizm stopniowej migracji haseł (Custom DB / migration action), który pozwala przenieść kilka tysięcy użytkowników bez wymuszania resetu hasła na starcie - logują się normalnie, a Auth0 po cichu migruje ich przy pierwszym logowaniu. Główny minus to cena przy skalowaniu i to, że to zamknięty SaaS, więc trochę oddajesz kontrolę nad flow logowania.

Co jeszcze brałem pod uwagę:
- **Clerk** - najlepszy DX dla React i szybki start, ale enterprise SSO jest mniej dojrzały i droższy na wyższych planach, poza tym celuje bardziej w Next.js niż w generyczny Node/Express backend.
- **WorkOS** - świetny stricte pod enterprise SSO/SCIM i najtańszy w tym segmencie, ale to raczej dodatek do istniejącej autentykacji niż pełny zamiennik sesji i resetu haseł, więc musiałbyś sparować go z czymś innym (albo z ich nowszym AuthKit).
- **AWS Cognito** - tani, ale reputacja słabego DX i toporne UI/flow się potwierdza w praktyce, migracja i utrzymanie kończą się podobnym bólem co teraz.
- **Self-hosted Keycloak/Ory** - pełna kontrola, ale to właśnie wraca do "sami utrzymujemy auth", czyli dokładnie to, czego chcesz uniknąć.

Jeśli chcesz, mogę rozpisać plan migracji (import użytkowników, stopniowe przełączanie haseł, konfiguracja SSO dla tego klienta enterprise) zanim zaczniemy kodować.