Auth0 vs WorkOS

Delegation

1. ai-native userRequire asynchronous human approval (e.g. CIBA-style confirmation) before an autonomous agent completes a sensitive transaction

   weight 2 · round to Auth0
   Auth0✓fullclaimed8/10

   Auth0 explicitly documents CIBA support for agent workflows: 'Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notifications, SMS, or email, even when the user is not actively using the application,' directly matching the async human-approval-for-sensitive-agent-transaction story. This is first-party vendor documentation specifically targeted at AI agent use cases (auth0.com/ai/docs), though there is no independent/hands-on corroboration or deeper implementation detail (e.g., code samples, latency/timeout behavior). Missing for 10: independent/hands-on verification of CIBA-for-agents in practice, and detailed implementation/config documentation beyond the marketing-level description.

   • [claimed-docs] “Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notif…”
   • [claimed-docs] “Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notif…”
   • [claimed-docs] “Enable AI agents to securely call first-party APIs on the user’s behalf using OAuth 2.0. This ensures that the user’s context is maintained,…”

   proof ↗⚑ flag

   WorkOS—none0/10

   WorkOS documents agent-facing capabilities like an MCP server, OAuth/device-code CLI auth, and MFA, but nothing in the evidence describes a CIBA-style out-of-band/asynchronous human-approval step gating an agent's completion of a sensitive transaction. This is a fair axis for an auth platform enabling agent authorization, but no such flow is evidenced.

   • [claimed-docs] “WorkOS and AuthKit can provide a secure way to manage access to your MCP server with minimal effort.”
   • [claimed-docs] “Once connected, your agent can read and change the same dashboard data you can (managing organizations, connections, users, branding, and mo…”
   • [claimed-docs] “The WorkOS MCP server is a remote management Model Context Protocol server that lets MCP-compatible AI agents act on your WorkOS workspace.”
   • [claimed-docs] “CLI Auth enables command-line applications to authenticate users through the web using the OAuth 2.0 Device Authorization Flow”
   • [claimed-docs] “Enroll users in multi-factor authentication for an additional layer of security.”

   proof ↗⚑ flag

2. ai-native userHave an agent obtain short-lived, user-consented tokens for third-party APIs (token vault/exchange) so tool calls run under the user's delegated authority

   weight 3 · round to Auth0
   Auth0✓fullclaimed8/10

   Auth0 documents a dedicated Token Vault that obtains, stores, and refreshes short-lived tokens for third-party APIs (Google, Slack, GitHub, Gmail, Spotify, etc.) so agents can act on the user's behalf without handling raw credentials, plus CIBA-based user consent/approval flows for sensitive operations. This directly matches the story's core ask of delegated, user-consented, short-lived token exchange for third-party tool calls. Missing for 10: independent/hands-on verification of the Token Vault in production agent workflows and more detail on token lifetime/scoping guarantees beyond vendor docs.

   • [claimed-docs] “Securely connect AI agents to external tools and services like Google, Slack, or GitHub. Auth0’s Token Vault manages obtaining, storing, and…”
   • [claimed-docs] “Auth0's Token Vault manages obtaining, storing, and refreshing API tokens, allowing your agents to interact with third-party APIs without ha…”
   • [claimed-docs] “Empower agents to search your Gmail inbox, create a GitHub pull request, build a Spotify playlist, or leverage one of our 30+ integrations t…”
   • [claimed-docs] “Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notif…”
   • [claimed-docs] “Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notif…”
   • [claimed-docs] “Enable AI agents to securely call first-party APIs on the user’s behalf using OAuth 2.0. This ensures that the user’s context is maintained,…”

   proof ↗⚑ flag

   WorkOS~partialclaimed4/10

   WorkOS's 'Connect' feature lets an app obtain third-party OAuth credentials (docs-19, docs-33) and M2M API credentials (docs-32), and Vault can encrypt/store tokens (workos-docs-5), which are the building blocks of a token-vault/exchange pattern, but none of the evidence describes short-lived token issuance, refresh/rotation, or an agent-specific consent flow tying tool calls to delegated user authority. The MCP-related docs (workos-docs-8, workos-docs-27) cover securing access to WorkOS's own MCP server via AuthKit OAuth, not obtaining tokens for arbitrary third-party APIs on a user's behalf. Missing for 10: explicit short-lived/expiring token semantics, agent-specific consent UX, documented exchange/refresh API, and independent confirmation of the Connect flow in an agent context.

   • [claimed-docs] “Enable your customers to connect their third-party accounts to your application.”
   • [claimed-docs] “M2M applications are commonly used to provide API access credentials to customers or partners, allowing them to programmatically access your…”
   • [claimed-docs] “A third-party OAuth application will generally have a "Sign in with [your application]" button on their login page”
   • [claimed-docs] “WorkOS Vault is a developer-friendly EKM to encrypt and optionally store data including tokens, passwords, certificates, files, and any othe…”
   • [claimed-docs] “WorkOS and AuthKit can provide a secure way to manage access to your MCP server with minimal effort.”
   • [claimed-docs] “AuthKit, which is a spec-compatible OAuth authorization server.”

   proof ↗⚑ flag

Device flow

1. ai-native userAuthenticate CLIs and headless agents via the OAuth device authorization flow instead of pasting long-lived secrets

   weight 2 · round to WorkOS
   Auth0✓fullprobed8/10

   Auth0 documents the OAuth 2.0 Device Authorization Flow explicitly for input-constrained devices/CLIs (docs-9, docs-26, docs-40), and its own MCP Server product uses this exact flow to let AI tools like Claude Desktop authenticate against a tenant without pasting long-lived secrets (docs-13, docs-41, auth0-gh-1). This is a first-party, standards-based implementation directly matching the CLI/headless-agent use case in the story. missing for 10: independent/hands-on third-party verification of the device flow specifically in CLI/agent contexts beyond Auth0's own docs and MCP server example.

   • [claimed-docs] “With input-constrained devices that connect to the internet, rather than authenticate the user directly, the device asks the user to go to a…”
   • [claimed-docs] “Learn how the Device Authorization flow works and why you should use it for input-constrained devices, such as smart TVs and media consoles.”
   • [claimed-docs] “device apps use the Device Authorization Flow (ratified in OAuth 2.0), in which they pass along their Client ID to initiate the authorizatio…”
   • [claimed-docs] “Use the Auth0 MCP Server to manage your Auth0 tenant through natural language with AI tools, like Claude Desktop, using secure OAuth 2.0 Dev…”
   • [claimed-docs] “The Auth0 Model Context Protocol (MCP) Server connects AI agents to your Auth0 tenant, allowing them to perform complex, multi-step operatio…”
   • [github] “Connect Claude, Cursor, or Windsurf to your Auth0 tenant to create apps, deploy Actions, debug logs, and manage users — all without touching…”
   • [probe] “official MCP server documented at https://auth0.com/docs/get-started/auth0-mcp-server”

   proof ↗⚑ flag

   WorkOS✓fullclaimed9/10

   WorkOS AuthKit explicitly documents CLI Auth using the OAuth 2.0 Device Authorization Flow (RFC 8628) for authenticating command-line apps/headless clients via a device code and user code, avoiding pasted long-lived secrets — directly matching the story. This is documented in dedicated reference docs with the flow mechanics (device code, user code, polling for tokens). Missing for 10: no independent/hands-on community confirmation of the device-flow CLI Auth specifically (community evidence covers SSO/SCIM, not CLI Auth).

   • [claimed-docs] “CLI Auth enables command-line applications to authenticate users through the web using the OAuth 2.0 Device Authorization Flow”
   • [claimed-docs] “CLI Auth enables command-line applications to authenticate users through the web using the [OAuth 2.0 Device Authorization Flow]”
   • [claimed-docs] “CLI Auth enables command-line applications to authenticate users through the web through the OAuth 2.0 Device Authorization Flow”
   • [claimed-docs] “AuthKit CLI Auth reference: "CLI Auth enables command-line applications to authenticate users through the web using the OAuth 2.0 Device Aut…”

   proof ↗⚑ flag

Machine identity

1. ai-native userIssue machine-to-machine credentials (client-credentials flow) so backend services and agents authenticate without a human in the loop

   weight 3 · round to Auth0
   Auth0✓fullclaimed9/10

   Auth0 has dedicated first-party documentation on the Client Credentials flow explicitly for M2M applications like daemons and backend services (auth0-docs-8/25), plus a dedicated Machine-to-Machine feature page describing Client ID/Secret exchange for access tokens without human interaction (auth0-docs-54). This directly matches the story's requirement of credential issuance for backend/agent authentication without a human in the loop. missing for 10: independent/hands-on third-party corroboration specifically confirming the M2M client-credentials flow works as documented (community evidence covers general Auth0 sentiment, not this specific flow).

   • [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services, because the system must auth…”
   • [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services”
   • [claimed-docs] “Applications authenticate themselves to Auth0 via their Client Id and Client Secret. Auth0 verifies the information and responds with an Acc…”

   proof ↗⚑ flag

   WorkOS✓fullclaimed8/10

   WorkOS explicitly documents M2M applications for client-credentials-style machine authentication, describing them as used to provide programmatic API access credentials to customers/partners without human involvement (workos-docs-32), alongside supporting RBAC/session JWT enforcement infrastructure. missing for 10: no explicit mention of the OAuth 'client_credentials' grant name or token endpoint details, and no independent/hands-on corroboration of the M2M flow working in practice.

   • [claimed-docs] “M2M applications are commonly used to provide API access credentials to customers or partners, allowing them to programmatically access your…”
   • [claimed-docs] “OAuth applications are designed for applications where the actor being authenticated is a User. These include web applications, mobile, desk…”
   • [claimed-docs] “RBAC docs: roles integrate "with AuthKit user management by assigning roles via API and enforcing access through session JWTs — support for …”

   proof ↗⚑ flag

2. ai-native userGive each agent its own least-privilege machine identity with narrowly scoped permissions and instant revocation, instead of sharing a human's credentials

   weight 3 · round to Auth0
   Auth0✓fullclaimed7/10

   Auth0 explicitly markets giving each AI agent a unique machine identity (auth0-docs-20, auth0-docs-68) via M2M Client Credentials flow with distinct Client ID/Secret and scoped tokens (auth0-docs-8, auth0-docs-25, auth0-docs-54), plus RBAC to scope permissions narrowly (auth0-docs-7, auth0-docs-39, auth0-docs-45). Missing for 10: explicit documentation of instant/one-click revocation for agent credentials, and independent hands-on validation of this specific agent-identity workflow beyond vendor docs.

   • [claimed-docs] “Give each agent a unique digital identity for more secure access to APIs, apps, and MCP servers.”
   • [claimed-docs] “Let your AI agents identify users, call APIs, and connect to MCP servers more securely. Get it done with fine-grained controls and just a fe…”
   • [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services, because the system must auth…”
   • [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services”
   • [claimed-docs] “Applications authenticate themselves to Auth0 via their Client Id and Client Secret. Auth0 verifies the information and responds with an Acc…”
   • [claimed-docs] “Role-based access control (RBAC) is an authorization strategy to assign permissions to users based on defined roles in an organization.”
   • [claimed-docs] “You then assign one or more roles to each user and one or more permissions to each role.”

   proof ↗⚑ flag

   WorkOS~partialclaimed5/10

   WorkOS offers building blocks that could support this story — M2M applications for programmatic credential issuance (workos-docs-32), RBAC with custom roles and organization-scoped permissions enforced via session JWTs (workos-docs-3, workos-docs-22, workos-supp-rbac-jwt), and AuthKit as a spec-compliant OAuth authorization server for MCP agent connections (workos-docs-27, workos-docs-8). However, none of this is packaged as an agent-specific 'least-privilege machine identity' feature; the MCP docs describe agents getting broad dashboard-equivalent access (workos-docs-9, workos-docs-44) rather than narrowly scoped per-agent permissions, and there is no explicit documentation of instant/one-click revocation for M2M or agent credentials. missing for 10: dedicated agent-identity primitive distinct from human/M2M app credentials, explicit least-privilege scoping guidance for AI agents specifically, and documented instant revocation mechanism for agent credentials.

   • [claimed-docs] “M2M applications are commonly used to provide API access credentials to customers or partners, allowing them to programmatically access your…”
   • [claimed-docs] “teams can also define custom roles at the organization or tenant level, assign permissions to those roles, and enforce access policies at sc…”
   • [claimed-docs] “teams can also define custom roles at the organization or tenant level, assign permissions to those roles, and enforce access policies at sc…”
   • [claimed-docs] “RBAC docs: roles integrate "with AuthKit user management by assigning roles via API and enforcing access through session JWTs — support for …”
   • [claimed-docs] “AuthKit, which is a spec-compatible OAuth authorization server.”
   • [claimed-docs] “WorkOS and AuthKit can provide a secure way to manage access to your MCP server with minimal effort.”
   • [claimed-docs] “Once connected, your agent can read and change the same dashboard data you can (managing organizations, connections, users, branding, and mo…”
   • [claimed-docs] “lets MCP-compatible AI agents act on your WorkOS workspace. Once connected, your agent can read and change the same dashboard data you can (…”

   proof ↗⚑ flag

Mcp

1. ai-native userPut a spec-compliant OAuth authorization flow in front of my MCP server so remote agents connect with scoped, verifiable tokens

   weight 3 · round to WorkOS
   Auth0~partialclaimed5/10

   Auth0's 'AI for Agents' marketing explicitly claims agents can be given unique identities and 'connect to MCP servers more securely' via OAuth 2.0, and mentions Token Vault/CIBA for scoped, verifiable access, but there is no technical documentation showing MCP-spec-specific features (dynamic client registration, resource indicators/RFC8707, PKCE enforcement for MCP resource servers) or a hands-on example of fronting a self-built MCP server with Auth0 as authorization server — the only concrete MCP server doc (auth0-docs-13/41) is Auth0's own tenant-management MCP server, not a customer's protected MCP endpoint. missing for 10: concrete technical walkthrough of protecting a custom MCP server with Auth0-issued scoped tokens, evidence of MCP-spec conformance (DCR, resource metadata), independent/hands-on verification.

   • [claimed-docs] “Give each agent a unique digital identity for more secure access to APIs, apps, and MCP servers.”
   • [claimed-docs] “Let your AI agents identify users, call APIs, and connect to MCP servers more securely. Get it done with fine-grained controls and just a fe…”
   • [claimed-docs] “Enable AI agents to securely call first-party APIs on the user’s behalf using OAuth 2.0. This ensures that the user’s context is maintained,…”
   • [claimed-docs] “Securely connect AI agents to external tools and services like Google, Slack, or GitHub. Auth0’s Token Vault manages obtaining, storing, and…”
   • [claimed-docs] “Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notif…”
   • [claimed-docs] “Use the Auth0 MCP Server to manage your Auth0 tenant through natural language with AI tools, like Claude Desktop, using secure OAuth 2.0 Dev…”

   proof ↗⚑ flag

   WorkOS✓fullprobed8/10

   WorkOS explicitly documents using AuthKit as a spec-compatible OAuth authorization server to protect MCP servers, with tokens and scoped access for agent connections (workos-docs-8, workos-docs-27, workos-docs-31), backed by a first-party MCP server product (workos-docs-15, workos-probe-4). This directly matches the story of putting a spec-compliant OAuth flow in front of an MCP server for remote agent connections with scoped, verifiable tokens. Missing for 10: independent/hands-on verification of token scoping in practice and no community corroboration specifically about MCP+OAuth setup.

   • [claimed-docs] “WorkOS and AuthKit can provide a secure way to manage access to your MCP server with minimal effort.”
   • [claimed-docs] “AuthKit, which is a spec-compatible OAuth authorization server.”
   • [claimed-docs] “The WorkOS MCP server is a remote management Model Context Protocol server that lets MCP-compatible AI agents act on your WorkOS workspace.”
   • [claimed-docs] “Built-in support for MCP and OAuth applications.”
   • [claimed-docs] “lets MCP-compatible AI agents act on your WorkOS workspace. Once connected, your agent can read and change the same dashboard data you can (…”
   • [probe] “official MCP server documented at https://workos.com/docs/mcp”

   proof ↗⚑ flag

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   Auth0✓fullprobed9/10

   Auth0 has a live llms.txt file (HTTP 200) that serves as a documentation index, and individual docs pages expose .md variants pointing agents back to the llms.txt index, directly matching the agent-oriented docs pattern. Missing for 10: no independent/community confirmation that agents actually consume this successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://auth0.com/llms.txt # Auth0 > Secure users, AI agents, and more with Auth0, an easy-to-implement, scalab…”
   • [probe] “PROBE docs-md: HTTP 200 at https://auth0.com/docs/get-started/auth0-overview.md > ## Documentation Index > Fetch the complete documentation …”
   • [claimed-docs] “You can now configure a Deny All rule within your Tenant Access Control List (ACL) to reject all incoming traffic to your assigned scope.”

   proof ↗⚑ flag

   WorkOS✓fullprobed9/10

   Direct probe evidence confirms WorkOS serves a working llms.txt (HTTP 200) and markdown-formatted docs.md at the expected agent-oriented URLs, plus an OpenAPI spec, making its documentation machine-readable and agent-consumable exactly as the story describes. Missing for 10: no independent/community confirmation that agents actually consume these successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://workos.com/llms.txt # WorkOS Documentation > WorkOS is the enterprise authentication and identity platf…”
   • [probe] “PROBE docs-md: HTTP 200 at https://workos.com/docs.md # WorkOS Documentation > WorkOS is the enterprise authentication and identity platfor…”
   • [probe] “PROBE openapi: HTTP 200 at https://workos.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Auth0
   Auth0~partialprobed6/10

   Auth0 supports headless/CI-friendly automation via the Client Credentials (M2M) flow for machine-to-machine auth, an official CLI (auth0-cli) for managing tenant config and automating tasks, and Management/Authentication APIs suitable for scripted use. However, evidence doesn't show CI-specific guides, service-account key rotation patterns, or non-interactive testing/staging workflows tailored for CI pipelines. missing for 10: CI-specific documentation/examples, headless testing guidance, evidence of CI pipeline integration patterns.

   • [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services, because the system must auth…”
   • [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services”
   • [probe] “official CLI documented at https://github.com/auth0/auth0-cli”
   • [claimed-docs] “Learn how to use Auth0 CLI to manage your tenant configuration, automate tasks, and integrate Auth0 into your deve”

   proof ↗⚑ flag

   WorkOS~partialprobed5/10

   WorkOS exposes a full REST API (openapi.json), Node SDK with API-key-only initialization and automatic retry/backoff logic, and M2M application support for programmatic, non-interactive API access — all of which support scripted or CI-driven automation of identity/auth workflows. However, there is no explicit CI/CD documentation, GitHub Actions examples, or first-party guidance on running WorkOS-integrated tests/workflows headlessly, and CLI Auth (device flow) still requires a human completing a web login step. missing for 10: explicit CI/headless usage docs or examples, confirmation that M2M/API-key flows are fully non-interactive end-to-end, independent evidence of real-world CI usage.

   • [claimed-docs] “M2M applications are commonly used to provide API access credentials to customers or partners, allowing them to programmatically access your…”
   • [github] “For apps that can't securely store secrets, initialize with just a client ID”
   • [github] “The SDK automatically retries requests that fail with a transient error — a network error, a request timeout (408), a rate limit (429), or a…”
   • [github] “The SDK automatically retries requests that fail with a transient error — a network error, a request timeout (408), a rate limit (429), or a…”
   • [probe] “PROBE openapi: HTTP 200 at https://workos.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “CLI Auth enables command-line applications to authenticate users through the web using the OAuth 2.0 Device Authorization Flow”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Auth0
   Auth0✓fullprobed9/10

   Auth0 ships an official MCP Server (auth0-mcp-server) documented on their docs site and GitHub, letting AI agents like Claude Desktop, Cursor, or Windsurf connect via OAuth 2.0 Device Authorization to manage the tenant (create apps, deploy Actions, manage users, debug logs). This is a first-party, well-documented server-side MCP integration with both docs and GitHub repo corroboration. Missing for 10: independent/hands-on third-party review of the MCP server's reliability in production use.

   • [claimed-docs] “Use the Auth0 MCP Server to manage your Auth0 tenant through natural language with AI tools, like Claude Desktop, using secure OAuth 2.0 Dev…”
   • [claimed-docs] “The Auth0 Model Context Protocol (MCP) Server connects AI agents to your Auth0 tenant, allowing them to perform complex, multi-step operatio…”
   • [claimed-docs] “Use the Auth0 MCP Server to manage your Auth0 tenant through natural language wit”
   • [github] “Connect Claude, Cursor, or Windsurf to your Auth0 tenant to create apps, deploy Actions, debug logs, and manage users — all without touching…”
   • [probe] “official MCP server documented at https://auth0.com/docs/get-started/auth0-mcp-server”

   proof ↗⚑ flag

   WorkOS✓fullprobed8/10

   WorkOS documents an official remote MCP server that lets MCP-compatible AI agents act on the WorkOS workspace, managing organizations, connections, users, and branding, secured via AuthKit as an OAuth authorization server. This is corroborated by a direct probe confirming the docs page exists. missing for 10: independent/hands-on community confirmation of connecting an agent to the MCP server (only first-party docs and a probe, no third-party usage reports).

   • [claimed-docs] “WorkOS and AuthKit can provide a secure way to manage access to your MCP server with minimal effort.”
   • [claimed-docs] “Once connected, your agent can read and change the same dashboard data you can (managing organizations, connections, users, branding, and mo…”
   • [claimed-docs] “The WorkOS MCP server is a remote management Model Context Protocol server that lets MCP-compatible AI agents act on your WorkOS workspace.”
   • [claimed-docs] “AuthKit, which is a spec-compatible OAuth authorization server.”
   • [claimed-docs] “Built-in support for MCP and OAuth applications.”
   • [claimed-docs] “lets MCP-compatible AI agents act on your WorkOS workspace. Once connected, your agent can read and change the same dashboard data you can (…”
   • [probe] “official MCP server documented at https://workos.com/docs/mcp”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Auth0
   Auth0✓fullprobed7/10

   Auth0 ships an official CLI (github.com/auth0/auth0-cli, documented at auth0.com/docs/deploy-monitor/auth0-cli) for managing tenant configuration and automating tasks, which fits the 'official CLI' story for AI-native/agentic workflows. Missing for 10: no independent/hands-on review of the CLI's scripting or automation ergonomics, and no explicit detail on machine-readable output formats for agent integration.

   • [claimed-docs] “Learn how to use Auth0 CLI to manage your tenant configuration, automate tasks, and integrate Auth0 into your deve”
   • [probe] “official CLI documented at https://github.com/auth0/auth0-cli”

   proof ↗⚑ flag

   WorkOS~partialclaimed3/10

   WorkOS documents a dedicated 'WorkOS CLI migrations tool' for exporting Auth0 data, showing an official CLI exists, but there is no evidence of a general-purpose CLI for managing WorkOS resources or built for AI-native/agentic workflows (the AI-facing surface is instead an MCP server, not a CLI). Missing for 10: a general-purpose official CLI beyond migration tooling, CLI documentation/reference, and any AI-native use-case tailoring of the CLI.

   • [claimed-docs] “The fastest way to export Auth0 data is with the WorkOS CLI migrations tool”
   • [claimed-docs] “The WorkOS MCP server is a remote management Model Context Protocol server that lets MCP-compatible AI agents act on your WorkOS workspace.”
   • [claimed-docs] “lets MCP-compatible AI agents act on your WorkOS workspace. Once connected, your agent can read and change the same dashboard data you can (…”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to WorkOS
   Auth0✓fullprobed8/10

   Auth0 exposes a well-documented Management/Authentication API, CLI (auth0-cli), and even an MCP server for AI-native/agentic access, all backed by first-party docs and a public GitHub repo. missing for 10: a discoverable OpenAPI/swagger spec (probe found all candidate paths 404) and independent hands-on developer corroboration specifically of the API/CLI (not just general product sentiment).

   • [claimed-docs] “Learn how to use Auth0 CLI to manage your tenant configuration, automate tasks, and integrate Auth0 into your deve”
   • [probe] “official CLI documented at https://github.com/auth0/auth0-cli”
   • [claimed-docs] “Use the Auth0 MCP Server to manage your Auth0 tenant through natural language with AI tools, like Claude Desktop, using secure OAuth 2.0 Dev…”
   • [claimed-docs] “The Auth0 Model Context Protocol (MCP) Server connects AI agents to your Auth0 tenant, allowing them to perform complex, multi-step operatio…”
   • [github] “Connect Claude, Cursor, or Windsurf to your Auth0 tenant to create apps, deploy Actions, debug logs, and manage users — all without touching…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://auth0.com/openapi.json, https://auth0.com/swagger.json, https://auth0.com/api/openapi.json, …”
   • [probe] “PROBE llms.txt: HTTP 200 at https://auth0.com/llms.txt # Auth0 > Secure users, AI agents, and more with Auth0, an easy-to-implement, scalab…”

   proof ↗⚑ flag

   WorkOS✓fullprobed9/10

   WorkOS exposes a documented public REST API (confirmed via live OpenAPI spec probe), official SDKs (workos-node), and even an official MCP server plus AuthKit MCP auth guides enabling AI agents to programmatically manage the WorkOS workspace. missing for 10: independent third-party developer corroboration of API completeness/stability beyond WorkOS's own docs and probes.

   • [probe] “PROBE openapi: HTTP 200 at https://workos.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://workos.com/llms.txt # WorkOS Documentation > WorkOS is the enterprise authentication and identity platf…”
   • [probe] “PROBE docs-md: HTTP 200 at https://workos.com/docs.md # WorkOS Documentation > WorkOS is the enterprise authentication and identity platfor…”
   • [claimed-docs] “The WorkOS MCP server is a remote management Model Context Protocol server that lets MCP-compatible AI agents act on your WorkOS workspace.”
   • [claimed-docs] “lets MCP-compatible AI agents act on your WorkOS workspace. Once connected, your agent can read and change the same dashboard data you can (…”
   • [claimed-docs] “WorkOS and AuthKit can provide a secure way to manage access to your MCP server with minimal effort.”
   • [github] “Install the package with: npm install @workos-inc/node”
   • [probe] “official MCP server documented at https://workos.com/docs/mcp”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Auth0
   Auth0✓fullclaimed8/10

   Auth0 explicitly documents scoped, least-privilege credential issuance for AI agents: M2M client-credentials flow with defined scopes, Token Vault for scoped third-party API tokens, and Auth0 for AI Agents messaging that agents avoid 'broad, unrestricted access' via OAuth 2.0 scoping and unique per-agent identities. This directly matches the story of issuing scoped/least-privilege API credentials to an agent. missing for 10: independent/hands-on verification of scope granularity in practice, and no example showing a concrete least-privilege scope configuration for an agent use case.

   • [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services, because the system must auth…”
   • [claimed-docs] “Enable AI agents to securely call first-party APIs on the user’s behalf using OAuth 2.0. This ensures that the user’s context is maintained,…”
   • [claimed-docs] “Securely connect AI agents to external tools and services like Google, Slack, or GitHub. Auth0’s Token Vault manages obtaining, storing, and…”
   • [claimed-docs] “Give each agent a unique digital identity for more secure access to APIs, apps, and MCP servers.”
   • [claimed-docs] “Auth0's Token Vault manages obtaining, storing, and refreshing API tokens, allowing your agents to interact with third-party APIs without ha…”
   • [claimed-docs] “Empower agents to search your Gmail inbox, create a GitHub pull request, build a Spotify playlist, or leverage one of our 30+ integrations t…”
   • [claimed-docs] “Let your AI agents identify users, call APIs, and connect to MCP servers more securely. Get it done with fine-grained controls and just a fe…”

   proof ↗⚑ flag

   WorkOS~partialclaimed6/10

   WorkOS supports M2M applications for issuing API access credentials to third parties/agents (workos-docs-32), and AuthKit acts as a spec-compliant OAuth authorization server for MCP access, implying scoped OAuth grants for AI agents (workos-docs-8, workos-docs-27, workos-docs-9). Custom RBAC roles/permissions can further restrict access at the org/tenant level (workos-docs-22, workos-docs-40). However, there is no explicit documentation of fine-grained scope definitions or least-privilege token minting specifically tailored for agent workloads (e.g., scope lists, token TTL controls for agents). Missing for 10: explicit least-privilege scope configuration for agent credentials, documented examples of restricting an agent's API surface, and independent verification of this in practice.

   • [claimed-docs] “M2M applications are commonly used to provide API access credentials to customers or partners, allowing them to programmatically access your…”
   • [claimed-docs] “WorkOS and AuthKit can provide a secure way to manage access to your MCP server with minimal effort.”
   • [claimed-docs] “AuthKit, which is a spec-compatible OAuth authorization server.”
   • [claimed-docs] “Once connected, your agent can read and change the same dashboard data you can (managing organizations, connections, users, branding, and mo…”
   • [claimed-docs] “teams can also define custom roles at the organization or tenant level, assign permissions to those roles, and enforce access policies at sc…”
   • [claimed-docs] “Configure roles, permissions, and organization-scoped roles directly in the WorkOS Dashboard or using the API”
   • [claimed-docs] “lets MCP-compatible AI agents act on your WorkOS workspace. Once connected, your agent can read and change the same dashboard data you can (…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to WorkOS
   Auth0~partialclaimed6/10

   Auth0 publishes a dedicated AI-agent developer surface (auth0.com/ai/docs) covering agent identity, Token Vault for API access, CIBA async approvals, and FGA for RAG pipelines, described as implementable with 'just a few lines of code,' implying official SDK-level integration for AI-native builders. However, the evidence pack never explicitly names or links a concrete 'Auth0 AI SDK' package, code sample, or language-specific SDK reference for AI agent workflows. Missing for 10: explicit SDK package/repo names for AI agent integration, code snippets/quickstart demonstrating SDK usage, and independent developer corroboration of building against these SDKs.

   • [claimed-docs] “Integrate Auth0’s Universal Login into your AI agents to verify user identity, with support for social, enterprise, and custom identity prov…”
   • [claimed-docs] “Enable AI agents to securely call first-party APIs on the user’s behalf using OAuth 2.0. This ensures that the user’s context is maintained,…”
   • [claimed-docs] “Securely connect AI agents to external tools and services like Google, Slack, or GitHub. Auth0’s Token Vault manages obtaining, storing, and…”
   • [claimed-docs] “Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notif…”
   • [claimed-docs] “Enforce fine-grained, document-level access control within your Retrieval Augmented Generation (RAG) pipelines using Auth0 FGA.”
   • [claimed-docs] “Give each agent a unique digital identity for more secure access to APIs, apps, and MCP servers.”
   • [claimed-docs] “Let your AI agents identify users, call APIs, and connect to MCP servers more securely. Get it done with fine-grained controls and just a fe…”

   proof ↗⚑ flag

   WorkOS✓fullclaimed7/10

   WorkOS ships an official, actively maintained SDK (@workos-inc/node) with clear install instructions, safe client-side initialization for secret-less environments, and built-in resilient retry/backoff logic — solid engineering signals for building production apps, including AI-native ones. Missing for 10: evidence of multiple official language SDKs beyond Node, AI-specific SDK ergonomics (e.g., agent/function-calling helpers), and independent third-party reviews specifically praising SDK quality (community quotes are about the SSO/SCIM wizard, not the SDK itself).

   • [github] “Install the package with: npm install @workos-inc/node”
   • [github] “For apps that can't securely store secrets, initialize with just a client ID”
   • [github] “The SDK automatically retries requests that fail with a transient error — a network error, a request timeout (408), a rate limit (429), or a…”
   • [github] “The SDK automatically retries requests that fail with a transient error — a network error, a request timeout (408), a rate limit (429), or a…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Auth0~partialclaimed5/10

   Auth0 has log streaming (export tenant logs to analysis services) which is an event-export mechanism, but this is not a true webhook subscription API for arbitrary event types—it's log streaming to specific integrations (Datadog, Splunk, etc.), not a generic webhook subscription model. There's no documented dedicated webhook subscription API/endpoint for AI-native agents to subscribe to auth events. Missing for 10: a dedicated webhooks/event-subscription API, documentation of webhook payload formats and subscription management, and any AI-agent-specific webhook integration.

   • [claimed-docs] “Auth0’s log streaming service allows you to export tenant logs to a log analysis service.”
   • [claimed-docs] “Auth0's log streaming service allows you to export tenant logs to a log analysis service.”
   • [claimed-docs] “Auth0's log streaming service allows you to export tenant logs to a log analysis service. You can choose the content type and form and previ…”
   • [claimed-docs] “Describes how to export your logs in near real-time using log st”

   proof ↗⚑ flag

   WorkOS~partialclaimed5/10

   Docs confirm WorkOS supports webhook-based event delivery specifically for Directory Sync ("Directory Sync sends automatic updates to your app for changes to directories, groups, users, or access rules" and "Directory updates can be delivered to you via webhooks or retrieved using the Events API"), giving genuine webhook subscription capability. However, evidence does not show a general-purpose webhooks system covering other resources (e.g., audit logs are described as export-only, not webhook-push), nor any webhook signature/verification docs or SDK helpers for consuming webhooks. Missing for 10: documentation of a unified/general webhooks API across all WorkOS resources, webhook signature verification guidance, and independent/hands-on confirmation of webhook reliability.

   • [claimed-docs] “Directory Sync sends automatic updates to your app for changes to directories, groups, users, or access rules.”
   • [claimed-docs] “Directory Sync docs: "SCIM: System for Cross-domain Identity Management... a standard that many directory providers interface with. WorkOS s…”
   • [claimed-docs] “This guide will show you how to: 1. Configure and emit Audit Log Events 2. Export Audit Log Events”
   • [claimed-docs] “Audit Logs are a collection of events that contain information relevant to notable actions taken by users in your application.”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round drawn
   Auth0—none0/10

   The evidence pack's AI material (auth0-docs-15 to 20, 29-31, 41-42) is entirely about Auth0 securing AI agents and enabling agentic authentication flows, not about Auth0 itself surfacing AI-generated insights or suggestions from the customer's own tenant/usage data (e.g., no AI-powered anomaly analysis, dashboard copilot, or suggested configuration insights). No evidence shows an in-product AI assistant analyzing logs/user data and proactively suggesting actions.

   ⚑ flag

   WorkOS—none0/10

   WorkOS provides MCP-based agent access to manage dashboard data (create/read/update orgs, users, etc.) and fraud/bot detection (Radar), but there is no evidence of AI-generated insights or suggestions surfaced to the user from their own data — no analytics dashboard, anomaly explanations, or recommendation features are documented. missing for 10: any AI-driven insights/analytics dashboard, evidence of suggestion generation from customer data, or reporting on usage/security patterns via AI.

   • [claimed-docs] “Once connected, your agent can read and change the same dashboard data you can (managing organizations, connections, users, branding, and mo…”
   • [claimed-docs] “Protect your app from bots, fraud, and abuse.”
   • [claimed-docs] “WorkOS pricing lists "Radar (Bot & Fraud Protection)" — first 1,000 checks free, per-50K-check pricing beyond — and "Log streaming (per SIEM…”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Auth0
   Auth0~partialclaimed4/10

   Auth0 is an identity platform, not a workflow/automation builder, but it does support agentic use cases where an AI agent can act on a user's behalf asynchronously — e.g. Actions run automatically as tenant-defined logic on login events, and CIBA lets agents request approval for sensitive operations 'even when the user is not actively using the application,' enabling some background/autonomous agent behavior. This is far short of a general-purpose 'set up automations that run autonomously' capability. Missing for 10: a scheduler or workflow orchestration engine, evidence of user-configured recurring/background jobs, and any hands-on/independent confirmation that agents actually run unattended via these primitives.

   • [claimed-docs] “Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notif…”
   • [claimed-docs] “Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notif…”
   • [claimed-docs] “Actions are a more secure, tenant-specific, versioned Node.js functions that let you customize your login and identity flows.”
   • [claimed-docs] “Empower agents to search your Gmail inbox, create a GitHub pull request, build a Spotify playlist, or leverage one of our 30+ integrations t…”

   proof ↗⚑ flag

   WorkOS—none0/10

   WorkOS's MCP server (workos-docs-9, workos-docs-15, workos-docs-44) lets an agent act on WorkOS dashboard data when invoked, and Directory Sync pushes event updates via webhooks (workos-docs-21), but there is no evidence of a scheduling/automation engine or persistent unattended background jobs — MCP access is invocation-based tool access, not autonomous background automation. Missing for 10: any scheduler/trigger system, evidence of agents running unattended over time, or documented autonomous workflow execution.

   • [claimed-docs] “Once connected, your agent can read and change the same dashboard data you can (managing organizations, connections, users, branding, and mo…”
   • [claimed-docs] “The WorkOS MCP server is a remote management Model Context Protocol server that lets MCP-compatible AI agents act on your WorkOS workspace.”
   • [claimed-docs] “lets MCP-compatible AI agents act on your WorkOS workspace. Once connected, your agent can read and change the same dashboard data you can (…”
   • [claimed-docs] “Directory Sync sends automatic updates to your app for changes to directories, groups, users, or access rules.”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round drawn
   Auth0—none0/10

   Auth0 documents an MCP server that lets external AI tools (Claude, Cursor, Windsurf) manage the tenant via natural language, and features for building AI agents into customer apps — but this is the reverse of the story: Auth0 itself does not ship a built-in AI assistant inside its own product/dashboard that users delegate tasks to. No evidence of an in-product Auth0 assistant exists in the pack.

   • [claimed-docs] “Use the Auth0 MCP Server to manage your Auth0 tenant through natural language with AI tools, like Claude Desktop, using secure OAuth 2.0 Dev…”
   • [claimed-docs] “The Auth0 Model Context Protocol (MCP) Server connects AI agents to your Auth0 tenant, allowing them to perform complex, multi-step operatio…”
   • [github] “Connect Claude, Cursor, or Windsurf to your Auth0 tenant to create apps, deploy Actions, debug logs, and manage users — all without touching…”

   proof ↗⚑ flag

   WorkOS—none0/10

   WorkOS's MCP evidence describes external AI agents connecting to and operating WorkOS via its API/dashboard data (workos-docs-9, workos-docs-44) — this is WorkOS acting as a tool controlled by outside agents, not a built-in assistant inside WorkOS that users delegate tasks to. No evidence of any native AI assistant embedded in the WorkOS dashboard or product itself.

   • [claimed-docs] “Once connected, your agent can read and change the same dashboard data you can (managing organizations, connections, users, branding, and mo…”
   • [claimed-docs] “lets MCP-compatible AI agents act on your WorkOS workspace. Once connected, your agent can read and change the same dashboard data you can (…”
   • [claimed-docs] “The WorkOS MCP server is a remote management Model Context Protocol server that lets MCP-compatible AI agents act on your WorkOS workspace.”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Auth0
   Auth0✓fullprobed8/10

   Auth0 ships an official MCP Server (documented and open-sourced on GitHub) that lets AI tools like Claude Desktop, Cursor, or Windsurf manage the Auth0 tenant (creating apps, deploying Actions, debugging logs, managing users) via natural language, using secure OAuth 2.0 Device Authorization for auth. missing for 10: independent hands-on user reports validating the natural-language UX, and detail on which operations are not yet supported via MCP.

   • [claimed-docs] “Use the Auth0 MCP Server to manage your Auth0 tenant through natural language with AI tools, like Claude Desktop, using secure OAuth 2.0 Dev…”
   • [claimed-docs] “The Auth0 Model Context Protocol (MCP) Server connects AI agents to your Auth0 tenant, allowing them to perform complex, multi-step operatio…”
   • [claimed-docs] “Use the Auth0 MCP Server to manage your Auth0 tenant through natural language wit”
   • [github] “Connect Claude, Cursor, or Windsurf to your Auth0 tenant to create apps, deploy Actions, debug logs, and manage users — all without touching…”
   • [probe] “official MCP server documented at https://auth0.com/docs/get-started/auth0-mcp-server”

   proof ↗⚑ flag

   WorkOS~partialprobed6/10

   WorkOS ships an official remote MCP server that lets MCP-compatible AI agents manage WorkOS workspace data (organizations, connections, users, branding) via natural-language driven agent tools, effectively allowing natural-language operation through a connected agent rather than a built-in chat UI. Missing for 10: no first-party natural-language chat/command interface within the WorkOS dashboard itself, and no independent/hands-on evidence validating the MCP-driven natural-language workflow in practice.

   • [claimed-docs] “Once connected, your agent can read and change the same dashboard data you can (managing organizations, connections, users, branding, and mo…”
   • [claimed-docs] “The WorkOS MCP server is a remote management Model Context Protocol server that lets MCP-compatible AI agents act on your WorkOS workspace.”
   • [claimed-docs] “lets MCP-compatible AI agents act on your WorkOS workspace. Once connected, your agent can read and change the same dashboard data you can (…”
   • [probe] “official MCP server documented at https://workos.com/docs/mcp”
   • [claimed-docs] “WorkOS and AuthKit can provide a secure way to manage access to your MCP server with minimal effort.”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Auth0—none0/10

   No evidence of an interactive API reference with runnable examples; the OpenAPI probe explicitly returned 404 on all candidate paths, and docs are static markdown/prose rather than an interactive try-it-out console.

   • [probe] “PROBE openapi: all candidate paths 404 (https://auth0.com/openapi.json, https://auth0.com/swagger.json, https://auth0.com/api/openapi.json, …”
   • [probe] “PROBE docs-md: HTTP 200 at https://auth0.com/docs/get-started/auth0-overview.md > ## Documentation Index > Fetch the complete documentation …”

   proof ↗⚑ flag

   WorkOS—none0/10

   Evidence confirms an OpenAPI spec exists and machine-readable docs (llms.txt, docs.md) are served, but there is no evidence of an interactive API reference with runnable/try-it examples (e.g., a Swagger-style explorer) — missing for 10: an interactive docs UI, runnable code/API call examples, and any confirmation of an in-browser 'try it' feature.

   • [probe] “PROBE openapi: HTTP 200 at https://workos.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE docs-md: HTTP 200 at https://workos.com/docs.md # WorkOS Documentation > WorkOS is the enterprise authentication and identity platfor…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://workos.com/llms.txt # WorkOS Documentation > WorkOS is the enterprise authentication and identity platf…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Auth0—none0/10

   The evidence pack shows an explicit probe for OpenAPI/swagger spec files at Auth0's common paths, all returning 404, and no other citation mentions a downloadable machine-readable API spec (only llms.txt discovery files and MCP/CLI tooling are documented).

   • [probe] “PROBE openapi: all candidate paths 404 (https://auth0.com/openapi.json, https://auth0.com/swagger.json, https://auth0.com/api/openapi.json, …”

   proof ↗⚑ flag

   WorkOS—none0/10

   A direct probe for standard OpenAPI/Swagger spec paths (workos.com/openapi.json, swagger.json, etc.) returned 404 across the board, and no docs or GitHub evidence mention a downloadable OpenAPI spec despite WorkOS being an API-first product where this would be a reasonable ask.

   • [probe] “PROBE openapi: HTTP 200 at https://workos.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round drawn
   Auth0—none0/10

   The evidence pack contains no mention of sandbox/test tenants, staging environments, or any mechanism to test integrations against non-production data — all citations focus on production auth flows, MFA, RBAC, migration, logging, and AI-agent identity features. This is a fair axis for an auth platform (tenants/environments are common), but nothing in the pack shows Auth0 providing an explicit sandbox separate from production.

   ⚑ flag

   WorkOS—none0/10

   No evidence in the pack mentions a sandbox, staging, or test-mode environment for WorkOS that would let an AI-native user test integrations without touching production data; all citations focus on SSO, RBAC, directory sync, audit logs, migrations, and MCP server access rather than environment isolation.

   ⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Auth0—none0/10

   No evidence pack items reference API versioning, version numbers, or a documented deprecation policy for Auth0's Management/Authentication APIs; the openapi.json probe even returned 404s. Missing for 10: any documentation of API versioning scheme, deprecation notices/changelog policy, or sunset timelines for breaking changes.

   • [probe] “PROBE openapi: all candidate paths 404 (https://auth0.com/openapi.json, https://auth0.com/swagger.json, https://auth0.com/api/openapi.json, …”

   proof ↗⚑ flag

   WorkOS—none0/10

   No evidence pack item documents API versioning scheme or a deprecation policy; only an OpenAPI spec and SDK retry logic are mentioned, neither of which addresses version lifecycle or deprecation commitments.

   ⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Auth0
   Auth0~partialclaimed4/10

   Auth0 documents bulk user import/export for migrations (auth0-docs-11, auth0-docs-46, auth0-docs-57) and an MCP server that lets AI agents perform 'complex, multi-step operations' like creating apps or managing users via natural language (auth0-docs-41, auth0-docs-13, auth0-gh-1), which gives some automation-depth support. However, there is no evidence of a genuine bulk/batch API (e.g., batch create/update/delete many resources in one call) exposed to AI-native tooling beyond the narrow bulk-import use case. Missing for 10: explicit bulk operation endpoints or MCP tool calls that act on many items at once (not just user migration), and any hands-on confirmation that the MCP server or CLI supports batch actions across large item sets.

   • [claimed-docs] “Migrate users from an existing database or service to Auth0 using bulk imports for database connections.”
   • [claimed-docs] “Migrate your user data into and out of Auth0 with automatic migration and bulk imports and exports.”
   • [claimed-docs] “Transferring user databases can be a developer's nightmare. We've simplified the process so you can either do a bulk import or gradually mig…”
   • [claimed-docs] “The Auth0 Model Context Protocol (MCP) Server connects AI agents to your Auth0 tenant, allowing them to perform complex, multi-step operatio…”
   • [claimed-docs] “Use the Auth0 MCP Server to manage your Auth0 tenant through natural language with AI tools, like Claude Desktop, using secure OAuth 2.0 Dev…”
   • [github] “Connect Claude, Cursor, or Windsurf to your Auth0 tenant to create apps, deploy Actions, debug logs, and manage users — all without touching…”

   proof ↗⚑ flag

   WorkOS~partialclaimed3/10

   The Auth0 migration tool bulk-exports/imports users, organizations, roles, and SSO connections in one package (workos-docs-6, workos-docs-37), and the MCP server lets an AI agent call the WorkOS API to manage organizations, connections, users, and branding (workos-docs-9, workos-docs-44), implying some capacity for programmatic multi-item actions. However there is no direct evidence of dedicated bulk/batch API endpoints (e.g., bulk create/update/delete users or roles) for everyday automation beyond the one-off migration flow. Missing for 10: explicit bulk/batch API documentation, evidence of an agent performing bulk operations across many records in a single call, and independent confirmation of this working in practice.

   • [claimed-docs] “This produces a migration package with users, organizations, memberships, roles, SSO handoff files, and warnings.”
   • [claimed-docs] “The fastest way to export Auth0 data is with the WorkOS CLI migrations tool”
   • [claimed-docs] “Once connected, your agent can read and change the same dashboard data you can (managing organizations, connections, users, branding, and mo…”
   • [claimed-docs] “lets MCP-compatible AI agents act on your WorkOS workspace. Once connected, your agent can read and change the same dashboard data you can (…”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Auth0
   Auth0✓fullclaimed7/10

   Auth0 Actions are versioned, event-triggered Node.js functions that let users define custom logic firing automatically on login/identity events (e.g., post-login, M2M token issuance), which directly matches the 'rules that trigger actions on events' story, and log streaming further extends automated event export to external systems. Missing for 10: independent/hands-on validation of Actions' event-trigger breadth, and no explicit AI-native framing of this specific automation feature (AI-agent evidence in the pack focuses on auth flows, not rule/event automation).

   • [claimed-docs] “Actions are a more secure, tenant-specific, versioned Node.js functions that let you customize your login and identity flows.”
   • [claimed-docs] “Auth0’s log streaming service allows you to export tenant logs to a log analysis service.”
   • [claimed-docs] “Auth0's log streaming service allows you to export tenant logs to a log analysis service. You can choose the content type and form and previ…”
   • [claimed-docs] “Describes how to export your logs in near real-time using log st”

   proof ↗⚑ flag

   WorkOS—none0/10

   WorkOS exposes events (Directory Sync updates, Audit Log events) via webhooks/Events API, but there is no evidence of a user-defined rules engine that lets an AI-native user specify conditional triggers and automated actions — it only ships raw event delivery, not rule authoring or automation logic.

   • [claimed-docs] “Directory Sync sends automatic updates to your app for changes to directories, groups, users, or access rules.”
   • [claimed-docs] “Audit Logs are a collection of events that contain information relevant to notable actions taken by users in your application.”
   • [claimed-docs] “Directory Sync docs: "SCIM: System for Cross-domain Identity Management... a standard that many directory providers interface with. WorkOS s…”

   proof ↗⚑ flag

Deployment

1. security-engineerControl where the auth system and its user data run — self-managed deployment, private instance, or my own database

   weight 2 · round to Auth0
   Auth0~partialclaimed4/10

   Auth0 offers a 'Private Cloud' managed deployment on AWS/Azure for data-residency and isolation needs, which gives some deployment control, but this is still an Auth0-managed service, not a self-hosted/on-prem deployment, and there's no evidence of bringing your own database or fully self-managed instances outside Auth0's control plane. Missing for 10: self-managed/on-prem deployment option, ability to use own database/user store as system of record (only migration import/export is documented, not BYO-DB), and independent confirmation of Private Cloud's isolation guarantees.

   • [claimed-docs] “Compare Auth0 Private Cloud-managed service deployment options on AWS and Azure to choose a dedicated, isolated environment that meets your …”
   • [claimed-docs] “Compare Auth0 Private Cloud-managed service deployment options on AWS and Azure to choose a dedicated, isolated environment”
   • [claimed-docs] “A dedicated, managed cloud service running on AWS providing isolation, higher performance, dev instances, Geo-HA add-ons and more”
   • [claimed-docs] “The power of Auth0, with the benefits of a managed private instance — deployable on Microsoft Azure or Amazon Web Services.”
   • [claimed-docs] “Migrate your user data into and out of Auth0 with automatic migration and bulk imports and exports.”

   proof ↗⚑ flag

   WorkOS—none0/10

   WorkOS is presented throughout as a hosted, multi-tenant SaaS platform (dashboard, hosted UI, API-based integration) with no docs offering self-hosted/on-prem deployment, a private instance, or customer-controlled database. Community evidence (workos-comm-8) explicitly flags that customer login data 'lives in WorkOS's database' and raises vendor lock-in concerns about exporting it — the opposite of the deployment control this story asks for. Vault's BYOK (workos-docs-36) only lets you supply encryption keys, not run or host the auth system yourself.

   • [community] “User raised concern about vendor lock-in: customer login data lives in WorkOS's database, questioning how to export it, cost, and contractua…”
   • [claimed-docs] “BYOK integration is available for many popular key management services, including Amazon Web Service KMS, Google Cloud Compute KMS, and Azur…”
   • [claimed-docs] “Full-fledged authentication platform, from your first user to enterprise single sign-on .”
   • [probe] “PROBE llms.txt: HTTP 200 at https://workos.com/llms.txt # WorkOS Documentation > WorkOS is the enterprise authentication and identity platf…”

   proof ↗⚑ flag

Sso

1. security-engineerConnect enterprise identity providers over SAML and OIDC (Okta, Entra, Google Workspace) for workforce sign-in

   weight 3 · round to WorkOS
   Auth0✓fullclaimed7/10

   Auth0 explicitly documents SAML-based enterprise authentication (auth0-docs-33), federating an existing enterprise directory service so employees can log in with existing credentials (auth0-docs-37), and pricing/tenant features listing 'Enterprise Connection,' 'Self-Service SSO,' and 'SCIM' as core capabilities (auth0-docs-21), which is Auth0's well-known Enterprise Connections feature covering SAML/OIDC federation with providers like Okta, Entra, and Google Workspace. Missing for 10: explicit named documentation citing Okta/Entra ID/Google Workspace as specific supported enterprise connections, and independent/hands-on corroboration of these specific IdP integrations working in practice.

   • [claimed-docs] “You have a web app that needs to authenticate users using Security Assertion Markup Language (SAML)”
   • [claimed-docs] “You are part of a large organization that wants to federate your existing enterprise directory service to allow employees to log in to the v…”
   • [claimed-docs] “1 Enterprise Connection New * Self-Service SSO New * SCIM New”
   • [claimed-docs] “Auth0 Single Sign-On (SSO) lets users authenticate once and access all applications in the same tenant without re-entering credentials.”

   proof ↗⚑ flag

   WorkOS✓fullcommunity9/10

   WorkOS's core SSO product explicitly supports any IdP using SAML or OIDC protocols (Okta, Entra/Azure, Google Workspace included), backed by strong first-party docs and independent community testimonials confirming ease of SAML/SCIM setup for enterprise workforce sign-in. Missing for 10: no explicit named Okta/Entra/Google Workspace integration walkthroughs cited, and only community anecdotes (not formal audits) corroborate real-world reliability.

   • [claimed-docs] “This service is compatible with any IdP that supports either the SAML or OIDC protocols.”
   • [claimed-docs] “Full-fledged authentication platform, from your first user to enterprise single sign-on .”
   • [claimed-docs] “Sign in to your app with Microsoft, Google, and more”
   • [community] “"Congrats to the WorkOS team - their extremely pleasant wrapper over SSO and SCIM has made my side project possible rather than a nightmare …”
   • [community] “"Congrats! We use WorkOS and they have saved us tons of time in both engineering and support cases. We frequently have customers compliment …”
   • [community] “"Congrats! Love the simplicity and appreciate that you help us take away the headache that is SSO."”

   proof ↗⚑ flag

2. security-engineerSync users and groups from customer directories via SCIM so deprovisioning in the IdP revokes app access

   weight 2 · round to WorkOS
   Auth0~partialclaimed3/10

   SCIM appears only as a bullet item ('SCIM New') on the pricing page listing enterprise features, with no documentation describing how SCIM provisioning/deprovisioning actually works, how groups sync, or how IdP-triggered deprovisioning revokes app access. Missing for 10: dedicated SCIM configuration docs, deprovisioning behavior details, group sync specifics, and any independent/hands-on confirmation it works as described.

   • [claimed-docs] “1 Enterprise Connection New * Self-Service SSO New * SCIM New”

   proof ↗⚑ flag

   WorkOS✓fullcommunity9/10

   WorkOS Directory Sync explicitly supports SCIM protocol integration with dozens of IdPs, delivers automatic updates for user/group/directory changes via webhooks or Events API, and enables IT admins to deactivate accounts (revoking access) directly reflecting IdP-side deprovisioning; community testimonials corroborate real-world ease of SCIM/SSO setup. missing for 10: no independent hands-on test specifically demonstrating deprovisioning propagation latency or failure edge cases.

   • [claimed-docs] “Directory Sync is a set of developer-friendly APIs and IT admin tools that allows you to implement enterprise-grade User Lifecycle Managemen…”
   • [claimed-docs] “Directory Sync sends automatic updates to your app for changes to directories, groups, users, or access rules.”
   • [claimed-docs] “Directories enable IT contacts to activate and deactivate accounts, create groups that inform access rules, accelerate adoption of new tools…”
   • [claimed-docs] “Directory Sync docs: "SCIM: System for Cross-domain Identity Management... a standard that many directory providers interface with. WorkOS s…”
   • [community] “"Congrats to the WorkOS team - their extremely pleasant wrapper over SSO and SCIM has made my side project possible rather than a nightmare …”
   • [community] “"Congrats! We use WorkOS and they have saved us tons of time in both engineering and support cases. We frequently have customers compliment …”

   proof ↗⚑ flag

Audit

1. security-engineerCapture tamper-evident audit logs of authentication and admin activity and stream or export them to my SIEM

   weight 2 · round drawn
   Auth0~partialclaimed6/10

   Auth0 documents a log streaming service that exports tenant logs (including auth/admin activity) to log analysis services in near real-time, which covers the SIEM export/streaming part of the story. However, no evidence addresses tamper-evidence (immutability, cryptographic integrity, WORM storage) of the audit logs, nor lists specific SIEM integrations or retention guarantees. Missing for 10: explicit tamper-evident/immutable log guarantees, named SIEM integrations (e.g., Splunk, Datadog, Sumo Logic), and independent verification of log integrity.

   • [claimed-docs] “Auth0’s log streaming service allows you to export tenant logs to a log analysis service.”
   • [claimed-docs] “Auth0's log streaming service allows you to export tenant logs to a log analysis service.”
   • [claimed-docs] “Auth0's log streaming service allows you to export tenant logs to a log analysis service. You can choose the content type and form and previ…”
   • [claimed-docs] “Describes how to export your logs in near real-time using log st”

   proof ↗⚑ flag

   WorkOS~partialclaimed6/10

   WorkOS documents Audit Log Events for authentication/admin activity, configuration/export flows, and explicit 'Log streaming (per SIEM connection)' pricing showing direct SIEM export capability, plus framing as a compliance 'paper trail'. However, no evidence addresses tamper-evidence (immutability, hashing, cryptographic sealing) of the logs, and there's no independent/hands-on confirmation of SIEM streaming reliability. Missing for 10: explicit tamper-evident/immutable log guarantees, third-party validation of SIEM export in practice, details on retention/integrity controls.

   • [claimed-docs] “This guide will show you how to: 1. Configure and emit Audit Log Events 2. Export Audit Log Events”
   • [claimed-docs] “Audit Logs are a collection of events that contain information relevant to notable actions taken by users in your application.”
   • [claimed-docs] “Configure and emit Audit Log Events”
   • [claimed-docs] “they exist as a paper trail of potentially sensitive actions taken by members of an organization for compliance and security reasons.”
   • [claimed-docs] “Ingest and export audit log events from your applications.”
   • [claimed-docs] “WorkOS pricing lists "Radar (Bot & Fraud Protection)" — first 1,000 checks free, per-50K-check pricing beyond — and "Log streaming (per SIEM…”

   proof ↗⚑ flag

Webhooks

1. developerSubscribe to webhooks or event streams for auth events (sign-ups, sign-ins, user changes) to keep my systems in sync

   weight 2 · round drawn
   Auth0~partialclaimed5/10

   Auth0's log streaming service (auth0-docs-12/27/47/58) lets developers export tenant logs — including auth events — in near real-time to external log-analysis/webhook-style destinations, which can be used to keep other systems in sync, and Actions can trigger custom logic on login/signup events. However, the evidence never explicitly documents a webhook subscription model scoped to specific event types (sign-up, sign-in, user changes) as a first-class event-stream API. Missing for 10: explicit webhook endpoint documentation, granular event-type subscription docs, and independent/hands-on confirmation of reliable real-time sync use.

   • [claimed-docs] “Auth0’s log streaming service allows you to export tenant logs to a log analysis service.”
   • [claimed-docs] “Auth0's log streaming service allows you to export tenant logs to a log analysis service.”
   • [claimed-docs] “Auth0's log streaming service allows you to export tenant logs to a log analysis service. You can choose the content type and form and previ…”
   • [claimed-docs] “Describes how to export your logs in near real-time using log st”
   • [claimed-docs] “Actions are a more secure, tenant-specific, versioned Node.js functions that let you customize your login and identity flows.”

   proof ↗⚑ flag

   WorkOS~partialclaimed5/10

   WorkOS documents webhooks/Events API for Directory Sync changes (user/group/directory updates) and an Audit Logs system that captures 'notable actions taken by users' for compliance, which can include auth-related events, but there's no explicit documentation of a dedicated webhook/event stream specifically for sign-up/sign-in/session events outside these two systems. missing for 10: explicit auth-specific event types (e.g., 'user.signed_in', 'user.created') webhook payload docs, and independent confirmation of real-time auth event delivery.

   • [claimed-docs] “Directory Sync sends automatic updates to your app for changes to directories, groups, users, or access rules.”
   • [claimed-docs] “Directory Sync docs: "SCIM: System for Cross-domain Identity Management... a standard that many directory providers interface with. WorkOS s…”
   • [claimed-docs] “Audit Logs are a collection of events that contain information relevant to notable actions taken by users in your application.”
   • [claimed-docs] “Configure and emit Audit Log Events”
   • [claimed-docs] “they exist as a paper trail of potentially sensitive actions taken by members of an organization for compliance and security reasons.”
   • [claimed-docs] “This guide will show you how to: 1. Configure and emit Audit Log Events 2. Export Audit Log Events”

   proof ↗⚑ flag

Frameworks

1. developerProtect routes with first-party framework SDKs and middleware (Next.js and peers) that verify sessions at the edge

   weight 3 · round drawn
   Auth0—none0/10

   The evidence pack covers Auth0's general auth features, MFA, SSO, MCP server, and AI agent tooling, but contains no mention of Next.js SDK, edge middleware, or session verification at the edge — no evidence of first-party framework SDK/middleware integration for route protection.

   ⚑ flag

   WorkOS—none0/10

   The evidence pack covers WorkOS's Node SDK, SSO, Directory Sync, RBAC, Audit Logs, Vault, and MCP server, but contains no mention of a Next.js-specific SDK, middleware, or edge-based session verification. Since framework-specific route protection is a plausible and expected capability for an auth platform, the lack of any supporting evidence makes this 'none' rather than 'na'.

   • [github] “Install the package with: npm install @workos-inc/node”
   • [claimed-docs] “AuthKit, which is a spec-compatible OAuth authorization server.”
   • [claimed-docs] “Full-fledged authentication platform, from your first user to enterprise single sign-on .”

   proof ↗⚑ flag

2. developerShip production sign-in, sign-up, and profile management with prebuilt, customizable UI components or hosted pages

   weight 2 · round drawn
   Auth0✓fullcommunity7/10

   Auth0 documents hosted Universal Login for sign-in/sign-up with password/social/passwordless options, plus no-code Forms editor and Actions for customizing identity flows, and community evidence (HN) corroborates that Universal Login works well and doesn't require JavaScript. However, evidence lacks explicit detail on prebuilt embeddable UI component libraries (e.g., Lock widget) or a dedicated self-service profile-management UI, and one comment notes the offering can be 'rough around the edges.' Missing for 10: explicit documentation of embeddable/prebuilt UI SDK components, dedicated user profile self-management UI, and independent hands-on confirmation of profile management specifically.

   • [claimed-docs] “Easily manage authentication across multiple services with just one login. Implement SSO and reduce user fatigue.”
   • [claimed-docs] “Quickly tailor the UI and business logic of your identity flows using a no-code editor.”
   • [claimed-docs] “Actions are a more secure, tenant-specific, versioned Node.js functions that let you customize your login and identity flows.”
   • [claimed-docs] “Your users should be able to log in either with an identifier (username, email, or phone number) and password or with their social accounts …”
   • [claimed-docs] “Your users should be able to log in either with an identifier (username, email, or phone number) and password or with their social accounts …”
   • [community] “Auth0's implementation of Universal Login didn't require JavaScript, which I liked; Auth0 has been 'on the ball' for a long time with their …”
   • [community] “Honestly as auth0 users we were mulling moving over to okta anyway. Auth0's offering has always been slightly rough around the edges and we …”

   proof ↗⚑ flag

   WorkOS✓fullcommunity7/10

   WorkOS/AuthKit is documented as a 'full-fledged authentication platform' with 'customizable hosted UI for authentication at any size' covering SSO, passkeys, social sign-in, passwords, and magic auth, plus APIs to 'store additional information about users and organizations' for profile management, and community testimonials confirm ease of adopting its SSO/SCIM UI wrappers in production apps. Missing for 10: explicit documentation of prebuilt embeddable UI *components* (vs. only hosted pages) for profile management specifically, and independent hands-on verification of UI customization depth beyond vendor docs.

   • [claimed-docs] “Customizable hosted UI for authentication at any size.”
   • [claimed-docs] “Full-fledged authentication platform, from your first user to enterprise single sign-on .”
   • [claimed-docs] “Single sign-on, passkeys, social sign-in, passwords, and more.”
   • [claimed-docs] “Passwordless auth with a six-digit code sent via email”
   • [claimed-docs] “Store additional information about users and organizations.”
   • [claimed-docs] “WorkOS pricing: "First 1M MAUs — Free; each additional 1M MAUs $2,500/mo. AuthKit includes email + password, social login, passkeys, MFA, ma…”
   • [community] “"Congrats to the WorkOS team - their extremely pleasant wrapper over SSO and SCIM has made my side project possible rather than a nightmare …”
   • [community] “"Congrats! We use WorkOS and they have saved us tons of time in both engineering and support cases. We frequently have customers compliment …”

   proof ↗⚑ flag

Hardening

1. security-engineerRely on built-in protection against bots, credential stuffing, and brute-force attacks on the auth flows

   weight 1 · round to Auth0
   Auth0✓fullclaimed7/10

   Auth0 docs explicitly describe proactive IP-blocking against consecutive failed login attempts to prevent brute-force/DDoS, breached-password detection using a compromised-credential database to block credential stuffing, and bot-detection-adjacent adaptive MFA that only challenges risky logins. These directly address bot/credential-stuffing/brute-force protection on auth flows. missing for 10: no explicit CAPTCHA/bot-detection documentation detail, no independent/hands-on validation of attack-blocking efficacy, and no security-engineer testimonial confirming real-world effectiveness.

   • [claimed-docs] “You want to act proactively to block suspicious IP addresses if they make consecutive failed login attempts, in order to avoid DDoS attacks.”
   • [claimed-docs] “Harness our extensive database of compromised assets to fortify your defense against large-scale account takeover th”
   • [claimed-docs] “Adaptive MFA: Only prompt users when a login seems risky, keeping security robust yet user-friendly.”
   • [claimed-docs] “If one of your user's email addresses is compromised in some site's public data breach, you want to be notified, and you want to notify the …”

   proof ↗⚑ flag

   WorkOS~partialclaimed6/10

   WorkOS documents a built-in 'Radar' feature explicitly for bot/fraud/abuse protection (workos-docs-12, workos-supp-radar) alongside MFA (workos-docs-11), but the evidence never specifically describes credential-stuffing or brute-force mitigations (e.g., rate limiting, anomaly detection specifics) or provides independent/hands-on validation of Radar's effectiveness. missing for 10: explicit credential-stuffing/brute-force protection mechanics, independent third-party validation of Radar's efficacy.

   • [claimed-docs] “Protect your app from bots, fraud, and abuse.”
   • [claimed-docs] “WorkOS pricing lists "Radar (Bot & Fraud Protection)" — first 1,000 checks free, per-50K-check pricing beyond — and "Log streaming (per SIEM…”
   • [claimed-docs] “Enroll users in multi-factor authentication for an additional layer of security.”
   • [claimed-docs] “we will walk through the steps to export, and then import your users, organizations, and enterprise SSO connections from Auth0”

   proof ↗⚑ flag

Mfa

1. security-engineerRequire multi-factor authentication with TOTP authenticator apps and backup codes, with step-up enforcement where needed

   weight 3 · round to Auth0
   Auth0✓fullclaimed7/10

   Auth0 docs explicitly list MFA factors including one-time passwords (TOTP) and recovery codes (backup codes) [auth0-docs-38, auth0-docs-23], and Adaptive MFA documentation shows risk-based, step-up-like enforcement that only prompts for MFA when a login looks risky [auth0-docs-50]. These are all vendor-first-party docs with no independent corroboration or explicit 'step-up authentication' API walkthrough in the pack. Missing for 10: independent/hands-on confirmation of step-up enforcement behavior, and explicit docs using the term 'step-up' tied to specific high-risk actions rather than just adaptive login risk scoring.

   • [claimed-docs] “Auth0 supports a variety of MFA factors, including: Push notifications, SMS notifications, Voice notifications, One-time passwords, WebAuthn…”
   • [claimed-docs] “MFA adds a layer of security during login that requires users to provide more than one credential to prove their digital identity.”
   • [claimed-docs] “Adaptive MFA: Only prompt users when a login seems risky, keeping security robust yet user-friendly.”

   proof ↗⚑ flag

   WorkOS~partialclaimed4/10

   WorkOS docs confirm MFA enrollment is supported and can be enabled via the dashboard, but the evidence never specifies TOTP authenticator app support, backup codes, or step-up (adaptive) enforcement mechanics. missing for 10: explicit documentation of TOTP authenticator app enrollment, backup code generation/recovery flow, and step-up MFA enforcement triggers or APIs, plus independent/hands-on confirmation.

   • [claimed-docs] “Enroll users in multi-factor authentication for an additional layer of security.”
   • [claimed-docs] “Enroll users in multi-factor authentication for an additional layer of security. MFA can be enabled via the Authentication page in the WorkO…”

   proof ↗⚑ flag

Passwordless

1. developerOffer passkeys/WebAuthn and passwordless options like magic links or email OTP as first-class sign-in methods

   weight 2 · round drawn
   Auth0✓fullclaimed8/10

   Auth0 documents WebAuthn (security keys and device biometrics) as an MFA factor, a dedicated Passwordless feature (email/SMS OTP, magic links), and email/SMS one-time code login as first-class sign-in options alongside password/social login. This covers passkeys/WebAuthn and passwordless magic link/OTP as first-class methods per official docs and feature pages. Missing for 10: independent hands-on developer confirmation specifically of passkey/WebAuthn setup ease, and clearer documentation of magic link (vs OTP) as a distinct flow.

   • [claimed-docs] “Auth0 supports a variety of MFA factors, including: Push notifications, SMS notifications, Voice notifications, One-time passwords, WebAuthn…”
   • [claimed-docs] “Go passwordless and give users a faster, more secure way to log in.”
   • [claimed-docs] “You believe passwords are broken and you want your users to log in with one-time codes delivered by email or SMS.”
   • [claimed-docs] “Auth0 supports a variety of MFA factors, including: * Push notifications * SMS notifications * Voice notifications * One-time passw…”
   • [claimed-docs] “MFA adds a layer of security during login that requires users to provide more than one credential to prove their digital identity.”

   proof ↗⚑ flag

   WorkOS✓fullclaimed8/10

   WorkOS/AuthKit explicitly lists passkeys, magic auth (email OTP), and passwordless as first-class sign-in methods alongside SSO, bundled into a single integration per pricing docs. Evidence confirms these are core AuthKit features, not add-ons requiring separate tooling. Missing for 10: independent hands-on developer testimony specifically about implementing passkeys/WebAuthn or magic link flows (community quotes focus on SSO/SCIM, not passwordless), and no detailed WebAuthn API/config documentation excerpt.

   • [claimed-docs] “Single sign-on, passkeys, social sign-in, passwords, and more.”
   • [claimed-docs] “Passwordless auth with a six-digit code sent via email”
   • [claimed-docs] “WorkOS pricing: "First 1M MAUs — Free; each additional 1M MAUs $2,500/mo. AuthKit includes email + password, social login, passkeys, MFA, ma…”
   • [claimed-docs] “Sign in to your app with Microsoft, Google, and more”

   proof ↗⚑ flag

Flows

1. developerImplement standard OAuth 2.0 / OIDC flows (authorization code with PKCE, refresh tokens) without hand-rolling protocol details

   weight 3 · round to Auth0
   Auth0✓fullcommunity7/10

   Auth0 documents core OAuth2/OIDC flows including client credentials (M2M), device authorization flow (explicitly noted as ratified OAuth 2.0), and general authentication/authorization via Universal Login and SDKs, sparing developers from implementing protocol details themselves. However, the evidence pack lacks explicit first-party documentation or quickstart specifically calling out 'authorization code with PKCE' or refresh token rotation/handling details, and there is no independent hands-on confirmation of PKCE support quality. missing for 10: explicit PKCE flow documentation, refresh token rotation/handling details, independent developer corroboration of authorization-code+PKCE implementation ease.

   • [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services, because the system must auth…”
   • [claimed-docs] “With input-constrained devices that connect to the internet, rather than authenticate the user directly, the device asks the user to go to a…”
   • [claimed-docs] “device apps use the Device Authorization Flow (ratified in OAuth 2.0), in which they pass along their Client ID to initiate the authorizatio…”
   • [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services”
   • [claimed-docs] “You built an API and you want to secure it with OAuth 2.0.”
   • [community] “Cognito is a nightmare and many things are broken. I lost 3 weeks in Feb. on a project trying to get it to work and just integrated Auth0 in…”
   • [community] “Cognito and Firebase are bush league by comparison. They can do the basics well enough if you have the right integration engineers. Okta and…”

   proof ↗⚑ flag

   WorkOS~partialclaimed6/10

   WorkOS's AuthKit is documented as a 'spec-compatible OAuth authorization server' (workos-docs-27) and supports device authorization flow (RFC 8628) for CLI apps (workos-docs-10, workos-supp-cli-auth), plus M2M and third-party OAuth app patterns (workos-docs-32, workos-docs-33, workos-docs-45), and SDKs handle retries/backoff (workos-gh-3, workos-gh-4). However, there's no explicit documentation of standard authorization-code-with-PKCE flow mechanics or refresh token handling/rotation for typical web/mobile apps — the evidence focuses on SSO/SAML, device flow, and M2M rather than the classic PKCE+refresh-token developer flow. missing for 10: explicit docs/SDK code samples showing authorization code + PKCE flow implementation, refresh token issuance/rotation details, and independent developer corroboration of hand-rolling-free OAuth/OIDC flow usage outside SSO context.

   • [claimed-docs] “AuthKit, which is a spec-compatible OAuth authorization server.”
   • [claimed-docs] “CLI Auth enables command-line applications to authenticate users through the web using the OAuth 2.0 Device Authorization Flow”
   • [claimed-docs] “AuthKit CLI Auth reference: "CLI Auth enables command-line applications to authenticate users through the web using the OAuth 2.0 Device Aut…”
   • [claimed-docs] “M2M applications are commonly used to provide API access credentials to customers or partners, allowing them to programmatically access your…”
   • [claimed-docs] “A third-party OAuth application will generally have a "Sign in with [your application]" button on their login page”
   • [claimed-docs] “OAuth applications are designed for applications where the actor being authenticated is a User. These include web applications, mobile, desk…”
   • [github] “The SDK automatically retries requests that fail with a transient error — a network error, a request timeout (408), a rate limit (429), or a…”
   • [github] “The SDK automatically retries requests that fail with a transient error — a network error, a request timeout (408), a rate limit (429), or a…”

   proof ↗⚑ flag

2. developerOffer sign-in with a broad set of social and OAuth identity providers through configuration, not custom code

   weight 2 · round to WorkOS
   Auth0✓fullclaimed7/10

   Auth0's docs explicitly describe adding social login (Facebook, X, etc.) alongside enterprise federation and SAML as configurable connection options rather than custom code, which is a core, well-documented Auth0 capability (auth0-docs-1/22/32/37/33). Missing for 10: an explicit enumerated list of all supported social/OAuth providers and independent hands-on verification that adding a new provider truly requires zero code.

   • [claimed-docs] “Your users should be able to log in either with an identifier (username, email, or phone number) and password or with their social accounts …”
   • [claimed-docs] “Your users should be able to log in either with an identifier (username, email, or phone number) and password or with their social accounts …”
   • [claimed-docs] “Your users should be able to log in either with an identifier (username, email, or phone number) and password or with their social accounts”
   • [claimed-docs] “You are part of a large organization that wants to federate your existing enterprise directory service to allow employees to log in to the v…”
   • [claimed-docs] “You have a web app that needs to authenticate users using Security Assertion Markup Language (SAML)”
   • [claimed-docs] “You built an awesome app and you want to add user authentication and authorization. Your users should be able to log in either with an ident…”

   proof ↗⚑ flag

   WorkOS✓fullcommunity8/10

   WorkOS/AuthKit is explicitly documented as compatible with any SAML/OIDC IdP and bundles social sign-in (Google, Microsoft, and more) alongside SSO in one configurable integration, with no custom code required — corroborated by developer testimonials praising the 'wizard' setup for SSO/social auth. missing for 10: an exhaustive enumerated list of supported social/OAuth providers, and one community report (workos-comm-9) noting a specific provider (Slack) advertised but not found in the SSO setup UI, indicating some provider coverage gaps in practice.

   • [claimed-docs] “This service is compatible with any IdP that supports either the SAML or OIDC protocols.”
   • [claimed-docs] “Sign in to your app with Microsoft, Google, and more”
   • [claimed-docs] “Single sign-on, passkeys, social sign-in, passwords, and more.”
   • [claimed-docs] “WorkOS pricing: "First 1M MAUs — Free; each additional 1M MAUs $2,500/mo. AuthKit includes email + password, social login, passkeys, MFA, ma…”
   • [claimed-docs] “Full-fledged authentication platform, from your first user to enterprise single sign-on .”
   • [community] “"Congrats to the WorkOS team - their extremely pleasant wrapper over SSO and SCIM has made my side project possible rather than a nightmare …”
   • [community] “"Congrats! We use WorkOS and they have saved us tons of time in both engineering and support cases. We frequently have customers compliment …”
   • [community] “"The signup page mentions using Slack for OAuth, but I don't see that option when I'm trying to set up an SSO integration. I wonder if that'…”

   proof ↗⚑ flag

Provider

1. developerTurn my own application into an OAuth provider that issues tokens to third-party clients ("Sign in with my app")

   weight 2 · round to WorkOS
   Auth0~partialclaimed5/10

   Auth0's core value proposition includes acting as an OAuth 2.0 authorization server that lets you 'secure your own API' and issue access tokens via flows like Client Credentials (M2M) and Authorization Code, which is the mechanism for turning an app into a token issuer for other clients (auth0-docs-2, auth0-docs-8/25, auth0-docs-54). Organizations also let you configure federated login for external business partners (auth0-docs-6/44). However, the evidence pack lacks explicit documentation of a self-service 'third-party app' registration/consent flow (dynamic client registration, developer marketplace, per-client consent screens) that fully mirrors 'Sign in with my app' for arbitrary third-party developers, missing for 10: dedicated third-party client registration/consent UI docs, dynamic client registration support, and independent hands-on confirmation of building a public OAuth provider on Auth0.

   • [claimed-docs] “You built an API and you want to secure it with OAuth 2.0.”
   • [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services, because the system must auth…”
   • [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services”
   • [claimed-docs] “Applications authenticate themselves to Auth0 via their Client Id and Client Secret. Auth0 verifies the information and responds with an Acc…”
   • [claimed-docs] “Auth0 customers can use Organizations to: * Represent their business customers and partners in Auth0 and manage their membership. * Con…”
   • [claimed-docs] “Auth0 customers can use Organizations to: Represent their business customers and partners in Auth0 and manage their membership. Configure br…”

   proof ↗⚑ flag

   WorkOS✓fullclaimed8/10

   WorkOS explicitly supports building 'Sign in with [your application]' OAuth applications via AuthKit Connect, describing it as a spec-compatible OAuth authorization server where third-party clients get a login button and users authenticate as the actor (docs-27, docs-33, docs-45), plus M2M app support for programmatic API access (docs-32). This directly delivers the 'become an OAuth provider' story with concrete docs. missing for 10: independent/hands-on developer corroboration of setting up third-party OAuth client flows, and more detail on token issuance/scopes management beyond the docs excerpts.

   • [claimed-docs] “AuthKit, which is a spec-compatible OAuth authorization server.”
   • [claimed-docs] “A third-party OAuth application will generally have a "Sign in with [your application]" button on their login page”
   • [claimed-docs] “OAuth applications are designed for applications where the actor being authenticated is a User. These include web applications, mobile, desk…”
   • [claimed-docs] “M2M applications are commonly used to provide API access credentials to customers or partners, allowing them to programmatically access your…”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to WorkOS
   Auth0~partialprobed7/10

   Auth0 exposes a Management API surfaced through both an official CLI (auth0-docs-61, probe-5) and an MCP server that explicitly lets AI agents 'create apps, deploy Actions, debug logs, and manage users — all without touching the dashboard' (auth0-gh-1, auth0-docs-41), showing strong API/automation parity with UI tasks. However, there is no explicit documentation or independent verification claiming 100% feature parity between the Management API and every UI/dashboard capability, and a direct OpenAPI spec probe returned 404s (auth0-probe-3). Missing for 10: explicit 'full API parity' documentation, independent hands-on confirmation of parity, and a public OpenAPI/swagger spec.

   • [github] “Connect Claude, Cursor, or Windsurf to your Auth0 tenant to create apps, deploy Actions, debug logs, and manage users — all without touching…”
   • [claimed-docs] “The Auth0 Model Context Protocol (MCP) Server connects AI agents to your Auth0 tenant, allowing them to perform complex, multi-step operatio…”
   • [claimed-docs] “Learn how to use Auth0 CLI to manage your tenant configuration, automate tasks, and integrate Auth0 into your deve”
   • [probe] “PROBE openapi: all candidate paths 404 (https://auth0.com/openapi.json, https://auth0.com/swagger.json, https://auth0.com/api/openapi.json, …”
   • [probe] “official CLI documented at https://github.com/auth0/auth0-cli”

   proof ↗⚑ flag

   WorkOS✓fullprobed8/10

   WorkOS ships a documented OpenAPI spec (workos-probe-3) and explicit docs stating configuration (roles, permissions, orgs) can be done 'directly in the WorkOS Dashboard or using the API' (workos-docs-40), plus an official MCP server that lets an agent 'read and change the same dashboard data you can (managing organizations, connections, users, branding, and more)' via the API (workos-docs-9, workos-docs-44). This shows the API is a first-class, near-complete mirror of the UI, not just SDK convenience wrappers (workos-gh-1..4). Missing for 10: independent hands-on confirmation that literally every dashboard action (e.g., billing/plan changes, full self-serve IT admin onboarding) has an API equivalent, and any third-party audit of full parity.

   • [claimed-docs] “Once connected, your agent can read and change the same dashboard data you can (managing organizations, connections, users, branding, and mo…”
   • [claimed-docs] “Configure roles, permissions, and organization-scoped roles directly in the WorkOS Dashboard or using the API”
   • [claimed-docs] “lets MCP-compatible AI agents act on your WorkOS workspace. Once connected, your agent can read and change the same dashboard data you can (…”
   • [probe] “PROBE openapi: HTTP 200 at https://workos.com/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://workos.com/docs/mcp”
   • [claimed-docs] “The WorkOS MCP server is a remote management Model Context Protocol server that lets MCP-compatible AI agents act on your WorkOS workspace.”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Auth0
   Auth0~partialcommunity5/10

   Auth0 documents bulk export/import of user data and log streaming export (auth0-docs-46, auth0-docs-66, auth0-docs-12), showing some data portability, but there is no explicit claim of exporting *all* tenant/user data in standardized open formats, and community commentary notes 'strong vendor lock-in' (auth0-comm-15) as a caveat. missing for 10: explicit open-format (e.g., JSON/CSV standard) full-tenant export guarantee, independent confirmation that a customer successfully exported and migrated away, and no evidence of a comprehensive one-click 'leave with all data' feature.

   • [claimed-docs] “Migrate your user data into and out of Auth0 with automatic migration and bulk imports and exports.”
   • [claimed-docs] “Import and Export User Data”
   • [claimed-docs] “Auth0’s log streaming service allows you to export tenant logs to a log analysis service.”
   • [claimed-docs] “Auth0's log streaming service allows you to export tenant logs to a log analysis service.”
   • [community] “The dominant player in this space is Auth0, who appeals to enterprises but lags behind in developer-friendliness and has strong vendor lock-…”

   proof ↗⚑ flag

   WorkOS—none0/10

   WorkOS documents only importing data (e.g., migrating FROM Auth0 INTO WorkOS) and offers audit-log export, but there is no documented capability for a user/customer to export all their identity, SSO, directory, RBAC, or vault data in open formats to leave the platform; a community thread explicitly raises this exact lock-in/export concern without any WorkOS response in the evidence pack.

   • [claimed-docs] “we will walk through the steps to export, and then import your users, organizations, and enterprise SSO connections from Auth0”
   • [claimed-docs] “The WorkOS AuthKit API allows you to migrate your existing user data from a variety of existing sources. In this guide, we will walk through…”
   • [claimed-docs] “The fastest way to export Auth0 data is with the WorkOS CLI migrations tool”
   • [community] “User raised concern about vendor lock-in: customer login data lives in WorkOS's database, questioning how to export it, cost, and contractua…”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round drawn
   Auth0—none0/10

   Auth0 is a proprietary, closed-source SaaS identity platform; there is no evidence of an open-license source release for the core product (only an MCP server and CLI are on GitHub, which are tooling, not the product itself).

   ⚑ flag

   WorkOS—none0/10

   WorkOS is a closed-source SaaS platform; its SDKs (workos-node) are open-source client libraries, but there is no evidence the core WorkOS product/service source is available under an open license. The evidence pack shows only docs, APIs, and SDK wrappers, not source availability of the platform itself.

   ⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   Auth0—none0/10

   Auth0 is offered exclusively as a managed SaaS (with a Private Cloud option deployed by Auth0 on AWS/Azure, not self-hosted by the customer); there is no evidence of an open-source or self-hostable core product that an AI-native user could run on their own infrastructure.

   • [claimed-docs] “Compare Auth0 Private Cloud-managed service deployment options on AWS and Azure to choose a dedicated, isolated environment that meets your …”
   • [claimed-docs] “Compare Auth0 Private Cloud-managed service deployment options on AWS and Azure to choose a dedicated, isolated environment”
   • [claimed-docs] “A dedicated, managed cloud service running on AWS providing isolation, higher performance, dev instances, Geo-HA add-ons and more”
   • [claimed-docs] “The power of Auth0, with the benefits of a managed private instance — deployable on Microsoft Azure or Amazon Web Services.”

   proof ↗⚑ flag

   WorkOS—none0/10

   WorkOS is presented entirely as a hosted SaaS platform with an API/SDK model; there is no evidence of a self-hostable core product, open-source server, or on-prem deployment option. Community comments even raise vendor lock-in concerns about data living in WorkOS's own database, reinforcing that it is not self-hostable.

   • [community] “User raised concern about vendor lock-in: customer login data lives in WorkOS's database, questioning how to export it, cost, and contractua…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://workos.com/llms.txt # WorkOS Documentation > WorkOS is the enterprise authentication and identity platf…”
   • [probe] “PROBE docs-md: HTTP 200 at https://workos.com/docs.md # WorkOS Documentation > WorkOS is the enterprise authentication and identity platfor…”

   proof ↗⚑ flag

Orgs

1. security-engineerGive each customer organization its own SSO connection with verified domains and just-in-time provisioning

   weight 2 · round to Auth0
   Auth0~partialclaimed6/10

   Auth0 Organizations lets security engineers represent each B2B customer/partner and configure branded, federated login flows per business (auth0-docs-6, auth0-docs-24, auth0-docs-44), and pricing page shows Enterprise Connection, Self-Service SSO, and SCIM as organization-related add-ons (auth0-docs-21). However, the evidence pack lacks explicit documentation of verified/claimed domains for automatic org routing or of just-in-time provisioning behavior tied to organizations. missing for 10: explicit docs on domain verification/home-realm-discovery per organization, explicit JIT provisioning documentation scoped to Organizations, and independent/hands-on confirmation of this multi-tenant SSO setup working end-to-end.

   • [claimed-docs] “Auth0 customers can use Organizations to: * Represent their business customers and partners in Auth0 and manage their membership. * Con…”
   • [claimed-docs] “Configure branded, federated login flows for each business.”
   • [claimed-docs] “Auth0 customers can use Organizations to: Represent their business customers and partners in Auth0 and manage their membership. Configure br…”
   • [claimed-docs] “1 Enterprise Connection New * Self-Service SSO New * SCIM New”

   proof ↗⚑ flag

   WorkOS~partialclaimed5/10

   Docs confirm WorkOS SSO is IdP-agnostic (SAML/OIDC) and organization-scoped constructs exist (org-scoped RBAC roles, per-org SSO connections referenced in the Auth0 migration guide, self-serve IT admin onboarding), supporting the idea that each customer org can have its own SSO connection. However, the evidence pack never explicitly documents 'verified domains' or 'just-in-time (JIT) provisioning' mechanics for SSO connections specifically (JIT-like behavior is only shown for Directory Sync/SCIM user lifecycle, not SSO login-time provisioning). Missing for 10: explicit verified-domain configuration docs, explicit JIT user/org provisioning on SSO login, and independent confirmation beyond vendor docs.

   • [claimed-docs] “This service is compatible with any IdP that supports either the SAML or OIDC protocols.”
   • [claimed-docs] “Enable IT admins to have a self-serve onboarding experience.”
   • [claimed-docs] “teams can also define custom roles at the organization or tenant level, assign permissions to those roles, and enforce access policies at sc…”
   • [claimed-docs] “Configure roles, permissions, and organization-scoped roles directly in the WorkOS Dashboard or using the API”
   • [claimed-docs] “walk through the steps to export, and then import your users, organizations, and enterprise SSO connections from Auth0”
   • [claimed-docs] “RBAC docs: roles integrate "with AuthKit user management by assigning roles via API and enforcing access through session JWTs — support for …”

   proof ↗⚑ flag

2. developerModel multi-tenant B2B apps with organizations, memberships, and invitation flows out of the box

   weight 3 · round drawn
   Auth0~partialclaimed6/10

   Auth0 docs explicitly describe an Organizations feature for representing B2B customers/partners, managing their membership, and configuring branded federated login flows per business (auth0-docs-6/24/44/65), plus RBAC for role-based permissions (auth0-docs-7/39/45). However, the evidence pack contains no mention of invitation flows or invitation APIs for organization members, which is a core part of the story. Missing for 10: explicit documentation of organization invitation/onboarding flows, and independent/hands-on corroboration of multi-tenant org setup working end-to-end.

   • [claimed-docs] “Auth0 customers can use Organizations to: * Represent their business customers and partners in Auth0 and manage their membership. * Con…”
   • [claimed-docs] “Configure branded, federated login flows for each business.”
   • [claimed-docs] “Auth0 customers can use Organizations to: Represent their business customers and partners in Auth0 and manage their membership. Configure br…”
   • [claimed-docs] “Auth0 Organizations”
   • [claimed-docs] “Role-based access control (RBAC) is an authorization strategy to assign permissions to users based on defined roles in an organization.”
   • [claimed-docs] “You then assign one or more roles to each user and one or more permissions to each role.”

   proof ↗⚑ flag

   WorkOS~partialclaimed6/10

   WorkOS docs explicitly reference organizations, memberships, and org/tenant-scoped roles (e.g., migration package includes 'users, organizations, memberships, roles' and RBAC roles 'at the organization or tenant level'), and self-serve IT admin onboarding is mentioned, showing multi-tenant B2B modeling out of the box. However, there is no direct evidence of a dedicated invitation flow API or UI for inviting members to organizations. missing for 10: explicit invitation flow documentation/API, hands-on/independent confirmation of the org+membership+invite workflow end-to-end.

   • [claimed-docs] “This produces a migration package with users, organizations, memberships, roles, SSO handoff files, and warnings.”
   • [claimed-docs] “teams can also define custom roles at the organization or tenant level, assign permissions to those roles, and enforce access policies at sc…”
   • [claimed-docs] “teams can also define custom roles at the organization or tenant level, assign permissions to those roles, and enforce access policies at sc…”
   • [claimed-docs] “Enable IT admins to have a self-serve onboarding experience.”
   • [claimed-docs] “RBAC docs: roles integrate "with AuthKit user management by assigning roles via API and enforcing access through session JWTs — support for …”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Auth0
   Auth0~partialclaimed4/10

   Auth0 Private Cloud deployment docs mention meeting 'data-residency' requirements via dedicated deployment on AWS or Azure, implying some regional choice, but this is only for the enterprise-tier Private Cloud offering, not the standard multi-tenant product. missing for 10: explicit list of supported regions/data centers, region-selection mechanism in the standard product/dashboard, and any documentation on residency guarantees for the mainstream SaaS tier.

   • [claimed-docs] “Compare Auth0 Private Cloud-managed service deployment options on AWS and Azure to choose a dedicated, isolated environment that meets your …”
   • [claimed-docs] “Compare Auth0 Private Cloud-managed service deployment options on AWS and Azure to choose a dedicated, isolated environment”
   • [claimed-docs] “A dedicated, managed cloud service running on AWS providing isolation, higher performance, dev instances, Geo-HA add-ons and more”
   • [claimed-docs] “The power of Auth0, with the benefits of a managed private instance — deployable on Microsoft Azure or Amazon Web Services.”

   proof ↗⚑ flag

   WorkOS—none0/10

   No evidence in the pack mentions data residency, regional storage options, or geographic data location controls for WorkOS-managed data; the closest topics (Vault/BYOK, migration, audit logs) address encryption/key management, not residency choice. Missing for 10: any documentation of region selection, data residency guarantees, or geo-specific hosting options.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Auth0—none0/10

   The evidence pack covers user migration/export/import, log streaming, and SSO/MFA, but nothing addresses configurable data retention periods or user data deletion controls (e.g., right-to-be-forgotten, account deletion APIs, retention policy settings). Absence of evidence for this applicable privacy-posture axis means it is unverified.

   • [claimed-docs] “Migrate your user data into and out of Auth0 with automatic migration and bulk imports and exports.”
   • [claimed-docs] “Transferring user databases can be a developer's nightmare. We've simplified the process so you can either do a bulk import or gradually mig…”
   • [claimed-docs] “Import and Export User Data”
   • [claimed-docs] “Auth0’s log streaming service allows you to export tenant logs to a log analysis service.”

   proof ↗⚑ flag

   WorkOS—none0/10

   WorkOS stores customer/user identity data (SSO, directory sync, Vault-encrypted secrets) so data retention/deletion is a fair axis, but the evidence pack contains no documentation of deletion APIs, retention policies, or data export/erasure controls — only a community comment raising unresolved concern about how to export data when leaving WorkOS (workos-comm-8), which is not evidence of a working capability.

   • [community] “User raised concern about vendor lock-in: customer login data lives in WorkOS's database, questioning how to export it, cost, and contractua…”
   • [claimed-docs] “WorkOS Vault is a developer-friendly EKM to encrypt and optionally store data including tokens, passwords, certificates, files, and any othe…”

   proof ↗⚑ flag

Rbac

1. security-engineerExpress fine-grained, resource-level authorization (relationship- or policy-based) beyond simple roles

   weight 1 · round to Auth0
   Auth0✓fullclaimed7/10

   Auth0 explicitly offers Auth0 FGA, described as 'a unified, relationship-based platform that helps secure multi-tenant B2B APIs and apps, and decouples complex authorization logic from your code,' going beyond basic RBAC, plus document-level access control for RAG pipelines and 'advanced authorization mechanics for more flexible access control.' This directly matches the relationship/policy-based fine-grained authorization ask, distinct from the separate RBAC docs. Missing for 10: deeper technical documentation on FGA's authorization model/policy language, and independent/hands-on validation of FGA in production beyond marketing copy.

   • [claimed-docs] “Auth0 FGA provides a unified, relationship-based platform that helps secure multi-tenant B2B APIs and apps, and decouples complex authorizat…”
   • [claimed-docs] “Enforce fine-grained, document-level access control within your Retrieval Augmented Generation (RAG) pipelines using Auth0 FGA.”
   • [claimed-docs] “Enforce fine-grained, document-level access control within your Retrieval Augmented Generation (RAG) pipelines using Auth0 FGA”
   • [claimed-docs] “Seamlessly define access roles for your apps and APIs, and tap into advanced authorization mechanics for more flexible access control.”

   proof ↗⚑ flag

   WorkOS~partialclaimed5/10

   WorkOS RBAC docs show custom roles, permission assignment, and organization/tenant-scoped roles enforced via JWTs, which goes beyond simple flat roles, but there is no evidence of relationship-based (ReBAC) authorization or a policy engine (e.g., ABAC/OPA-style) for arbitrary resource-level grants. Missing for 10: relationship-graph based authorization, fine-grained per-resource ACLs, and any policy-language/attribute-based access control beyond role+organization scoping.

   • [claimed-docs] “teams can also define custom roles at the organization or tenant level, assign permissions to those roles, and enforce access policies at sc…”
   • [claimed-docs] “teams can also define custom roles at the organization or tenant level, assign permissions to those roles, and enforce access policies at sc…”
   • [claimed-docs] “Advanced RBAC with custom roles and role assignment.”
   • [claimed-docs] “Configure roles, permissions, and organization-scoped roles directly in the WorkOS Dashboard or using the API”
   • [claimed-docs] “RBAC docs: roles integrate "with AuthKit user management by assigning roles via API and enforcing access through session JWTs — support for …”

   proof ↗⚑ flag

2. developerDefine roles and permissions and have them enforced and surfaced in session tokens for authorization checks

   weight 3 · round drawn
   Auth0✓fullclaimed8/10

   Auth0 docs clearly describe RBAC where roles are assigned to users and permissions to roles (auth0-docs-7, auth0-docs-39, auth0-docs-45), and the broader access-management platform page confirms role-based access control for apps and APIs (auth0-docs-56). Auth0's RBAC is standardly surfaced via permissions claims in access tokens for authorization checks, consistent with the OAuth2-based API security flows documented (auth0-docs-2, auth0-docs-8). Missing for 10: explicit first-party documentation snippet showing the permissions/roles claim appearing inside issued session/access tokens, and independent hands-on confirmation of token enforcement behavior.

   • [claimed-docs] “Role-based access control (RBAC) is an authorization strategy to assign permissions to users based on defined roles in an organization.”
   • [claimed-docs] “You then assign one or more roles to each user and one or more permissions to each role.”
   • [claimed-docs] “When using RBAC for Role Management, you analyze the needs of your users and group them into roles based on common responsibilities. You the…”
   • [claimed-docs] “Seamlessly define access roles for your apps and APIs, and tap into advanced authorization mechanics for more flexible access control.”
   • [claimed-docs] “You built an API and you want to secure it with OAuth 2.0.”

   proof ↗⚑ flag

   WorkOS✓fullclaimed8/10

   WorkOS RBAC docs explicitly describe defining custom roles and permissions at the org/tenant level, assigning them via API or dashboard, and enforcing access through session JWTs, including organization-scoped roles and IdP role assignment via SSO/Directory Sync — directly matching the story's requirements. missing for 10: independent/hands-on developer corroboration of JWT-based permission checks in production and concrete code samples showing authorization checks against token claims.

   • [claimed-docs] “teams can also define custom roles at the organization or tenant level, assign permissions to those roles, and enforce access policies at sc…”
   • [claimed-docs] “teams can also define custom roles at the organization or tenant level, assign permissions to those roles, and enforce access policies at sc…”
   • [claimed-docs] “Configure roles, permissions, and organization-scoped roles directly in the WorkOS Dashboard or using the API”
   • [claimed-docs] “RBAC docs: roles integrate "with AuthKit user management by assigning roles via API and enforcing access through session JWTs — support for …”
   • [claimed-docs] “Advanced RBAC with custom roles and role assignment.”

   proof ↗⚑ flag

Sessions

1. security-engineerLet users and admins see active sessions and devices and revoke them individually or all at once

   weight 1 · round drawn
   Auth0—none0/10

   No evidence in the pack describes session/device visibility or revocation features (active session lists, per-device revocation, or 'log out all devices' controls) for end users or admins; the pack covers login flows, MFA, SSO, RBAC, migration, and AI agent integrations but never session management.

   ⚑ flag

   WorkOS—none0/10

   The evidence pack covers SSO, Directory Sync, RBAC, MFA, Audit Logs, Vault, and MCP integration, but contains no mention of a session/device management feature that lets users or admins view active sessions/devices and revoke them individually or all at once. This is a fair axis for an authentication platform, but no documentation, dashboard feature, or API reference in the pack addresses it.

   ⚑ flag

2. developerManage session lifecycle — expiry, refresh, and immediate server-side revocation of a compromised session

   weight 3 · round drawn
   Auth0—none0/10

   The evidence pack covers login flows, SSO, MFA, RBAC, Organizations, and AI-agent security features, but contains no documentation of session lifetime configuration, refresh-token rotation/expiry controls, or an API/dashboard action for immediately revoking a live session — a core, expected capability for an identity platform. Since this is a fair and applicable axis for Auth0 but no supporting evidence is present, it cannot be credited as full/partial.

   ⚑ flag

   WorkOS—none0/10

   WorkOS/AuthKit is an authentication platform where session lifecycle management (expiry, refresh, revocation) would be a natural and expected capability, so the axis applies — but the evidence pack contains no documentation of session expiry policies, token refresh mechanics, or server-side session/token revocation for compromised sessions.

   ⚑ flag

Migration

1. developerBulk-import existing users — including password hashes — and export them again, so I am never locked in

   weight 2 · round to Auth0
   Auth0~partialcommunity6/10

   Auth0 docs clearly describe bulk import and export of user data ('Migrate your user data into and out of Auth0 with automatic migration and bulk imports and exports' — auth0-docs-46/57/66) and gradual migration via import mode (auth0-docs-10/11). However, the evidence never specifically confirms password-hash import support or details the export format/API, and one community comment even flags Auth0 as having 'strong vendor lock-in' (auth0-comm-15), which cuts against the 'never locked in' framing. Missing for 10: explicit documentation of password-hash import fields, concrete export API/schema details, and independent confirmation that migration avoids lock-in.

   • [claimed-docs] “Gradually migrate users from your external user store to Auth0 as they log in by enabling import mode on your custom database connection.”
   • [claimed-docs] “Migrate users from an existing database or service to Auth0 using bulk imports for database connections.”
   • [claimed-docs] “Migrate your user data into and out of Auth0 with automatic migration and bulk imports and exports.”
   • [claimed-docs] “Transferring user databases can be a developer's nightmare. We've simplified the process so you can either do a bulk import or gradually mig…”
   • [claimed-docs] “Import and Export User Data”
   • [community] “The dominant player in this space is Auth0, who appeals to enterprises but lags behind in developer-friendliness and has strong vendor lock-…”

   proof ↗⚑ flag

   WorkOS~partialcommunity5/10

   WorkOS documents a concrete bulk-import path from Auth0 (users, organizations, memberships, roles, SSO handoff files) via a CLI migrations tool, which implies handling credentials like SSO/password data, but no docs explicitly confirm password-hash import fidelity or any reverse 'export your users out of WorkOS' capability. A community thread explicitly raises the lock-in/export question without a documented resolution, leaving the 'export again' half of the story unaddressed. missing for 10: explicit documentation of password-hash import support, and a documented user-data export/portability path out of WorkOS to prevent lock-in.

   • [claimed-docs] “This produces a migration package with users, organizations, memberships, roles, SSO handoff files, and warnings.”
   • [claimed-docs] “The WorkOS AuthKit API allows you to migrate your existing user data from a variety of existing sources.”
   • [claimed-docs] “we will walk through the steps to export, and then import your users, organizations, and enterprise SSO connections from Auth0”
   • [claimed-docs] “The WorkOS AuthKit API allows you to migrate your existing user data from a variety of existing sources. In this guide, we will walk through…”
   • [claimed-docs] “walk through the steps to export, and then import your users, organizations, and enterprise SSO connections from Auth0”
   • [claimed-docs] “The fastest way to export Auth0 data is with the WorkOS CLI migrations tool”
   • [community] “User raised concern about vendor lock-in: customer login data lives in WorkOS's database, questioning how to export it, cost, and contractua…”

   proof ↗⚑ flag

2. founderFollow vendor-maintained migration guides or tooling for moving off a competing auth provider without forcing password resets

   weight 1 · round to Auth0
   Auth0✓fullclaimed7/10

   Auth0 documents vendor-maintained tooling for exactly this need: gradual migration via import mode that migrates users transparently as they log in (no forced password reset) plus bulk import/export for one-time migrations from an external user store or database. Missing for 10: named step-by-step guides for migrating from specific competing providers (e.g., Okta, Cognito, Firebase) rather than generic import-mode docs, and independent/hands-on evidence confirming migrations complete without any password resets in practice.

   • [claimed-docs] “Gradually migrate users from your external user store to Auth0 as they log in by enabling import mode on your custom database connection.”
   • [claimed-docs] “Migrate users from an existing database or service to Auth0 using bulk imports for database connections.”
   • [claimed-docs] “Migrate your user data into and out of Auth0 with automatic migration and bulk imports and exports.”
   • [claimed-docs] “Transferring user databases can be a developer's nightmare. We've simplified the process so you can either do a bulk import or gradually mig…”
   • [claimed-docs] “Import and Export User Data”

   proof ↗⚑ flag

   WorkOS~partialclaimed6/10

   WorkOS has a dedicated Auth0 migration guide/CLI tool that exports and imports users, organizations, roles, and enterprise SSO connections, producing a migration package with warnings—clearly vendor-maintained tooling for moving off a competing provider. However, the evidence never explicitly states passwords/password hashes are migrated or that end users won't be forced to reset passwords, and guides are limited to Auth0 (no mention of other competitors like Okta, Cognito, Firebase). missing for 10: explicit confirmation that password hashes are migrated without forcing resets, migration guides/tooling for providers beyond Auth0, and independent/hands-on confirmation the migration tool works as described in practice.

   • [claimed-docs] “This produces a migration package with users, organizations, memberships, roles, SSO handoff files, and warnings.”
   • [claimed-docs] “The WorkOS AuthKit API allows you to migrate your existing user data from a variety of existing sources.”
   • [claimed-docs] “we will walk through the steps to export, and then import your users, organizations, and enterprise SSO connections from Auth0”
   • [claimed-docs] “The WorkOS AuthKit API allows you to migrate your existing user data from a variety of existing sources. In this guide, we will walk through…”
   • [claimed-docs] “walk through the steps to export, and then import your users, organizations, and enterprise SSO connections from Auth0”
   • [claimed-docs] “The fastest way to export Auth0 data is with the WorkOS CLI migrations tool”
   • [claimed-docs] “we will walk through the steps to export, and then import your users, organizations, and enterprise SSO connections from Auth0.”

   proof ↗⚑ flag