Clerk 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 Clerk
   Clerk~partialclaimed3/10

   Clerk documents a device-authorization-grant-style flow (clerk-docs-52) that lets a user approve access from a separate browser-capable device — conceptually adjacent to CIBA-style out-of-band approval — and a 'reverification window' for sensitive actions (clerk-docs-53), but neither is presented as a mechanism for an autonomous agent to pause a specific transaction and await asynchronous human approval. Missing for 10: explicit CIBA/agent-transaction-approval workflow, agent-side APIs to request and await approval mid-task, and any hands-on or documented example of this exact use case.

   • [claimed-docs] “The grant provides a standards-based flow for applications that cannot open a browser or easily accept text input. CLIs, TVs, game consoles,…”
   • [claimed-docs] “Customize the reverification window: Control how recently users must have authenticated before performing sensitive actions.”

   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 Clerk
   Clerk~partialclaimed6/10

   Clerk's 'eve' agent-auth docs explicitly describe brokering OAuth to obtain a provider token on the caller's behalf, gated by the caller's Clerk permissions/scopes, and Clerk separately supports OAuth scoped access for third-party API delegation — directly matching the token-vault/exchange concept for delegated tool calls. Missing for 10: no detail on token lifetime/refresh mechanics specific to third-party tokens (as opposed to Clerk's own short-lived session tokens), no independent/hands-on corroboration of the eve broker in production use.

   • [claimed-docs] “Gate individual eve tool calls against the caller's Clerk permissions and scopes — and broker OAuth for tools that need a provider token on …”
   • [claimed-docs] “Gate individual eve tool calls against the caller's Clerk permissions and scopes — and broker OAuth for tools that need a provider token”
   • [claimed-docs] “Clerk's OAuth implementation supports OAuth scoped access, which lets third-party applications request limited access to specific parts of a…”
   • [claimed-docs] “Clerk's OAuth implementation supports OAuth scoped access, which lets third-party applications request limited access to specific parts of a…”
   • [claimed-docs] “Clerk's OAuth implementation supports **OAuth scoped access**, which lets third-party applications request limited access to specific parts …”
   • [claimed-docs] “Custom OAuth scopes: Give MCP clients precise, discove”
   • [claimed-docs] “Clerk generates a short-lived session token that you can use to authenticate requests to your backend. This token is a JSON Web Token (JWT) …”

   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
   Clerk~partialclaimed6/10

   Clerk's changelog explicitly describes an OAuth device authorization grant ('CLIs, TVs, game consoles... can ask a user to approve access from a browser-capable device without entering their credentials') matching the story's core need, and a related changelog entry mentions custom OAuth scopes for MCP clients. However, this is only surfaced as a brief changelog note rather than a dedicated implementation guide, and Clerk's more prominently documented machine-auth pattern is long-lived API keys/M2M tokens, which is the opposite pattern the story wants to avoid. Missing for 10: a full first-party guide/tutorial for implementing the device flow for CLIs/agents, SDK examples, and independent/hands-on confirmation it works as described.

   • [claimed-docs] “The grant provides a standards-based flow for applications that cannot open a browser or easily accept text input. CLIs, TVs, game consoles,…”
   • [claimed-docs] “Custom OAuth scopes: Give MCP clients precise, discove”
   • [claimed-docs] “API keys authenticate programmatic callers; M2M tokens authenticate calls between your agents.”
   • [claimed-docs] “**[API keys](https://clerk.com/docs/guides/development/machine-auth/api-keys.md)** authenticate programmatic callers; **[M2M tokens](https:/…”

   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 WorkOS
   Clerk✓fullclaimed7/10

   Clerk documents dedicated Machine-to-Machine (M2M) tokens distinct from user session tokens, explicitly described as authenticating 'calls between your agents' (vs. API keys for programmatic callers), with tool-call authorization gated by permissions/scopes — directly matching the client-credentials/agent-auth use case. This is a metered, real platform feature (present in pricing tiers), not just a docs mention. missing for 10: explicit naming of the OAuth2 'client_credentials' grant type, independent/hands-on verification of the M2M flow, and details on token lifetime/rotation for service accounts.

   • [claimed-docs] “API keys authenticate programmatic callers; M2M tokens authenticate calls between your agents.”
   • [claimed-docs] “**[API keys](https://clerk.com/docs/guides/development/machine-auth/api-keys.md)** authenticate programmatic callers; **[M2M tokens](https:/…”
   • [claimed-docs] “Gate individual eve tool calls against the caller's Clerk permissions and scopes — and broker OAuth for tools that need a provider token on …”
   • [claimed-docs] “Gate individual eve tool calls against the caller's Clerk permissions and scopes — and broker OAuth for tools that need a provider token”
   • [claimed-docs] “Clerk pricing: the Free plan carries a "Machine Authentication — API Keys & M2M Tokens limit per month"; machine authentication (API keys an…”

   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 Clerk
   Clerk~partialclaimed7/10

   Clerk's 'eve' agent-auth product provides M2M tokens as a distinct credential type from user API keys/sessions, explicitly for 'calls between your agents,' and lets you gate individual tool calls against the caller's scoped Clerk permissions, plus custom OAuth scopes for MCP clients — directly supporting least-privilege, non-human machine identities for agents. Missing for 10: explicit documentation of instant/granular revocation specifically for M2M tokens (only session/device revocation is documented), and independent/hands-on corroboration beyond first-party docs.

   • [claimed-docs] “API keys authenticate programmatic callers; M2M tokens authenticate calls between your agents.”
   • [claimed-docs] “**[API keys](https://clerk.com/docs/guides/development/machine-auth/api-keys.md)** authenticate programmatic callers; **[M2M tokens](https:/…”
   • [claimed-docs] “Gate individual eve tool calls against the caller's Clerk permissions and scopes — and broker OAuth for tools that need a provider token on …”
   • [claimed-docs] “Gate individual eve tool calls against the caller's Clerk permissions and scopes — and broker OAuth for tools that need a provider token”
   • [claimed-docs] “Custom OAuth scopes: Give MCP clients precise, discove”
   • [claimed-docs] “Clerk pricing: the Free plan carries a "Machine Authentication — API Keys & M2M Tokens limit per month"; machine authentication (API keys an…”
   • [claimed-docs] “Clerk site, Session Management: "Clerk manages the full session lifecycle, including critical security functionality like active device moni…”

   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
   Clerk~partialclaimed6/10

   Clerk shows real building blocks for this story — OAuth scoped access, M2M tokens for agent-to-agent calls, an 'eve' feature to gate tool calls against caller permissions/scopes and broker OAuth on the caller's behalf, and a changelog entry specifically about 'Custom OAuth scopes: give MCP clients precise, discoverable' scopes. However, evidence stops short of a dedicated guide showing a spec-compliant OAuth authorization flow specifically fronting a self-hosted MCP server (Clerk's own MCP server is for feeding docs to coding agents, a different use case). Missing for 10: a dedicated first-party tutorial/reference for protecting a custom MCP server with Clerk OAuth end-to-end, and independent/hands-on confirmation of spec compliance with the MCP authorization spec.

   • [claimed-docs] “Clerk's OAuth implementation supports OAuth scoped access, which lets third-party applications request limited access to specific parts of a…”
   • [claimed-docs] “Gate individual eve tool calls against the caller's Clerk permissions and scopes — and broker OAuth for tools that need a provider token on …”
   • [claimed-docs] “Gate individual eve tool calls against the caller's Clerk permissions and scopes — and broker OAuth for tools that need a provider token”
   • [claimed-docs] “**[API keys](https://clerk.com/docs/guides/development/machine-auth/api-keys.md)** authenticate programmatic callers; **[M2M tokens](https:/…”
   • [claimed-docs] “Custom OAuth scopes: Give MCP clients precise, discove”
   • [claimed-docs] “The grant provides a standards-based flow for applications that cannot open a browser or easily accept text input. CLIs, TVs, game consoles,…”

   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
   Clerk✓fullprobed9/10

   Clerk hosts a working llms.txt (HTTP 200, confirmed by probe) and docs.md machine-readable docs, plus a changelog llms-full.txt/llms.txt, giving agents direct access to agent-oriented documentation; it also ships an official MCP server so agents can pull SDK snippets directly. missing for 10: independent third-party confirmation that agents successfully consume llms.txt in practice beyond the probe check.

   • [probe] “PROBE llms.txt: HTTP 200 at https://clerk.com/llms.txt # Clerk > Install the Clerk CLI to add auth to your app. No global install, API keys…”
   • [probe] “PROBE docs-md: HTTP 200 at https://clerk.com/docs.md # Welcome to Clerk Docs Clerk provides full-stack authentication and user management w…”
   • [claimed-docs] “The grant provides a standards-based flow for applications that cannot open a browser or easily accept text input. CLIs, TVs, game consoles,…”
   • [claimed-docs] “Customize the reverification window: Control how recently users must have authenticated before performing sensitive actions.”
   • [claimed-docs] “Audit Dashboard activity with Admin Logs: An audit trail of admin actions across your workspace”
   • [claimed-docs] “Custom OAuth scopes: Give MCP clients precise, discove”
   • [claimed-docs] “Clerk provides a remote Model Context Protocol (MCP) server that allows AI agents like Claude, Cursor, and Github Copilot to access Clerk SD…”
   • [probe] “official MCP server documented at https://clerk.com/docs/guides/ai/mcp/clerk-mcp-server”

   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 drawn
   Clerk~partialprobed5/10

   Clerk exposes a Backend API, OpenAPI spec, API keys and M2M tokens for machine-to-machine/programmatic auth, and a scriptable CLI plus an open-source migration tool that respects rate limits — all usable in automated/non-interactive contexts. It also supports the OAuth device-code grant for browser-less clients (CLIs, TVs). However there is no explicit documentation of CI pipelines, headless test-mode, or automated end-to-end testing workflows for the auth flows themselves. missing for 10: explicit CI/test-automation guides, headless browser/session testing support, first-party CI examples.

   • [claimed-docs] “API keys authenticate programmatic callers; M2M tokens authenticate calls between your agents.”
   • [claimed-docs] “**[API keys](https://clerk.com/docs/guides/development/machine-auth/api-keys.md)** authenticate programmatic callers; **[M2M tokens](https:/…”
   • [claimed-docs] “Clerk provides an open-source tool that takes a JSON or CSV file as input, containing a list of users, and creates a user in Clerk using the…”
   • [claimed-docs] “Migration guide, "Migration tooling": "To aid in basic migrations, Clerk provides an open-source tool that takes a JSON or CSV file as input…”
   • [claimed-docs] “The grant provides a standards-based flow for applications that cannot open a browser or easily accept text input. CLIs, TVs, game consoles,…”
   • [probe] “PROBE openapi: HTTP 200 at https://clerk.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Start in the repo you already have. Clerk detects the framework, links an app, and adds the auth files your project needs.”

   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 Clerk
   Clerk✓fullprobed9/10

   Clerk documents an official remote MCP server enabling AI agents (Claude, Cursor, GitHub Copilot) to access Clerk SDK snippets and implementation patterns, and its CLI offers a one-command connector to wire this MCP server into AI clients. This is exactly the story's requirement and is corroborated by both docs and a live probe confirming the page exists. Missing for 10: independent/hands-on community confirmation that the MCP connection works reliably in practice.

   • [claimed-docs] “Clerk provides a remote Model Context Protocol (MCP) server that allows AI agents like Claude, Cursor, and Github Copilot to access Clerk SD…”
   • [claimed-docs] “Clerk provides a remote Model Context Protocol (MCP) server that allows AI agents like Claude, Cursor, and Github Copilot to access Clerk SD…”
   • [claimed-docs] “Clerk provides a remote [Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction) server that allows AI agents like Claud…”
   • [claimed-docs] “Connect the Clerk MCP server to your AI clients in one command, so your agent works with up-to-date Clerk SDK snippets.”
   • [probe] “official MCP server documented at https://clerk.com/docs/guides/ai/mcp/clerk-mcp-server”
   • [probe] “official CLI documented at https://clerk.com/cli”

   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 Clerk
   Clerk✓fullprobed8/10

   Clerk ships an official CLI (clerk.com/cli, llms.txt) that scaffolds auth into a repo, manages webhooks locally, ships to production, and connects the Clerk MCP server to AI clients in one command — directly serving AI-native/agentic workflows. missing for 10: independent/hands-on community verification of the CLI's reliability and no deeper detail on full command coverage beyond the marketing/docs pages.

   • [claimed-docs] “Start in the repo you already have. Clerk detects the framework, links an app, and adds the auth files your project needs.”
   • [claimed-docs] “Relay webhook deliveries to your local handler and verify their signatures offline, with no public tunnel service.”
   • [claimed-docs] “Create a short-lived sign-in URL to reproduce and debug a specific user session, stamped with your account.”
   • [claimed-docs] “Ship your auth to production from the CLI. Clerk helps you set up your domain, OAuth providers, and DNS records with confidence.”
   • [claimed-docs] “Connect the Clerk MCP server to your AI clients in one command, so your agent works with up-to-date Clerk SDK snippets.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://clerk.com/llms.txt # Clerk > Install the Clerk CLI to add auth to your app. No global install, API keys…”
   • [probe] “official CLI documented at https://clerk.com/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
   Clerk✓fullprobed8/10

   Clerk publishes a documented, discoverable Backend API with an OpenAPI spec (clerk-probe-3), a CLI and llms.txt entry points for programmatic/AI-native access (clerk-probe-1, clerk-probe-2, clerk-docs-37/40), session tokens and API keys/M2M tokens for programmatic auth (clerk-docs-6, clerk-docs-43), and a dedicated remote MCP server plus docs guiding AI agents to use it (clerk-docs-2, clerk-docs-42, clerk-probe-4). This is strong, well-documented, first-party evidence of API-driven and agent-friendly access. missing for 10: independent/hands-on developer confirmation that the public API/OpenAPI spec is fully complete and stable in practice (community evidence is silent on the API itself, only on general product reliability), and no third-party audit of API completeness.

   • [probe] “PROBE openapi: HTTP 200 at https://clerk.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://clerk.com/llms.txt # Clerk > Install the Clerk CLI to add auth to your app. No global install, API keys…”
   • [probe] “PROBE docs-md: HTTP 200 at https://clerk.com/docs.md # Welcome to Clerk Docs Clerk provides full-stack authentication and user management w…”
   • [claimed-docs] “Start in the repo you already have. Clerk detects the framework, links an app, and adds the auth files your project needs.”
   • [claimed-docs] “Ship your auth to production from the CLI. Clerk helps you set up your domain, OAuth providers, and DNS records with confidence.”
   • [claimed-docs] “Clerk generates a short-lived session token that you can use to authenticate requests to your backend. This token is a JSON Web Token (JWT) …”
   • [claimed-docs] “**[API keys](https://clerk.com/docs/guides/development/machine-auth/api-keys.md)** authenticate programmatic callers; **[M2M tokens](https:/…”
   • [claimed-docs] “Clerk provides a remote Model Context Protocol (MCP) server that allows AI agents like Claude, Cursor, and Github Copilot to access Clerk SD…”
   • [claimed-docs] “Clerk provides a remote [Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction) server that allows AI agents like Claud…”
   • [probe] “official MCP server documented at https://clerk.com/docs/guides/ai/mcp/clerk-mcp-server”

   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 Clerk
   Clerk✓fullclaimed8/10

   Clerk explicitly supports machine-to-machine tokens and API keys for agent-to-agent auth, custom OAuth scopes for MCP clients, gating individual tool calls against caller's permissions/scopes, and OAuth scoped access limiting third-party data access — directly enabling scoped, least-privilege credentials for agents. missing for 10: independent/hands-on verification of the scoping granularity in production and no community corroboration of this specific agentic credentialing workflow.

   • [claimed-docs] “API keys authenticate programmatic callers; M2M tokens authenticate calls between your agents.”
   • [claimed-docs] “**[API keys](https://clerk.com/docs/guides/development/machine-auth/api-keys.md)** authenticate programmatic callers; **[M2M tokens](https:/…”
   • [claimed-docs] “Gate individual eve tool calls against the caller's Clerk permissions and scopes — and broker OAuth for tools that need a provider token on …”
   • [claimed-docs] “Gate individual eve tool calls against the caller's Clerk permissions and scopes — and broker OAuth for tools that need a provider token”
   • [claimed-docs] “Custom OAuth scopes: Give MCP clients precise, discove”
   • [claimed-docs] “Clerk's OAuth implementation supports OAuth scoped access, which lets third-party applications request limited access to specific parts of a…”
   • [claimed-docs] “Clerk's OAuth implementation supports **OAuth scoped access**, which lets third-party applications request limited access to specific parts …”
   • [claimed-docs] “Clerk pricing: the Free plan carries a "Machine Authentication — API Keys & M2M Tokens limit per month"; machine authentication (API keys an…”

   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 Clerk
   Clerk✓fullprobed8/10

   Clerk ships official SDKs (e.g., the clerk/javascript GitHub repo, framework-specific guides like Next.js) plus a CLI and a first-party remote MCP server that lets AI agents like Claude, Cursor, and GitHub Copilot pull up-to-date SDK snippets and implementation patterns, directly serving AI-native builders (clerk-gh-1, clerk-docs-2/26/42, clerk-docs-41, clerk-probe-4/5). Community feedback (clerk-comm-1) raises quality concerns about the JS SDK being bloated/obfuscated, tempering confidence without disputing that official SDKs exist and are documented. Missing for 10: independent hands-on validation of SDK developer experience and broader multi-language SDK coverage beyond JS/Next.js in the evidence pack.

   • [github] “Clerk helps developers build user management. We provide streamlined user experiences for your users to sign up, sign in, and manage their p…”
   • [claimed-docs] “Clerk provides a remote Model Context Protocol (MCP) server that allows AI agents like Claude, Cursor, and Github Copilot to access Clerk SD…”
   • [claimed-docs] “Clerk provides a remote Model Context Protocol (MCP) server that allows AI agents like Claude, Cursor, and Github Copilot to access Clerk SD…”
   • [claimed-docs] “Connect the Clerk MCP server to your AI clients in one command, so your agent works with up-to-date Clerk SDK snippets.”
   • [claimed-docs] “Clerk provides a remote [Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction) server that allows AI agents like Claud…”
   • [probe] “official MCP server documented at https://clerk.com/docs/guides/ai/mcp/clerk-mcp-server”
   • [probe] “official CLI documented at https://clerk.com/cli”
   • [community] “Clerk is just a mess. They cram EVERYTHING into their libraries: Web3 crap, Stripe, etc. Clerk's JS blob is now triggering browser inspector…”

   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 to Clerk
   Clerk✓fullclaimed8/10

   Clerk documents native webhook support for event notifications (user created/updated, billing events) plus CLI tooling to relay and verify webhook deliveries locally with signature verification, giving a clear event-subscription mechanism for automation/agentic consumers. Missing for 10: independent/hands-on corroboration of webhook reliability and a full enumerated event catalog.

   • [claimed-docs] “Clerk webhooks allow you to receive event notifications from Clerk, such as when a user is created or updated.”
   • [claimed-docs] “Set up and manage Billing for B2C and B2B applications, including free trials, Subscription Plans, payments, and webhook events.”
   • [claimed-docs] “Relay webhook deliveries to your local handler and verify their signatures offline, with no public tunnel service.”

   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 userSet up automations that run autonomously in the background

   weight 2 · round drawn
   Clerk—none0/10

   Clerk's evidence covers auth/identity features (webhooks, M2M tokens, eve agent authorization, MCP server for coding assistants) but none of this describes a capability for an AI-native user to configure workflows or automations that run autonomously in the background — Clerk enables agents to authenticate, not to be orchestrated or scheduled. Missing for 10: any documented automation/workflow builder, scheduling, or background task runner within Clerk itself.

   • [claimed-docs] “Clerk webhooks allow you to receive event notifications from Clerk, such as when a user is created or updated.”
   • [claimed-docs] “API keys authenticate programmatic callers; M2M tokens authenticate calls between your agents.”
   • [claimed-docs] “Gate individual eve tool calls against the caller's Clerk permissions and scopes — and broker OAuth for tools that need a provider token on …”
   • [claimed-docs] “**[API keys](https://clerk.com/docs/guides/development/machine-auth/api-keys.md)** authenticate programmatic callers; **[M2M tokens](https:/…”

   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

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

   weight 3 · round drawn
   Clerk—none0/10

   Clerk's AI-related evidence is about enabling external AI coding agents (via an MCP server) to consume Clerk's docs/snippets, and about infrastructure ('eve') for authenticating and authorizing AI agents built by developers — not a built-in assistant inside Clerk's own product that an end-user could delegate tasks to. No evidence of an embedded assistant in the Clerk dashboard or admin console.

   • [claimed-docs] “Clerk provides a remote Model Context Protocol (MCP) server that allows AI agents like Claude, Cursor, and Github Copilot to access Clerk SD…”
   • [claimed-docs] “Clerk provides a remote [Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction) server that allows AI agents like Claud…”
   • [claimed-docs] “API keys authenticate programmatic callers; M2M tokens authenticate calls between your agents.”
   • [claimed-docs] “Gate individual eve tool calls against the caller's Clerk permissions and scopes — and broker OAuth for tools that need a provider token on …”

   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

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

   weight 2 · round to WorkOS
   Clerk~partialprobed5/10

   Clerk exposes a remote MCP server so AI coding agents (Claude, Cursor, Copilot, Codex) can pull SDK snippets and scaffold auth/session/org code via natural-language prompts, and the CLI can connect this MCP server in one command; clerk.com/agents explicitly shows 'Hand Codex the Clerk docs and it scaffolds sign-in, sessions, and orgs.' However this is developer/setup-time tooling (agent-assisted integration), not an end-user natural-language interface for operating the live Clerk product (e.g., managing users/orgs via chat) — missing for 10: evidence of natural-language control over runtime product operations (user/org management, billing, settings) rather than just code scaffolding, and independent hands-on confirmation of the MCP server's reliability.

   • [claimed-docs] “Clerk provides a remote Model Context Protocol (MCP) server that allows AI agents like Claude, Cursor, and Github Copilot to access Clerk SD…”
   • [claimed-docs] “Connect the Clerk MCP server to your AI clients in one command, so your agent works with up-to-date Clerk SDK snippets.”
   • [claimed-docs] “Hand Codex the Clerk docs and it scaffolds sign-in, sessions, and orgs.”
   • [probe] “official MCP server documented at https://clerk.com/docs/guides/ai/mcp/clerk-mcp-server”
   • [probe] “official CLI documented at https://clerk.com/cli”

   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
   Clerk—none0/10

   Evidence shows Clerk publishes an OpenAPI JSON spec (clerk-probe-3) and various docs pages, but there is no evidence of an interactive API reference UI (e.g., a 'try it out' console or runnable code sandbox) that lets users execute API calls directly from the docs.

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

   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 to Clerk
   Clerk✓fullprobed9/10

   A probe confirms Clerk publishes a machine-readable OpenAPI spec at a stable public URL (clerk.com/openapi.json) that returns HTTP 200 and contains a valid 'openapi' key, directly satisfying the story. Missing for 10: no independent third-party validation of the spec's completeness/accuracy beyond the probe check.

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

   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
   Clerk—none0/10

   The evidence pack contains no mention of a sandbox/test environment separate from production (no dev-instance vs prod-instance distinction, no test mode, no synthetic data environment) for AI agents or otherwise to safely test against.

   ⚑ 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
   Clerk—none0/10

   The evidence pack shows an OpenAPI spec exists and extensive feature docs, but nowhere is there mention of API versioning scheme, version headers, or a documented deprecation policy for Clerk's APIs/SDKs.

   ⚑ 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 Clerk
   Clerk~partialclaimed4/10

   Clerk documents an open-source migration tool that bulk-creates users from a JSON/CSV file via the Backend API (respecting rate limits), which is a genuine bulk operation capability, but there is no evidence of broader bulk operations (e.g., bulk role/permission updates, bulk org membership changes, bulk deletions) or of an AI agent invoking such bulk actions through the MCP server (which only exposes SDK snippets, not execution). missing for 10: evidence of bulk operations beyond user import, AI-agent-driven bulk actions via API/MCP, and bulk management of organizations/roles/permissions.

   • [claimed-docs] “Clerk provides an open-source tool that takes a JSON or CSV file as input, containing a list of users, and creates a user in Clerk using the…”
   • [claimed-docs] “Migration guide, "Migration tooling": "To aid in basic migrations, Clerk provides an open-source tool that takes a JSON or CSV file as input…”
   • [claimed-docs] “Clerk provides a remote [Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction) server that allows AI agents like Claud…”

   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 Clerk
   Clerk~partialclaimed4/10

   Clerk offers webhooks that fire on events like user creation/update, giving a basic event-trigger mechanism, but there's no evidence of a built-in rules engine, conditional logic, or automated actions beyond delivering the webhook payload — developers must build the 'action' side themselves outside Clerk. Missing for 10: native rules/automation engine, conditional trigger logic, built-in actions (not just event notifications), and any documentation of automation workflows beyond webhook delivery.

   • [claimed-docs] “Clerk webhooks allow you to receive event notifications from Clerk, such as when a user is created or updated.”

   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 drawn
   Clerk—none0/10

   Clerk is presented throughout the evidence as a hosted SaaS (managed dashboard, CLI, remote MCP server, cloud APIs) with no mention of self-hosting, on-premise/private instance deployment, or bringing your own user database. No docs, changelog, or community evidence describe data residency controls or self-managed deployment options. missing for 10: any self-hosted/on-prem deployment option, BYO-database support, or documented data residency/private-instance controls.

   ⚑ 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
   Clerk✓fullclaimed8/10

   Clerk's docs explicitly state Enterprise SSO support for SAML and OIDC protocols with named IdPs Azure AD, Okta, and Google Workspace, plus user data sync — directly matching the story. Missing for 10: independent/hands-on verification of enterprise SSO setup (e.g., a third-party case study or admin walkthrough) and specifics on workforce-directory sync/SCIM depth.

   • [claimed-docs] “Enterprise Single Sign-On (SSO) allows users to sign in seamlessly using their Identity Provider (IdP) credentials (e.g.,Azure AD, Okta, or …”
   • [claimed-docs] “Clerk supports multiple protocols for implementing Enterprise SSO, including SAML and OIDC.”

   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
   Clerk—none0/10

   The evidence pack shows Clerk supports Enterprise SSO via SAML/OIDC and syncs user data on sign-in, but there is no mention anywhere of SCIM provisioning/deprovisioning, group sync, or automated deactivation triggered by IdP changes — the core of this story.

   • [claimed-docs] “Enterprise Single Sign-On (SSO) allows users to sign in seamlessly using their Identity Provider (IdP) credentials (e.g.,Azure AD, Okta, or …”
   • [claimed-docs] “Clerk supports multiple protocols for implementing Enterprise SSO, including SAML and OIDC.”

   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 to WorkOS
   Clerk!disputedcontradicted3/10

   Clerk documents an 'Admin Logs' audit trail for dashboard/admin actions and general webhook event notifications, but there's no evidence of tamper-evidence, SIEM streaming/export integrations, or full auth-event logging — and a hands-on community report explicitly states Clerk is 'lacking audit logs/versioning,' directly contradicting the audit-log claim. missing for 10: SIEM/webhook-to-SIEM streaming or export integration, tamper-evidence/immutability guarantees, comprehensive auth-event (not just admin-action) audit coverage, and resolution of the community-reported lack of audit logs.

   • [claimed-docs] “Audit Dashboard activity with Admin Logs: An audit trail of admin actions across your workspace”
   • [claimed-docs] “Clerk webhooks allow you to receive event notifications from Clerk, such as when a user is created or updated.”
   • [community] “Clerk is just a mess. They cram EVERYTHING into their libraries: Web3 crap, Stripe, etc. Clerk's JS blob is now triggering browser inspector…”

   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 to Clerk
   Clerk✓fullclaimed7/10

   Clerk documents first-party webhooks for auth events like user creation/updates, plus a CLI feature to relay webhook deliveries locally for testing signatures offline, directly supporting sync-to-external-systems use cases. Missing for 10: a full enumerated list of supported event types (sign-in specifically), independent/hands-on developer confirmation of webhook reliability, and details on delivery guarantees/retries.

   • [claimed-docs] “Clerk webhooks allow you to receive event notifications from Clerk, such as when a user is created or updated.”
   • [claimed-docs] “Relay webhook deliveries to your local handler and verify their signatures offline, with no public tunnel service.”
   • [claimed-docs] “Set up and manage Billing for B2C and B2B applications, including free trials, Subscription Plans, payments, and webhook events.”

   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 to Clerk
   Clerk~partialcommunity6/10

   Clerk's docs confirm first-party Next.js support and JWT-based short-lived session tokens for backend/API authentication (clerk-docs-19, clerk-docs-6/22/32), and community feedback praises the Next.js integration story (clerk-comm-11), supporting the framework-SDK claim. However, the evidence pack never explicitly documents the clerkMiddleware()/edge-runtime session verification mechanism or peer-framework (Remix, SvelteKit, etc.) middleware parity. Missing for 10: explicit middleware API docs, edge-runtime verification details, and coverage of non-Next.js framework middleware equivalents.

   • [claimed-docs] “Easily add secure, beautiful, and fast authentication to Next.js with Clerk.”
   • [claimed-docs] “Clerk generates a short-lived session token that you can use to authenticate requests to your backend. This token is a JSON Web Token (JWT) …”
   • [claimed-docs] “When a user is authenticated in your application, Clerk generates a short-lived session token that you can use to authenticate requests to y…”
   • [claimed-docs] “Clerk generates a short-lived session token that you can use to authenticate requests to your backend.”
   • [community] “Really good stuff. The Next.js integration story is already really quite good and the Clerk team has really good ideas on how to make it eve…”
   • [github] “Clerk helps developers build user management. We provide streamlined user experiences for your users to sign up, sign in, and manage their p…”

   proof ↗⚑ 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 to Clerk
   Clerk✓fullclaimed8/10

   Clerk's docs strongly evidence prebuilt drop-in UI components (SignIn/SignUp, profile management), customization of branding/CSS, Next.js and other framework integration, and CLI-driven production deployment (domains, OAuth providers, DNS) supporting shipping to production. Community threads raise reliability/complexity concerns but do not contradict the core UI-component/profile-management capability itself. Missing for 10: explicit first-party documentation of hosted/account-portal pages (as opposed to embedded components) and independent hands-on confirmation of the full sign-up/sign-in/profile flow in production.

   • [claimed-docs] “Clerk's prebuilt UI components give you a beautiful, fully-functional user management experience in minutes.”
   • [claimed-docs] “Add user `<SignUp/>` and `<SignIn/>`, provide account access through a dropdown menu, and manage profile and security settings.”
   • [claimed-docs] “Customize Clerk's UI components, email templates, and other aspects of the user experience to match your application's branding and user int…”
   • [claimed-docs] “Easily add secure, beautiful, and fast authentication to Next.js with Clerk.”
   • [claimed-docs] “Drop-in UI components for authentication, profile management, organization management, and billing.”
   • [claimed-docs] “Match to your brand with any CSS library, then deploy to your own domain.”
   • [claimed-docs] “Start in the repo you already have. Clerk detects the framework, links an app, and adds the auth files your project needs.”
   • [claimed-docs] “Ship your auth to production from the CLI. Clerk helps you set up your domain, OAuth providers, and DNS records with confidence.”
   • [github] “Clerk helps developers build user management. We provide streamlined user experiences for your users to sign up, sign in, and manage their p…”

   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 Clerk
   Clerk✓fullclaimed8/10

   Clerk documents built-in bot detection ('advanced bot and multi-account protection...machine learning', 'Bot Detection...continually updated machine learning'), brute-force prevention on OTPs ('built-in brute force prevention'), disposable-email blocking against fraudulent sign-ups, and MFA (SMS, authenticator app, backup codes) to harden auth flows against credential stuffing. These are first-party vendor claims without independent penetration-test corroboration. missing for 10: independent/hands-on verification of bot/brute-force protection efficacy, and explicit mention of credential-stuffing-specific defenses (e.g., breached-password detection) beyond general bot ML claims.

   • [claimed-docs] “Clerk site: "Bot Detection — Dramatically reduce fraudulent sign-ups with built-in, continually updated machine learning" and "Email and SMS…”
   • [claimed-docs] “Clerk deploys advanced bot and multi-account protection to detect and neutralize attacks in real time. Dramatically reduce fraudulent sign-u…”
   • [claimed-docs] “Stop fraudulent sign-ups by blocking high-risk disposable email domains, or limit email subaddresses that leverage the "+" separator.”
   • [claimed-docs] “Clerk allows you to enable the following second factor strategies: - MFA: - SMS verification code - Authenticator application - Backup codes”
   • [claimed-docs] “If you have multi-factor authentication (MFA) enabled for your application, the sign-in attempt will return a status of needs_second_factor.”

   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 Clerk
   Clerk✓fullclaimed8/10

   Clerk docs explicitly list authenticator app and backup codes as second-factor MFA strategies, alongside SMS, and document the needs_second_factor sign-in status for enforcement. Step-up/reverification is also documented (customizable reverification window for sensitive actions), covering the step-up enforcement requirement. missing for 10: independent hands-on verification of TOTP/backup-code flows and step-up reverification working end-to-end, and more detail on configuring per-action step-up policies.

   • [claimed-docs] “Clerk allows you to enable the following second factor strategies: - MFA: - SMS verification code - Authenticator application - Backup codes”
   • [claimed-docs] “If you have multi-factor authentication (MFA) enabled for your application, the sign-in attempt will return a status of needs_second_factor.”
   • [claimed-docs] “the sign-in attempt will return a status of needs_second_factor”
   • [claimed-docs] “If you have [multi-factor authentication (MFA)](https://clerk.com/docs/guides/configure/auth-strategies/sign-up-sign-in-options.md#multi-fac…”
   • [claimed-docs] “Customize the reverification window: Control how recently users must have authenticated before performing sensitive actions.”

   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 to WorkOS
   Clerk~partialclaimed6/10

   Clerk documents passkey and biometric sign-in support and email/SMS one-time passcodes with brute-force prevention, showing first-class passwordless/WebAuthn options, but passkeys and biometric sign-in are explicitly gated behind paid Pro+ plans rather than being universally free/first-class, and no evidence explicitly confirms magic links as a distinct sign-in strategy. missing for 10: explicit magic-link documentation, confirmation that passkeys are available on all plans (not just Pro+), and independent/hands-on validation of the passwordless UX.

   • [claimed-docs] “Clerk pricing matrix: "Passkeys — Authenticate with any form of passkeys": not included on the Free plan, included on Pro and above; "Biomet…”
   • [claimed-docs] “Clerk site: "Bot Detection — Dramatically reduce fraudulent sign-ups with built-in, continually updated machine learning" and "Email and SMS…”
   • [claimed-docs] “Clerk allows you to enable the following second factor strategies: - MFA: - SMS verification code - Authenticator application - Backup codes”

   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 drawn
   Clerk~partialclaimed6/10

   Clerk's SDKs/components abstract social-login OAuth, and docs show OIDC support for Enterprise SSO, OAuth scoped access, a device-authorization grant for CLIs/TVs, custom OAuth scopes for MCP clients, and short-lived JWT session tokens — all handled without developers touching raw protocol code. However, the evidence never explicitly confirms an authorization-code+PKCE flow or a standard OAuth refresh-token grant/rotation mechanism (session tokens are proprietary short-lived JWTs, not documented OAuth refresh tokens). Missing for 10: explicit PKCE flow documentation, explicit refresh-token grant/rotation details, and independent/hands-on confirmation that the abstraction fully hides protocol nuances in production use.

   • [claimed-docs] “Clerk generates a short-lived session token that you can use to authenticate requests to your backend. This token is a JSON Web Token (JWT) …”
   • [claimed-docs] “Clerk's OAuth implementation supports OAuth scoped access, which lets third-party applications request limited access to specific parts of a…”
   • [claimed-docs] “Clerk supports multiple protocols for implementing Enterprise SSO, including SAML and OIDC.”
   • [claimed-docs] “Clerk's OAuth implementation supports **OAuth scoped access**, which lets third-party applications request limited access to specific parts …”
   • [claimed-docs] “The grant provides a standards-based flow for applications that cannot open a browser or easily accept text input. CLIs, TVs, game consoles,…”
   • [claimed-docs] “Custom OAuth scopes: Give MCP clients precise, discove”
   • [claimed-docs] “When a user is authenticated in your application, Clerk generates a short-lived session token that you can use to authenticate requests to y…”

   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
   Clerk~partialclaimed6/10

   Evidence confirms Clerk supports configurable OAuth flows (scoped access, docs-10/29/44) and Enterprise SSO via SAML/OIDC with multiple IdPs like Azure AD, Okta, Google Workspace (docs-8/28), implying broad provider support without custom code. However, the pack never explicitly enumerates the standard social-provider list (Google, GitHub, Facebook, etc.) or shows a dashboard toggle UI, and community notes raise reliability concerns (clerk-comm-3/4) though these are about RBAC/uptime, not OAuth setup itself. missing for 10: explicit list/screenshot of supported social providers, first-party doc confirming zero-code toggle configuration, independent hands-on confirmation of ease of adding new providers.

   • [claimed-docs] “Enterprise Single Sign-On (SSO) allows users to sign in seamlessly using their Identity Provider (IdP) credentials (e.g.,Azure AD, Okta, or …”
   • [claimed-docs] “Clerk supports multiple protocols for implementing Enterprise SSO, including SAML and OIDC.”
   • [claimed-docs] “Clerk's OAuth implementation supports OAuth scoped access, which lets third-party applications request limited access to specific parts of a…”
   • [claimed-docs] “Clerk's OAuth implementation supports OAuth scoped access, which lets third-party applications request limited access to specific parts of a…”
   • [claimed-docs] “Clerk's OAuth implementation supports **OAuth scoped access**, which lets third-party applications request limited access to specific parts …”

   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
   Clerk~partialclaimed5/10

   Clerk's docs describe 'OAuth scoped access' letting third-party applications request limited access to a user's data through Clerk's API, and changelog notes 'Custom OAuth scopes' for MCP clients — both indicating Clerk can act as an OAuth provider issuing tokens to third-party clients. However, the evidence never details the full provider mechanics (client app registration, consent screens, token/refresh endpoints, discovery metadata) expected from a genuine 'Sign in with my app' OAuth provider setup. Missing for 10: detailed docs/tutorial on registering third-party OAuth client apps against a Clerk-backed app, consent-screen/token-issuance flow documentation, and independent/hands-on confirmation that third parties can integrate 'Sign in with [customer's app]'.

   • [claimed-docs] “Clerk's OAuth implementation supports OAuth scoped access, which lets third-party applications request limited access to specific parts of a…”
   • [claimed-docs] “Clerk's OAuth implementation supports OAuth scoped access, which lets third-party applications request limited access to specific parts of a…”
   • [claimed-docs] “Clerk's OAuth implementation supports **OAuth scoped access**, which lets third-party applications request limited access to specific parts …”
   • [claimed-docs] “Custom OAuth scopes: Give MCP clients precise, discove”

   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
   Clerk~partialprobed6/10

   Clerk exposes a documented OpenAPI/Backend API (clerk-probe-3), session-token backend auth (clerk-docs-6), webhooks, migration via Backend API (clerk-docs-7), and org/role/permission management that mirrors the UI (clerk-docs-3,4,24), suggesting broad API parity with the dashboard/UI experience. However, there is no explicit vendor claim of full UI-to-API parity, and community feedback flags gaps like RBAC limitations and reliability issues that suggest not every UI capability is cleanly API-accessible (clerk-comm-3). missing for 10: explicit parity documentation/statement, evidence that billing/impersonation/admin-dashboard actions are fully API-driven, independent confirmation of complete feature parity.

   • [probe] “PROBE openapi: HTTP 200 at https://clerk.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Clerk generates a short-lived session token that you can use to authenticate requests to your backend. This token is a JSON Web Token (JWT) …”
   • [claimed-docs] “Clerk provides an open-source tool that takes a JSON or CSV file as input, containing a list of users, and creates a user in Clerk using the…”
   • [claimed-docs] “Organizations let you group users with Roles and Permissions. This lets you build multi-tenant B2B apps like Slack (workspaces), Linear (tea…”
   • [claimed-docs] “Users can belong to multiple Organizations, and Clerk provides the Organization context (memberships, Roles, and the Active Organization) in…”
   • [community] “Using Clerk, quite unhappy with it. No proper RBAC (roles tied to organizations, not stored on user itself), and more than once in past week…”

   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 drawn
   Clerk—none0/10

   Evidence only shows a migration tool for importing user data INTO Clerk (JSON/CSV via Backend API) and a general Backend/OpenAPI surface, but nothing documents a bulk data-export feature or open-format export path for users wanting to leave the platform.

   • [claimed-docs] “Clerk provides an open-source tool that takes a JSON or CSV file as input, containing a list of users, and creates a user in Clerk using the…”
   • [claimed-docs] “Migration guide, "Migration tooling": "To aid in basic migrations, Clerk provides an open-source tool that takes a JSON or CSV file as input…”
   • [probe] “PROBE openapi: HTTP 200 at https://clerk.com/openapi.json — contains "openapi" key”

   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 to Clerk
   Clerk~partialclaimed4/10

   Clerk's client SDKs are published on GitHub (clerk/javascript) and it explicitly ships an open-source migration tool, showing some source is publicly readable, but the core Clerk platform/backend is a closed SaaS with no evidence of an open license covering the full product. Missing for 10: explicit license text (e.g., MIT) for the SDK repo, confirmation that the core auth/backend service is open source, and independent verification of license terms.

   • [github] “Clerk helps developers build user management. We provide streamlined user experiences for your users to sign up, sign in, and manage their p…”
   • [claimed-docs] “Migration guide, "Migration tooling": "To aid in basic migrations, Clerk provides an open-source tool that takes a JSON or CSV file as input…”

   proof ↗⚑ 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
   Clerk—none0/10

   Clerk is a hosted, closed-source authentication/user-management SaaS; there is no evidence of a self-hostable core product, on-prem deployment option, or open-source server. Only a small migration CLI tool is open-source, not the core product itself.

   • [claimed-docs] “Clerk provides an open-source tool that takes a JSON or CSV file as input, containing a list of users, and creates a user in Clerk using the…”
   • [claimed-docs] “Migration guide, "Migration tooling": "To aid in basic migrations, Clerk provides an open-source tool that takes a JSON or CSV file as input…”

   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 drawn
   Clerk~partialclaimed5/10

   Clerk documents Organizations for multi-tenant B2B apps and Enterprise SSO (SAML/OIDC) with IdP sync, which together support giving customer orgs their own SSO connections. However, there is no explicit documentation of per-organization SSO connection scoping, verified-domain-based auto-join/JIT provisioning tied to a specific org, or an admin flow for org-level domain verification — these are typically distinct enterprise features not evidenced here. Missing for 10: explicit per-org SSO connection binding, domain verification workflow, and JIT provisioning-on-domain-match documentation, plus independent confirmation these work together as described.

   • [claimed-docs] “Organizations let you group users with Roles and Permissions. This lets you build multi-tenant B2B apps like Slack (workspaces), Linear (tea…”
   • [claimed-docs] “Enterprise Single Sign-On (SSO) allows users to sign in seamlessly using their Identity Provider (IdP) credentials (e.g.,Azure AD, Okta, or …”
   • [claimed-docs] “Clerk supports multiple protocols for implementing Enterprise SSO, including SAML and OIDC.”
   • [claimed-docs] “Users can belong to multiple Organizations, and Clerk provides the Organization context (memberships, Roles, and the Active Organization) in…”
   • [claimed-docs] “Organizations let you group users with Roles and Permissions. This lets you build multi-tenant B2B apps like Slack (workspaces), Linear (tea…”

   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 to Clerk
   Clerk✓fullcommunity8/10

   Clerk's Organizations feature is well documented: multi-tenant B2B support with grouping users, default admin/member roles plus custom roles and permissions, multiple org membership with active-organization session context, and built-in UI for creating orgs, switching, and viewing memberships/invitations (clerk-docs-3, clerk-docs-4/17/46, clerk-docs-24, clerk-docs-34, clerk-docs-12). This covers the core story out of the box via prebuilt components and APIs. Missing for 10: independent/hands-on corroboration of the invitation flow specifically, and one community comment (clerk-comm-3) notes RBAC is organization-scoped rather than user-scoped, a design caveat rather than a failure.

   • [claimed-docs] “Organizations let you group users with Roles and Permissions. This lets you build multi-tenant B2B apps like Slack (workspaces), Linear (tea…”
   • [claimed-docs] “Clerk provides two default Roles - admin and member - that cover most common use cases. You can also create custom Roles and fine-grained Pe…”
   • [claimed-docs] “Allow your users to create new organizations, switch between accounts, manage settings and billing, and view memberships and invitations.”
   • [claimed-docs] “Users can belong to multiple Organizations, and Clerk provides the Organization context (memberships, Roles, and the Active Organization) in…”
   • [claimed-docs] “each tab "remembers" its chosen Organization for the life of that tab, and displays data and Permissions relevant to that Organization's con…”
   • [claimed-docs] “Clerk provides two default Roles - **admin** and **member** - that cover most common use cases. You can also create custom Roles and fine-gr…”
   • [community] “Using Clerk, quite unhappy with it. No proper RBAC (roles tied to organizations, not stored on user itself), and more than once in past week…”

   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 drawn
   Clerk—none0/10

   No evidence in the pack mentions data residency, regional data storage, or the ability to choose where user data is hosted; Clerk's docs cover auth, orgs, MFA, MCP, CLI, etc., but nothing about region/residency controls.

   ⚑ 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
   Clerk—none0/10

   The evidence pack contains no mention of data retention policies, user data deletion APIs/webhooks, GDPR/CCPA compliance controls, or configurable retention windows — nothing addresses this privacy-posture story despite Clerk being a user-data platform where such controls would be expected.

   ⚑ 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 WorkOS
   Clerk~partialcommunity3/10

   Clerk documents custom Roles and fine-grained Permissions scoped to Organizations, which goes beyond the two default roles, but this is still a classic RBAC model (roles+permission strings tied to org membership) — there is no documented relationship-based (ReBAC/Zanzibar-style) or policy-based (ABAC/OPA-style) resource-level authorization engine. A community report explicitly flags the RBAC as limited ('roles tied to organizations, not stored on user itself'), reinforcing that Clerk does not offer authorization beyond role/permission checks. missing for 10: relationship-graph or ABAC/policy engine, resource-level (object-instance) permission checks, independent confirmation that custom Permissions support conditions/attributes rather than static strings.

   • [claimed-docs] “Clerk provides two default Roles - admin and member - that cover most common use cases. You can also create custom Roles and fine-grained Pe…”
   • [claimed-docs] “You can also create custom Roles and fine-grained Permissions that fit your application's specific features and team setup.”
   • [claimed-docs] “Clerk provides two default Roles - admin and member - that cover most common use cases. You can also create custom Roles and fine-grained Pe…”
   • [claimed-docs] “Clerk provides two default Roles - **admin** and **member** - that cover most common use cases. You can also create custom Roles and fine-gr…”
   • [community] “Using Clerk, quite unhappy with it. No proper RBAC (roles tied to organizations, not stored on user itself), and more than once in past week…”

   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 to WorkOS
   Clerk~partialcommunity7/10

   Clerk's docs clearly show role/permission definition (default admin/member plus custom roles and fine-grained permissions) scoped to Organizations, and confirm that session tokens carry Organization context including memberships and Roles for authorization checks. However, a hands-on community report explicitly criticizes Clerk for lacking 'proper RBAC' because roles are tied to Organizations rather than being storable directly on the user, which is a real limitation on how broadly the enforcement model applies. Missing for 10: evidence of user-level (non-org) role/permission enforcement, first-party code samples showing permission checks against the session JWT claims, and independent corroboration beyond the single critical community post.

   • [claimed-docs] “Clerk provides two default Roles - admin and member - that cover most common use cases. You can also create custom Roles and fine-grained Pe…”
   • [claimed-docs] “You can also create custom Roles and fine-grained Permissions that fit your application's specific features and team setup.”
   • [claimed-docs] “Clerk provides two default Roles - admin and member - that cover most common use cases. You can also create custom Roles and fine-grained Pe…”
   • [claimed-docs] “Users can belong to multiple Organizations, and Clerk provides the Organization context (memberships, Roles, and the Active Organization) in…”
   • [claimed-docs] “each tab "remembers" its chosen Organization for the life of that tab, and displays data and Permissions relevant to that Organization's con…”
   • [claimed-docs] “Clerk provides two default Roles - **admin** and **member** - that cover most common use cases. You can also create custom Roles and fine-gr…”
   • [claimed-docs] “When a user is authenticated in your application, Clerk generates a short-lived session token that you can use to authenticate requests to y…”
   • [community] “Using Clerk, quite unhappy with it. No proper RBAC (roles tied to organizations, not stored on user itself), and more than once in past week…”

   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 to Clerk
   Clerk~partialclaimed6/10

   Clerk explicitly advertises active device monitoring and per-device session revocation in the user profile UI, directly matching the user-facing part of the story. However, the evidence pack does not explicitly document admin-side dashboard controls to view/revoke all users' sessions or a one-click 'revoke all devices' bulk action. missing for 10: explicit admin dashboard session/device management UI, bulk 'revoke all sessions' action, independent/hands-on confirmation of revocation behavior.

   • [claimed-docs] “Clerk site, Session Management: "Clerk manages the full session lifecycle, including critical security functionality like active device moni…”
   • [claimed-docs] “When a user is authenticated in your application, Clerk generates a short-lived session token that you can use to authenticate requests to y…”
   • [claimed-docs] “Clerk generates a short-lived session token that you can use to authenticate requests to your backend. This token is a JSON Web Token (JWT) …”

   proof ↗⚑ 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 to Clerk
   Clerk!disputedcontradicted5/10

   Clerk's docs describe short-lived session JWTs with refresh (clerk-docs-6/22/32) and explicit session-lifecycle management including active device monitoring and per-device/session revocation (clerk-supp-session-devices), which covers expiry, refresh, and revocation as claimed. However a hands-on community report describes production token-refresh failures requiring manual weekend fixes (clerk-comm-1), directly contradicting the reliability of the refresh mechanism in practice. Missing for 10: independent verification of instant/reliable server-side revocation propagation and no corroborating success reports to offset the refresh-failure account.

   • [claimed-docs] “Clerk generates a short-lived session token that you can use to authenticate requests to your backend. This token is a JSON Web Token (JWT) …”
   • [claimed-docs] “When a user is authenticated in your application, Clerk generates a short-lived session token that you can use to authenticate requests to y…”
   • [claimed-docs] “Clerk site, Session Management: "Clerk manages the full session lifecycle, including critical security functionality like active device moni…”
   • [community] “Clerk is just a mess. They cram EVERYTHING into their libraries: Web3 crap, Stripe, etc. Clerk's JS blob is now triggering browser inspector…”

   proof ↗⚑ 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 WorkOS
   Clerk~partialclaimed4/10

   Clerk documents an open-source migration tool that imports users from JSON/CSV via the Backend API (clerk-docs-7, clerk-supp-migration-tool), covering the bulk-import half of the story, but the evidence never mentions preserving/importing password hashes specifically, nor any official export tool or process for getting users back out of Clerk. Missing for 10: explicit password-hash import support, an official export/data-portability tool, and confirmation of round-trip migration to avoid lock-in.

   • [claimed-docs] “Clerk provides an open-source tool that takes a JSON or CSV file as input, containing a list of users, and creates a user in Clerk using the…”
   • [claimed-docs] “Migration guide, "Migration tooling": "To aid in basic migrations, Clerk provides an open-source tool that takes a JSON or CSV file as input…”

   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 WorkOS
   Clerk~partialclaimed5/10

   Clerk documents a vendor-maintained, open-source migration tool that ingests a JSON/CSV list of users and creates them via the Backend API, explicitly for migrating off other providers (clerk-docs-7, clerk-supp-migration-tool). However, the evidence never confirms the tool imports existing password hashes or otherwise avoids forcing users to reset passwords — a key part of this story. Missing for 10: explicit documentation of password/credential hash migration support, guidance on preserving existing sessions, and independent/hands-on confirmation that migrated users are not forced to reset passwords.

   • [claimed-docs] “Clerk provides an open-source tool that takes a JSON or CSV file as input, containing a list of users, and creates a user in Clerk using the…”
   • [claimed-docs] “Migration guide, "Migration tooling": "To aid in basic migrations, Clerk provides an open-source tool that takes a JSON or CSV file as input…”

   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