Auth0 vs Clerk
Auth0 wins · 24–15 (13 drawn)
Agent auth — stories about agent auth in this arenaAgent auth
Stories about agent auth in this arena
Delegation
ai-native userRequire asynchronous human approval (e.g. CIBA-style confirmation) before an autonomous agent completes a sensitive transaction
weight 2 · round to Auth0Auth0 explicitly documents CIBA support for agent workflows: 'Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notifications, SMS, or email, even when the user is not actively using the application,' directly matching the async human-approval-for-sensitive-agent-transaction story. This is first-party vendor documentation specifically targeted at AI agent use cases (auth0.com/ai/docs), though there is no independent/hands-on corroboration or deeper implementation detail (e.g., code samples, latency/timeout behavior). Missing for 10: independent/hands-on verification of CIBA-for-agents in practice, and detailed implementation/config documentation beyond the marketing-level description.
- [claimed-docs] “Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notif…”
- [claimed-docs] “Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notif…”
- [claimed-docs] “Enable AI agents to securely call first-party APIs on the user’s behalf using OAuth 2.0. This ensures that the user’s context is maintained,…”
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.”
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 Auth0Auth0 documents a dedicated Token Vault that obtains, stores, and refreshes short-lived tokens for third-party APIs (Google, Slack, GitHub, Gmail, Spotify, etc.) so agents can act on the user's behalf without handling raw credentials, plus CIBA-based user consent/approval flows for sensitive operations. This directly matches the story's core ask of delegated, user-consented, short-lived token exchange for third-party tool calls. Missing for 10: independent/hands-on verification of the Token Vault in production agent workflows and more detail on token lifetime/scoping guarantees beyond vendor docs.
- [claimed-docs] “Securely connect AI agents to external tools and services like Google, Slack, or GitHub. Auth0’s Token Vault manages obtaining, storing, and…”
- [claimed-docs] “Auth0's Token Vault manages obtaining, storing, and refreshing API tokens, allowing your agents to interact with third-party APIs without ha…”
- [claimed-docs] “Empower agents to search your Gmail inbox, create a GitHub pull request, build a Spotify playlist, or leverage one of our 30+ integrations t…”
- [claimed-docs] “Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notif…”
- [claimed-docs] “Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notif…”
- [claimed-docs] “Enable AI agents to securely call first-party APIs on the user’s behalf using OAuth 2.0. This ensures that the user’s context is maintained,…”
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) …”
Device flow
ai-native userAuthenticate CLIs and headless agents via the OAuth device authorization flow instead of pasting long-lived secrets
weight 2 · round to Auth0Auth0 documents the OAuth 2.0 Device Authorization Flow explicitly for input-constrained devices/CLIs (docs-9, docs-26, docs-40), and its own MCP Server product uses this exact flow to let AI tools like Claude Desktop authenticate against a tenant without pasting long-lived secrets (docs-13, docs-41, auth0-gh-1). This is a first-party, standards-based implementation directly matching the CLI/headless-agent use case in the story. missing for 10: independent/hands-on third-party verification of the device flow specifically in CLI/agent contexts beyond Auth0's own docs and MCP server example.
- [claimed-docs] “With input-constrained devices that connect to the internet, rather than authenticate the user directly, the device asks the user to go to a…”
- [claimed-docs] “Learn how the Device Authorization flow works and why you should use it for input-constrained devices, such as smart TVs and media consoles.”
- [claimed-docs] “device apps use the Device Authorization Flow (ratified in OAuth 2.0), in which they pass along their Client ID to initiate the authorizatio…”
- [claimed-docs] “Use the Auth0 MCP Server to manage your Auth0 tenant through natural language with AI tools, like Claude Desktop, using secure OAuth 2.0 Dev…”
- [claimed-docs] “The Auth0 Model Context Protocol (MCP) Server connects AI agents to your Auth0 tenant, allowing them to perform complex, multi-step operatio…”
- [github] “Connect Claude, Cursor, or Windsurf to your Auth0 tenant to create apps, deploy Actions, debug logs, and manage users — all without touching…”
- [probe] “official MCP server documented at https://auth0.com/docs/get-started/auth0-mcp-server”
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:/…”
Machine identity
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 Auth0Auth0 has dedicated first-party documentation on the Client Credentials flow explicitly for M2M applications like daemons and backend services (auth0-docs-8/25), plus a dedicated Machine-to-Machine feature page describing Client ID/Secret exchange for access tokens without human interaction (auth0-docs-54). This directly matches the story's requirement of credential issuance for backend/agent authentication without a human in the loop. missing for 10: independent/hands-on third-party corroboration specifically confirming the M2M client-credentials flow works as documented (community evidence covers general Auth0 sentiment, not this specific flow).
- [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services, because the system must auth…”
- [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services”
- [claimed-docs] “Applications authenticate themselves to Auth0 via their Client Id and Client Secret. Auth0 verifies the information and responds with an Acc…”
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…”
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 Auth0Auth0 explicitly markets giving each AI agent a unique machine identity (auth0-docs-20, auth0-docs-68) via M2M Client Credentials flow with distinct Client ID/Secret and scoped tokens (auth0-docs-8, auth0-docs-25, auth0-docs-54), plus RBAC to scope permissions narrowly (auth0-docs-7, auth0-docs-39, auth0-docs-45). Missing for 10: explicit documentation of instant/one-click revocation for agent credentials, and independent hands-on validation of this specific agent-identity workflow beyond vendor docs.
- [claimed-docs] “Give each agent a unique digital identity for more secure access to APIs, apps, and MCP servers.”
- [claimed-docs] “Let your AI agents identify users, call APIs, and connect to MCP servers more securely. Get it done with fine-grained controls and just a fe…”
- [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services, because the system must auth…”
- [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services”
- [claimed-docs] “Applications authenticate themselves to Auth0 via their Client Id and Client Secret. Auth0 verifies the information and responds with an Acc…”
- [claimed-docs] “Role-based access control (RBAC) is an authorization strategy to assign permissions to users based on defined roles in an organization.”
- [claimed-docs] “You then assign one or more roles to each user and one or more permissions to each role.”
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…”
Mcp
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 ClerkAuth0's 'AI for Agents' marketing explicitly claims agents can be given unique identities and 'connect to MCP servers more securely' via OAuth 2.0, and mentions Token Vault/CIBA for scoped, verifiable access, but there is no technical documentation showing MCP-spec-specific features (dynamic client registration, resource indicators/RFC8707, PKCE enforcement for MCP resource servers) or a hands-on example of fronting a self-built MCP server with Auth0 as authorization server — the only concrete MCP server doc (auth0-docs-13/41) is Auth0's own tenant-management MCP server, not a customer's protected MCP endpoint. missing for 10: concrete technical walkthrough of protecting a custom MCP server with Auth0-issued scoped tokens, evidence of MCP-spec conformance (DCR, resource metadata), independent/hands-on verification.
- [claimed-docs] “Give each agent a unique digital identity for more secure access to APIs, apps, and MCP servers.”
- [claimed-docs] “Let your AI agents identify users, call APIs, and connect to MCP servers more securely. Get it done with fine-grained controls and just a fe…”
- [claimed-docs] “Enable AI agents to securely call first-party APIs on the user’s behalf using OAuth 2.0. This ensures that the user’s context is maintained,…”
- [claimed-docs] “Securely connect AI agents to external tools and services like Google, Slack, or GitHub. Auth0’s Token Vault manages obtaining, storing, and…”
- [claimed-docs] “Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notif…”
- [claimed-docs] “Use the Auth0 MCP Server to manage your Auth0 tenant through natural language with AI tools, like Claude Desktop, using secure OAuth 2.0 Dev…”
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,…”
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
Agent access
ai-native userPoint an agent at llms.txt or agent-oriented docs
weight 2 · round drawnAuth0 has a live llms.txt file (HTTP 200) that serves as a documentation index, and individual docs pages expose .md variants pointing agents back to the llms.txt index, directly matching the agent-oriented docs pattern. Missing for 10: no independent/community confirmation that agents actually consume this successfully in practice.
- [probe] “PROBE llms.txt: HTTP 200 at https://auth0.com/llms.txt # Auth0 > Secure users, AI agents, and more with Auth0, an easy-to-implement, scalab…”
- [probe] “PROBE docs-md: HTTP 200 at https://auth0.com/docs/get-started/auth0-overview.md > ## Documentation Index > Fetch the complete documentation …”
- [claimed-docs] “You can now configure a Deny All rule within your Tenant Access Control List (ACL) to reject all incoming traffic to your assigned scope.”
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”
ai-native userRun the product headlessly / in CI for automation
weight 2 · round to Auth0Auth0 supports headless/CI-friendly automation via the Client Credentials (M2M) flow for machine-to-machine auth, an official CLI (auth0-cli) for managing tenant config and automating tasks, and Management/Authentication APIs suitable for scripted use. However, evidence doesn't show CI-specific guides, service-account key rotation patterns, or non-interactive testing/staging workflows tailored for CI pipelines. missing for 10: CI-specific documentation/examples, headless testing guidance, evidence of CI pipeline integration patterns.
- [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services, because the system must auth…”
- [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services”
- [probe] “official CLI documented at https://github.com/auth0/auth0-cli”
- [claimed-docs] “Learn how to use Auth0 CLI to manage your tenant configuration, automate tasks, and integrate Auth0 into your deve”
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.”
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · round to Auth0Auth0's AI-agent docs explicitly state that its identity platform lets AI agents 'connect to MCP servers' securely (unique agent identities, Token Vault for token management) rather than Auth0 itself being the MCP client consuming tools — this is infrastructure for developers' agents, not Auth0 acting as the tool-consuming agent. Evidence is limited to marketing-style doc snippets with no technical walkthrough or hands-on confirmation of actual MCP tool invocation. Missing for 10: a concrete technical guide/example showing an agent built on Auth0 actually calling tools from a connected MCP server, and independent/hands-on corroboration of this specific flow.
- [claimed-docs] “Give each agent a unique digital identity for more secure access to APIs, apps, and MCP servers.”
- [claimed-docs] “Let your AI agents identify users, call APIs, and connect to MCP servers more securely. Get it done with fine-grained controls and just a fe…”
- [claimed-docs] “Securely connect AI agents to external tools and services like Google, Slack, or GitHub. Auth0’s Token Vault manages obtaining, storing, and…”
- [claimed-docs] “Auth0's Token Vault manages obtaining, storing, and refreshing API tokens, allowing your agents to interact with third-party APIs without ha…”
Clerknone0/10Clerk's evidence only shows it publishing its own MCP server for other AI agents to consume Clerk's SDK docs (clerk-docs-2/26/-4), which is the opposite direction of the story — Clerk acting as an MCP client that plugs in external MCP servers to use their tools. The 'eve' agent-authorization features (clerk-docs-11, -16, -27) discuss gating tool calls and OAuth brokering for agent tools, but there is no evidence Clerk itself connects to or consumes third-party MCP servers.
- [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] “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] “Gate individual eve tool calls against the caller's Clerk permissions and scopes — and broker OAuth for tools that need a provider token”
ai-native userConnect an agent via an official MCP server
weight 3 · round drawnAuth0 ships an official MCP Server (auth0-mcp-server) documented on their docs site and GitHub, letting AI agents like Claude Desktop, Cursor, or Windsurf connect via OAuth 2.0 Device Authorization to manage the tenant (create apps, deploy Actions, manage users, debug logs). This is a first-party, well-documented server-side MCP integration with both docs and GitHub repo corroboration. Missing for 10: independent/hands-on third-party review of the MCP server's reliability in production use.
- [claimed-docs] “Use the Auth0 MCP Server to manage your Auth0 tenant through natural language with AI tools, like Claude Desktop, using secure OAuth 2.0 Dev…”
- [claimed-docs] “The Auth0 Model Context Protocol (MCP) Server connects AI agents to your Auth0 tenant, allowing them to perform complex, multi-step operatio…”
- [claimed-docs] “Use the Auth0 MCP Server to manage your Auth0 tenant through natural language wit”
- [github] “Connect Claude, Cursor, or Windsurf to your Auth0 tenant to create apps, deploy Actions, debug logs, and manage users — all without touching…”
- [probe] “official MCP server documented at https://auth0.com/docs/get-started/auth0-mcp-server”
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”
ai-native userUse an official CLI
weight 2 · round to ClerkAuth0 ships an official CLI (github.com/auth0/auth0-cli, documented at auth0.com/docs/deploy-monitor/auth0-cli) for managing tenant configuration and automating tasks, which fits the 'official CLI' story for AI-native/agentic workflows. Missing for 10: no independent/hands-on review of the CLI's scripting or automation ergonomics, and no explicit detail on machine-readable output formats for agent integration.
- [claimed-docs] “Learn how to use Auth0 CLI to manage your tenant configuration, automate tasks, and integrate Auth0 into your deve”
- [probe] “official CLI documented at https://github.com/auth0/auth0-cli”
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”
ai-native userDrive the product through a documented public API
weight 3 · round drawnAuth0 exposes a well-documented Management/Authentication API, CLI (auth0-cli), and even an MCP server for AI-native/agentic access, all backed by first-party docs and a public GitHub repo. missing for 10: a discoverable OpenAPI/swagger spec (probe found all candidate paths 404) and independent hands-on developer corroboration specifically of the API/CLI (not just general product sentiment).
- [claimed-docs] “Learn how to use Auth0 CLI to manage your tenant configuration, automate tasks, and integrate Auth0 into your deve”
- [probe] “official CLI documented at https://github.com/auth0/auth0-cli”
- [claimed-docs] “Use the Auth0 MCP Server to manage your Auth0 tenant through natural language with AI tools, like Claude Desktop, using secure OAuth 2.0 Dev…”
- [claimed-docs] “The Auth0 Model Context Protocol (MCP) Server connects AI agents to your Auth0 tenant, allowing them to perform complex, multi-step operatio…”
- [github] “Connect Claude, Cursor, or Windsurf to your Auth0 tenant to create apps, deploy Actions, debug logs, and manage users — all without touching…”
- [probe] “PROBE openapi: all candidate paths 404 (https://auth0.com/openapi.json, https://auth0.com/swagger.json, https://auth0.com/api/openapi.json, …”
- [probe] “PROBE llms.txt: HTTP 200 at https://auth0.com/llms.txt # Auth0 > Secure users, AI agents, and more with Auth0, an easy-to-implement, scalab…”
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”
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · round drawnAuth0 explicitly documents scoped, least-privilege credential issuance for AI agents: M2M client-credentials flow with defined scopes, Token Vault for scoped third-party API tokens, and Auth0 for AI Agents messaging that agents avoid 'broad, unrestricted access' via OAuth 2.0 scoping and unique per-agent identities. This directly matches the story of issuing scoped/least-privilege API credentials to an agent. missing for 10: independent/hands-on verification of scope granularity in practice, and no example showing a concrete least-privilege scope configuration for an agent use case.
- [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services, because the system must auth…”
- [claimed-docs] “Enable AI agents to securely call first-party APIs on the user’s behalf using OAuth 2.0. This ensures that the user’s context is maintained,…”
- [claimed-docs] “Securely connect AI agents to external tools and services like Google, Slack, or GitHub. Auth0’s Token Vault manages obtaining, storing, and…”
- [claimed-docs] “Give each agent a unique digital identity for more secure access to APIs, apps, and MCP servers.”
- [claimed-docs] “Auth0's Token Vault manages obtaining, storing, and refreshing API tokens, allowing your agents to interact with third-party APIs without ha…”
- [claimed-docs] “Empower agents to search your Gmail inbox, create a GitHub pull request, build a Spotify playlist, or leverage one of our 30+ integrations t…”
- [claimed-docs] “Let your AI agents identify users, call APIs, and connect to MCP servers more securely. Get it done with fine-grained controls and just a fe…”
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…”
ai-native userBuild against official SDKs
weight 2 · round to ClerkAuth0 publishes a dedicated AI-agent developer surface (auth0.com/ai/docs) covering agent identity, Token Vault for API access, CIBA async approvals, and FGA for RAG pipelines, described as implementable with 'just a few lines of code,' implying official SDK-level integration for AI-native builders. However, the evidence pack never explicitly names or links a concrete 'Auth0 AI SDK' package, code sample, or language-specific SDK reference for AI agent workflows. Missing for 10: explicit SDK package/repo names for AI agent integration, code snippets/quickstart demonstrating SDK usage, and independent developer corroboration of building against these SDKs.
- [claimed-docs] “Integrate Auth0’s Universal Login into your AI agents to verify user identity, with support for social, enterprise, and custom identity prov…”
- [claimed-docs] “Enable AI agents to securely call first-party APIs on the user’s behalf using OAuth 2.0. This ensures that the user’s context is maintained,…”
- [claimed-docs] “Securely connect AI agents to external tools and services like Google, Slack, or GitHub. Auth0’s Token Vault manages obtaining, storing, and…”
- [claimed-docs] “Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notif…”
- [claimed-docs] “Enforce fine-grained, document-level access control within your Retrieval Augmented Generation (RAG) pipelines using Auth0 FGA.”
- [claimed-docs] “Give each agent a unique digital identity for more secure access to APIs, apps, and MCP servers.”
- [claimed-docs] “Let your AI agents identify users, call APIs, and connect to MCP servers more securely. Get it done with fine-grained controls and just a fe…”
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…”
ai-native userSubscribe to events via webhooks
weight 2 · round to ClerkAuth0 has log streaming (export tenant logs to analysis services) which is an event-export mechanism, but this is not a true webhook subscription API for arbitrary event types—it's log streaming to specific integrations (Datadog, Splunk, etc.), not a generic webhook subscription model. There's no documented dedicated webhook subscription API/endpoint for AI-native agents to subscribe to auth events. Missing for 10: a dedicated webhooks/event-subscription API, documentation of webhook payload formats and subscription management, and any AI-agent-specific webhook integration.
- [claimed-docs] “Auth0’s log streaming service allows you to export tenant logs to a log analysis service.”
- [claimed-docs] “Auth0's log streaming service allows you to export tenant logs to a log analysis service.”
- [claimed-docs] “Auth0's log streaming service allows you to export tenant logs to a log analysis service. You can choose the content type and form and previ…”
- [claimed-docs] “Describes how to export your logs in near real-time using log st”
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.”
Agentic features
ai-native userSet up automations that run autonomously in the background
weight 2 · round to Auth0Auth0 is an identity platform, not a workflow/automation builder, but it does support agentic use cases where an AI agent can act on a user's behalf asynchronously — e.g. Actions run automatically as tenant-defined logic on login events, and CIBA lets agents request approval for sensitive operations 'even when the user is not actively using the application,' enabling some background/autonomous agent behavior. This is far short of a general-purpose 'set up automations that run autonomously' capability. Missing for 10: a scheduler or workflow orchestration engine, evidence of user-configured recurring/background jobs, and any hands-on/independent confirmation that agents actually run unattended via these primitives.
- [claimed-docs] “Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notif…”
- [claimed-docs] “Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notif…”
- [claimed-docs] “Actions are a more secure, tenant-specific, versioned Node.js functions that let you customize your login and identity flows.”
- [claimed-docs] “Empower agents to search your Gmail inbox, create a GitHub pull request, build a Spotify playlist, or leverage one of our 30+ integrations t…”
Clerknone0/10Clerk'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:/…”
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · round drawnAuth0none0/10Auth0 documents an MCP server that lets external AI tools (Claude, Cursor, Windsurf) manage the tenant via natural language, and features for building AI agents into customer apps — but this is the reverse of the story: Auth0 itself does not ship a built-in AI assistant inside its own product/dashboard that users delegate tasks to. No evidence of an in-product Auth0 assistant exists in the pack.
- [claimed-docs] “Use the Auth0 MCP Server to manage your Auth0 tenant through natural language with AI tools, like Claude Desktop, using secure OAuth 2.0 Dev…”
- [claimed-docs] “The Auth0 Model Context Protocol (MCP) Server connects AI agents to your Auth0 tenant, allowing them to perform complex, multi-step operatio…”
- [github] “Connect Claude, Cursor, or Windsurf to your Auth0 tenant to create apps, deploy Actions, debug logs, and manage users — all without touching…”
Clerknone0/10Clerk'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 …”
ai-native userOperate the product with natural-language commands
weight 2 · round to Auth0Auth0 ships an official MCP Server (documented and open-sourced on GitHub) that lets AI tools like Claude Desktop, Cursor, or Windsurf manage the Auth0 tenant (creating apps, deploying Actions, debugging logs, managing users) via natural language, using secure OAuth 2.0 Device Authorization for auth. missing for 10: independent hands-on user reports validating the natural-language UX, and detail on which operations are not yet supported via MCP.
- [claimed-docs] “Use the Auth0 MCP Server to manage your Auth0 tenant through natural language with AI tools, like Claude Desktop, using secure OAuth 2.0 Dev…”
- [claimed-docs] “The Auth0 Model Context Protocol (MCP) Server connects AI agents to your Auth0 tenant, allowing them to perform complex, multi-step operatio…”
- [claimed-docs] “Use the Auth0 MCP Server to manage your Auth0 tenant through natural language wit”
- [github] “Connect Claude, Cursor, or Windsurf to your Auth0 tenant to create apps, deploy Actions, debug logs, and manage users — all without touching…”
- [probe] “official MCP server documented at https://auth0.com/docs/get-started/auth0-mcp-server”
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”
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round drawnAuth0none0/10No evidence of an interactive API reference with runnable examples; the OpenAPI probe explicitly returned 404 on all candidate paths, and docs are static markdown/prose rather than an interactive try-it-out console.
- [probe] “PROBE openapi: all candidate paths 404 (https://auth0.com/openapi.json, https://auth0.com/swagger.json, https://auth0.com/api/openapi.json, …”
- [probe] “PROBE docs-md: HTTP 200 at https://auth0.com/docs/get-started/auth0-overview.md > ## Documentation Index > Fetch the complete documentation …”
Clerknone0/10Evidence 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”
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round to ClerkAuth0none0/10The evidence pack shows an explicit probe for OpenAPI/swagger spec files at Auth0's common paths, all returning 404, and no other citation mentions a downloadable machine-readable API spec (only llms.txt discovery files and MCP/CLI tooling are documented).
- [probe] “PROBE openapi: all candidate paths 404 (https://auth0.com/openapi.json, https://auth0.com/swagger.json, https://auth0.com/api/openapi.json, …”
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”
ai-native userTest against a sandbox environment without touching production data
weight 1 · round drawnAuth0none0/10The evidence pack contains no mention of sandbox/test tenants, staging environments, or any mechanism to test integrations against non-production data — all citations focus on production auth flows, MFA, RBAC, migration, logging, and AI-agent identity features. This is a fair axis for an auth platform (tenants/environments are common), but nothing in the pack shows Auth0 providing an explicit sandbox separate from production.
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round drawnAuth0none0/10No evidence pack items reference API versioning, version numbers, or a documented deprecation policy for Auth0's Management/Authentication APIs; the openapi.json probe even returned 404s. Missing for 10: any documentation of API versioning scheme, deprecation notices/changelog policy, or sunset timelines for breaking changes.
- [probe] “PROBE openapi: all candidate paths 404 (https://auth0.com/openapi.json, https://auth0.com/swagger.json, https://auth0.com/api/openapi.json, …”
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
ai-native userPerform bulk operations across many items at once
weight 2 · round drawnAuth0 documents bulk user import/export for migrations (auth0-docs-11, auth0-docs-46, auth0-docs-57) and an MCP server that lets AI agents perform 'complex, multi-step operations' like creating apps or managing users via natural language (auth0-docs-41, auth0-docs-13, auth0-gh-1), which gives some automation-depth support. However, there is no evidence of a genuine bulk/batch API (e.g., batch create/update/delete many resources in one call) exposed to AI-native tooling beyond the narrow bulk-import use case. Missing for 10: explicit bulk operation endpoints or MCP tool calls that act on many items at once (not just user migration), and any hands-on confirmation that the MCP server or CLI supports batch actions across large item sets.
- [claimed-docs] “Migrate users from an existing database or service to Auth0 using bulk imports for database connections.”
- [claimed-docs] “Migrate your user data into and out of Auth0 with automatic migration and bulk imports and exports.”
- [claimed-docs] “Transferring user databases can be a developer's nightmare. We've simplified the process so you can either do a bulk import or gradually mig…”
- [claimed-docs] “The Auth0 Model Context Protocol (MCP) Server connects AI agents to your Auth0 tenant, allowing them to perform complex, multi-step operatio…”
- [claimed-docs] “Use the Auth0 MCP Server to manage your Auth0 tenant through natural language with AI tools, like Claude Desktop, using secure OAuth 2.0 Dev…”
- [github] “Connect Claude, Cursor, or Windsurf to your Auth0 tenant to create apps, deploy Actions, debug logs, and manage users — all without touching…”
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…”
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round to Auth0Auth0 Actions are versioned, event-triggered Node.js functions that let users define custom logic firing automatically on login/identity events (e.g., post-login, M2M token issuance), which directly matches the 'rules that trigger actions on events' story, and log streaming further extends automated event export to external systems. Missing for 10: independent/hands-on validation of Actions' event-trigger breadth, and no explicit AI-native framing of this specific automation feature (AI-agent evidence in the pack focuses on auth flows, not rule/event automation).
- [claimed-docs] “Actions are a more secure, tenant-specific, versioned Node.js functions that let you customize your login and identity flows.”
- [claimed-docs] “Auth0’s log streaming service allows you to export tenant logs to a log analysis service.”
- [claimed-docs] “Auth0's log streaming service allows you to export tenant logs to a log analysis service. You can choose the content type and form and previ…”
- [claimed-docs] “Describes how to export your logs in near real-time using log st”
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.”
Deployment control — stories about deployment control in this arenaDeployment control
Stories about deployment control in this arena
Deployment
security-engineerControl where the auth system and its user data run — self-managed deployment, private instance, or my own database
weight 2 · round to Auth0Auth0 offers a 'Private Cloud' managed deployment on AWS/Azure for data-residency and isolation needs, which gives some deployment control, but this is still an Auth0-managed service, not a self-hosted/on-prem deployment, and there's no evidence of bringing your own database or fully self-managed instances outside Auth0's control plane. Missing for 10: self-managed/on-prem deployment option, ability to use own database/user store as system of record (only migration import/export is documented, not BYO-DB), and independent confirmation of Private Cloud's isolation guarantees.
- [claimed-docs] “Compare Auth0 Private Cloud-managed service deployment options on AWS and Azure to choose a dedicated, isolated environment that meets your …”
- [claimed-docs] “Compare Auth0 Private Cloud-managed service deployment options on AWS and Azure to choose a dedicated, isolated environment”
- [claimed-docs] “A dedicated, managed cloud service running on AWS providing isolation, higher performance, dev instances, Geo-HA add-ons and more”
- [claimed-docs] “The power of Auth0, with the benefits of a managed private instance — deployable on Microsoft Azure or Amazon Web Services.”
- [claimed-docs] “Migrate your user data into and out of Auth0 with automatic migration and bulk imports and exports.”
Clerknone0/10Clerk 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.
Enterprise sso — stories about enterprise sso in this arenaEnterprise sso
Stories about enterprise sso in this arena
Sso
security-engineerConnect enterprise identity providers over SAML and OIDC (Okta, Entra, Google Workspace) for workforce sign-in
weight 3 · round to ClerkAuth0 explicitly documents SAML-based enterprise authentication (auth0-docs-33), federating an existing enterprise directory service so employees can log in with existing credentials (auth0-docs-37), and pricing/tenant features listing 'Enterprise Connection,' 'Self-Service SSO,' and 'SCIM' as core capabilities (auth0-docs-21), which is Auth0's well-known Enterprise Connections feature covering SAML/OIDC federation with providers like Okta, Entra, and Google Workspace. Missing for 10: explicit named documentation citing Okta/Entra ID/Google Workspace as specific supported enterprise connections, and independent/hands-on corroboration of these specific IdP integrations working in practice.
- [claimed-docs] “You have a web app that needs to authenticate users using Security Assertion Markup Language (SAML)”
- [claimed-docs] “You are part of a large organization that wants to federate your existing enterprise directory service to allow employees to log in to the v…”
- [claimed-docs] “1 Enterprise Connection New * Self-Service SSO New * SCIM New”
- [claimed-docs] “Auth0 Single Sign-On (SSO) lets users authenticate once and access all applications in the same tenant without re-entering credentials.”
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.”
security-engineerSync users and groups from customer directories via SCIM so deprovisioning in the IdP revokes app access
weight 2 · round to Auth0SCIM appears only as a bullet item ('SCIM New') on the pricing page listing enterprise features, with no documentation describing how SCIM provisioning/deprovisioning actually works, how groups sync, or how IdP-triggered deprovisioning revokes app access. Missing for 10: dedicated SCIM configuration docs, deprovisioning behavior details, group sync specifics, and any independent/hands-on confirmation it works as described.
- [claimed-docs] “1 Enterprise Connection New * Self-Service SSO New * SCIM New”
Clerknone0/10The 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.”
Events webhooks — stories about events webhooks in this arenaEvents webhooks
Stories about events webhooks in this arena
Audit
security-engineerCapture tamper-evident audit logs of authentication and admin activity and stream or export them to my SIEM
weight 2 · round to Auth0Auth0 documents a log streaming service that exports tenant logs (including auth/admin activity) to log analysis services in near real-time, which covers the SIEM export/streaming part of the story. However, no evidence addresses tamper-evidence (immutability, cryptographic integrity, WORM storage) of the audit logs, nor lists specific SIEM integrations or retention guarantees. Missing for 10: explicit tamper-evident/immutable log guarantees, named SIEM integrations (e.g., Splunk, Datadog, Sumo Logic), and independent verification of log integrity.
- [claimed-docs] “Auth0’s log streaming service allows you to export tenant logs to a log analysis service.”
- [claimed-docs] “Auth0's log streaming service allows you to export tenant logs to a log analysis service.”
- [claimed-docs] “Auth0's log streaming service allows you to export tenant logs to a log analysis service. You can choose the content type and form and previ…”
- [claimed-docs] “Describes how to export your logs in near real-time using log st”
Clerkdisputedcontradicted3/10Clerk 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…”
Webhooks
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 ClerkAuth0's log streaming service (auth0-docs-12/27/47/58) lets developers export tenant logs — including auth events — in near real-time to external log-analysis/webhook-style destinations, which can be used to keep other systems in sync, and Actions can trigger custom logic on login/signup events. However, the evidence never explicitly documents a webhook subscription model scoped to specific event types (sign-up, sign-in, user changes) as a first-class event-stream API. Missing for 10: explicit webhook endpoint documentation, granular event-type subscription docs, and independent/hands-on confirmation of reliable real-time sync use.
- [claimed-docs] “Auth0’s log streaming service allows you to export tenant logs to a log analysis service.”
- [claimed-docs] “Auth0's log streaming service allows you to export tenant logs to a log analysis service.”
- [claimed-docs] “Auth0's log streaming service allows you to export tenant logs to a log analysis service. You can choose the content type and form and previ…”
- [claimed-docs] “Describes how to export your logs in near real-time using log st”
- [claimed-docs] “Actions are a more secure, tenant-specific, versioned Node.js functions that let you customize your login and identity flows.”
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.”
Framework integration — stories about framework integration in this arenaFramework integration
Stories about framework integration in this arena
Frameworks
developerProtect routes with first-party framework SDKs and middleware (Next.js and peers) that verify sessions at the edge
weight 3 · round to ClerkAuth0none0/10The evidence pack covers Auth0's general auth features, MFA, SSO, MCP server, and AI agent tooling, but contains no mention of Next.js SDK, edge middleware, or session verification at the edge — no evidence of first-party framework SDK/middleware integration for route protection.
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…”
developerShip production sign-in, sign-up, and profile management with prebuilt, customizable UI components or hosted pages
weight 2 · round to ClerkAuth0 documents hosted Universal Login for sign-in/sign-up with password/social/passwordless options, plus no-code Forms editor and Actions for customizing identity flows, and community evidence (HN) corroborates that Universal Login works well and doesn't require JavaScript. However, evidence lacks explicit detail on prebuilt embeddable UI component libraries (e.g., Lock widget) or a dedicated self-service profile-management UI, and one comment notes the offering can be 'rough around the edges.' Missing for 10: explicit documentation of embeddable/prebuilt UI SDK components, dedicated user profile self-management UI, and independent hands-on confirmation of profile management specifically.
- [claimed-docs] “Easily manage authentication across multiple services with just one login. Implement SSO and reduce user fatigue.”
- [claimed-docs] “Quickly tailor the UI and business logic of your identity flows using a no-code editor.”
- [claimed-docs] “Actions are a more secure, tenant-specific, versioned Node.js functions that let you customize your login and identity flows.”
- [claimed-docs] “Your users should be able to log in either with an identifier (username, email, or phone number) and password or with their social accounts …”
- [claimed-docs] “Your users should be able to log in either with an identifier (username, email, or phone number) and password or with their social accounts …”
- [community] “Auth0's implementation of Universal Login didn't require JavaScript, which I liked; Auth0 has been 'on the ball' for a long time with their …”
- [community] “Honestly as auth0 users we were mulling moving over to okta anyway. Auth0's offering has always been slightly rough around the edges and we …”
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…”
Mfa passwordless — stories about mfa passwordless in this arenaMfa passwordless
Stories about mfa passwordless in this arena
Hardening
security-engineerRely on built-in protection against bots, credential stuffing, and brute-force attacks on the auth flows
weight 1 · round to ClerkAuth0 docs explicitly describe proactive IP-blocking against consecutive failed login attempts to prevent brute-force/DDoS, breached-password detection using a compromised-credential database to block credential stuffing, and bot-detection-adjacent adaptive MFA that only challenges risky logins. These directly address bot/credential-stuffing/brute-force protection on auth flows. missing for 10: no explicit CAPTCHA/bot-detection documentation detail, no independent/hands-on validation of attack-blocking efficacy, and no security-engineer testimonial confirming real-world effectiveness.
- [claimed-docs] “You want to act proactively to block suspicious IP addresses if they make consecutive failed login attempts, in order to avoid DDoS attacks.”
- [claimed-docs] “Harness our extensive database of compromised assets to fortify your defense against large-scale account takeover th”
- [claimed-docs] “Adaptive MFA: Only prompt users when a login seems risky, keeping security robust yet user-friendly.”
- [claimed-docs] “If one of your user's email addresses is compromised in some site's public data breach, you want to be notified, and you want to notify the …”
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.”
Mfa
security-engineerRequire multi-factor authentication with TOTP authenticator apps and backup codes, with step-up enforcement where needed
weight 3 · round to ClerkAuth0 docs explicitly list MFA factors including one-time passwords (TOTP) and recovery codes (backup codes) [auth0-docs-38, auth0-docs-23], and Adaptive MFA documentation shows risk-based, step-up-like enforcement that only prompts for MFA when a login looks risky [auth0-docs-50]. These are all vendor-first-party docs with no independent corroboration or explicit 'step-up authentication' API walkthrough in the pack. Missing for 10: independent/hands-on confirmation of step-up enforcement behavior, and explicit docs using the term 'step-up' tied to specific high-risk actions rather than just adaptive login risk scoring.
- [claimed-docs] “Auth0 supports a variety of MFA factors, including: Push notifications, SMS notifications, Voice notifications, One-time passwords, WebAuthn…”
- [claimed-docs] “MFA adds a layer of security during login that requires users to provide more than one credential to prove their digital identity.”
- [claimed-docs] “Adaptive MFA: Only prompt users when a login seems risky, keeping security robust yet user-friendly.”
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.”
Passwordless
developerOffer passkeys/WebAuthn and passwordless options like magic links or email OTP as first-class sign-in methods
weight 2 · round to Auth0Auth0 documents WebAuthn (security keys and device biometrics) as an MFA factor, a dedicated Passwordless feature (email/SMS OTP, magic links), and email/SMS one-time code login as first-class sign-in options alongside password/social login. This covers passkeys/WebAuthn and passwordless magic link/OTP as first-class methods per official docs and feature pages. Missing for 10: independent hands-on developer confirmation specifically of passkey/WebAuthn setup ease, and clearer documentation of magic link (vs OTP) as a distinct flow.
- [claimed-docs] “Auth0 supports a variety of MFA factors, including: Push notifications, SMS notifications, Voice notifications, One-time passwords, WebAuthn…”
- [claimed-docs] “Go passwordless and give users a faster, more secure way to log in.”
- [claimed-docs] “You believe passwords are broken and you want your users to log in with one-time codes delivered by email or SMS.”
- [claimed-docs] “Auth0 supports a variety of MFA factors, including: * Push notifications * SMS notifications * Voice notifications * One-time passw…”
- [claimed-docs] “MFA adds a layer of security during login that requires users to provide more than one credential to prove their digital identity.”
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”
Oauth oidc — stories about oauth oidc in this arenaOauth oidc
Stories about oauth oidc in this arena
Flows
developerImplement standard OAuth 2.0 / OIDC flows (authorization code with PKCE, refresh tokens) without hand-rolling protocol details
weight 3 · round to Auth0Auth0 documents core OAuth2/OIDC flows including client credentials (M2M), device authorization flow (explicitly noted as ratified OAuth 2.0), and general authentication/authorization via Universal Login and SDKs, sparing developers from implementing protocol details themselves. However, the evidence pack lacks explicit first-party documentation or quickstart specifically calling out 'authorization code with PKCE' or refresh token rotation/handling details, and there is no independent hands-on confirmation of PKCE support quality. missing for 10: explicit PKCE flow documentation, refresh token rotation/handling details, independent developer corroboration of authorization-code+PKCE implementation ease.
- [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services, because the system must auth…”
- [claimed-docs] “With input-constrained devices that connect to the internet, rather than authenticate the user directly, the device asks the user to go to a…”
- [claimed-docs] “device apps use the Device Authorization Flow (ratified in OAuth 2.0), in which they pass along their Client ID to initiate the authorizatio…”
- [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services”
- [claimed-docs] “You built an API and you want to secure it with OAuth 2.0.”
- [community] “Cognito is a nightmare and many things are broken. I lost 3 weeks in Feb. on a project trying to get it to work and just integrated Auth0 in…”
- [community] “Cognito and Firebase are bush league by comparison. They can do the basics well enough if you have the right integration engineers. Okta and…”
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…”
developerOffer sign-in with a broad set of social and OAuth identity providers through configuration, not custom code
weight 2 · round to Auth0Auth0's docs explicitly describe adding social login (Facebook, X, etc.) alongside enterprise federation and SAML as configurable connection options rather than custom code, which is a core, well-documented Auth0 capability (auth0-docs-1/22/32/37/33). Missing for 10: an explicit enumerated list of all supported social/OAuth providers and independent hands-on verification that adding a new provider truly requires zero code.
- [claimed-docs] “Your users should be able to log in either with an identifier (username, email, or phone number) and password or with their social accounts …”
- [claimed-docs] “Your users should be able to log in either with an identifier (username, email, or phone number) and password or with their social accounts …”
- [claimed-docs] “Your users should be able to log in either with an identifier (username, email, or phone number) and password or with their social accounts”
- [claimed-docs] “You are part of a large organization that wants to federate your existing enterprise directory service to allow employees to log in to the v…”
- [claimed-docs] “You have a web app that needs to authenticate users using Security Assertion Markup Language (SAML)”
- [claimed-docs] “You built an awesome app and you want to add user authentication and authorization. Your users should be able to log in either with an ident…”
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 …”
Provider
developerTurn my own application into an OAuth provider that issues tokens to third-party clients ("Sign in with my app")
weight 2 · round drawnAuth0's core value proposition includes acting as an OAuth 2.0 authorization server that lets you 'secure your own API' and issue access tokens via flows like Client Credentials (M2M) and Authorization Code, which is the mechanism for turning an app into a token issuer for other clients (auth0-docs-2, auth0-docs-8/25, auth0-docs-54). Organizations also let you configure federated login for external business partners (auth0-docs-6/44). However, the evidence pack lacks explicit documentation of a self-service 'third-party app' registration/consent flow (dynamic client registration, developer marketplace, per-client consent screens) that fully mirrors 'Sign in with my app' for arbitrary third-party developers, missing for 10: dedicated third-party client registration/consent UI docs, dynamic client registration support, and independent hands-on confirmation of building a public OAuth provider on Auth0.
- [claimed-docs] “You built an API and you want to secure it with OAuth 2.0.”
- [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services, because the system must auth…”
- [claimed-docs] “This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services”
- [claimed-docs] “Applications authenticate themselves to Auth0 via their Client Id and Client Secret. Auth0 verifies the information and responds with an Acc…”
- [claimed-docs] “Auth0 customers can use Organizations to: * Represent their business customers and partners in Auth0 and manage their membership. * Con…”
- [claimed-docs] “Auth0 customers can use Organizations to: Represent their business customers and partners in Auth0 and manage their membership. Configure br…”
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”
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
ai-native userDo everything through the API that I can do in the UI
weight 2 · round to Auth0Auth0 exposes a Management API surfaced through both an official CLI (auth0-docs-61, probe-5) and an MCP server that explicitly lets AI agents 'create apps, deploy Actions, debug logs, and manage users — all without touching the dashboard' (auth0-gh-1, auth0-docs-41), showing strong API/automation parity with UI tasks. However, there is no explicit documentation or independent verification claiming 100% feature parity between the Management API and every UI/dashboard capability, and a direct OpenAPI spec probe returned 404s (auth0-probe-3). Missing for 10: explicit 'full API parity' documentation, independent hands-on confirmation of parity, and a public OpenAPI/swagger spec.
- [github] “Connect Claude, Cursor, or Windsurf to your Auth0 tenant to create apps, deploy Actions, debug logs, and manage users — all without touching…”
- [claimed-docs] “The Auth0 Model Context Protocol (MCP) Server connects AI agents to your Auth0 tenant, allowing them to perform complex, multi-step operatio…”
- [claimed-docs] “Learn how to use Auth0 CLI to manage your tenant configuration, automate tasks, and integrate Auth0 into your deve”
- [probe] “PROBE openapi: all candidate paths 404 (https://auth0.com/openapi.json, https://auth0.com/swagger.json, https://auth0.com/api/openapi.json, …”
- [probe] “official CLI documented at https://github.com/auth0/auth0-cli”
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…”
ai-native userExport all of my data in open formats and leave
weight 3 · round to Auth0Auth0 documents bulk export/import of user data and log streaming export (auth0-docs-46, auth0-docs-66, auth0-docs-12), showing some data portability, but there is no explicit claim of exporting *all* tenant/user data in standardized open formats, and community commentary notes 'strong vendor lock-in' (auth0-comm-15) as a caveat. missing for 10: explicit open-format (e.g., JSON/CSV standard) full-tenant export guarantee, independent confirmation that a customer successfully exported and migrated away, and no evidence of a comprehensive one-click 'leave with all data' feature.
- [claimed-docs] “Migrate your user data into and out of Auth0 with automatic migration and bulk imports and exports.”
- [claimed-docs] “Import and Export User Data”
- [claimed-docs] “Auth0’s log streaming service allows you to export tenant logs to a log analysis service.”
- [claimed-docs] “Auth0's log streaming service allows you to export tenant logs to a log analysis service.”
- [community] “The dominant player in this space is Auth0, who appeals to enterprises but lags behind in developer-friendliness and has strong vendor lock-…”
Clerknone0/10Evidence 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”
ai-native userRead the product's source under an open license
weight 2 · round to ClerkAuth0none0/10Auth0 is a proprietary, closed-source SaaS identity platform; there is no evidence of an open-license source release for the core product (only an MCP server and CLI are on GitHub, which are tooling, not the product itself).
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…”
ai-native userSelf-host the core product
weight 3 · round drawnAuth0none0/10Auth0 is offered exclusively as a managed SaaS (with a Private Cloud option deployed by Auth0 on AWS/Azure, not self-hosted by the customer); there is no evidence of an open-source or self-hostable core product that an AI-native user could run on their own infrastructure.
- [claimed-docs] “Compare Auth0 Private Cloud-managed service deployment options on AWS and Azure to choose a dedicated, isolated environment that meets your …”
- [claimed-docs] “Compare Auth0 Private Cloud-managed service deployment options on AWS and Azure to choose a dedicated, isolated environment”
- [claimed-docs] “A dedicated, managed cloud service running on AWS providing isolation, higher performance, dev instances, Geo-HA add-ons and more”
- [claimed-docs] “The power of Auth0, with the benefits of a managed private instance — deployable on Microsoft Azure or Amazon Web Services.”
Clerknone0/10Clerk 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…”
Orgs multitenant — stories about orgs multitenant in this arenaOrgs multitenant
Stories about orgs multitenant in this arena
Orgs
security-engineerGive each customer organization its own SSO connection with verified domains and just-in-time provisioning
weight 2 · round to Auth0Auth0 Organizations lets security engineers represent each B2B customer/partner and configure branded, federated login flows per business (auth0-docs-6, auth0-docs-24, auth0-docs-44), and pricing page shows Enterprise Connection, Self-Service SSO, and SCIM as organization-related add-ons (auth0-docs-21). However, the evidence pack lacks explicit documentation of verified/claimed domains for automatic org routing or of just-in-time provisioning behavior tied to organizations. missing for 10: explicit docs on domain verification/home-realm-discovery per organization, explicit JIT provisioning documentation scoped to Organizations, and independent/hands-on confirmation of this multi-tenant SSO setup working end-to-end.
- [claimed-docs] “Auth0 customers can use Organizations to: * Represent their business customers and partners in Auth0 and manage their membership. * Con…”
- [claimed-docs] “Configure branded, federated login flows for each business.”
- [claimed-docs] “Auth0 customers can use Organizations to: Represent their business customers and partners in Auth0 and manage their membership. Configure br…”
- [claimed-docs] “1 Enterprise Connection New * Self-Service SSO New * SCIM New”
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…”
developerModel multi-tenant B2B apps with organizations, memberships, and invitation flows out of the box
weight 3 · round to ClerkAuth0 docs explicitly describe an Organizations feature for representing B2B customers/partners, managing their membership, and configuring branded federated login flows per business (auth0-docs-6/24/44/65), plus RBAC for role-based permissions (auth0-docs-7/39/45). However, the evidence pack contains no mention of invitation flows or invitation APIs for organization members, which is a core part of the story. Missing for 10: explicit documentation of organization invitation/onboarding flows, and independent/hands-on corroboration of multi-tenant org setup working end-to-end.
- [claimed-docs] “Auth0 customers can use Organizations to: * Represent their business customers and partners in Auth0 and manage their membership. * Con…”
- [claimed-docs] “Configure branded, federated login flows for each business.”
- [claimed-docs] “Auth0 customers can use Organizations to: Represent their business customers and partners in Auth0 and manage their membership. Configure br…”
- [claimed-docs] “Auth0 Organizations”
- [claimed-docs] “Role-based access control (RBAC) is an authorization strategy to assign permissions to users based on defined roles in an organization.”
- [claimed-docs] “You then assign one or more roles to each user and one or more permissions to each role.”
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…”
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
ai-native userChoose where my data is stored (region/residency)
weight 2 · round to Auth0Auth0 Private Cloud deployment docs mention meeting 'data-residency' requirements via dedicated deployment on AWS or Azure, implying some regional choice, but this is only for the enterprise-tier Private Cloud offering, not the standard multi-tenant product. missing for 10: explicit list of supported regions/data centers, region-selection mechanism in the standard product/dashboard, and any documentation on residency guarantees for the mainstream SaaS tier.
- [claimed-docs] “Compare Auth0 Private Cloud-managed service deployment options on AWS and Azure to choose a dedicated, isolated environment that meets your …”
- [claimed-docs] “Compare Auth0 Private Cloud-managed service deployment options on AWS and Azure to choose a dedicated, isolated environment”
- [claimed-docs] “A dedicated, managed cloud service running on AWS providing isolation, higher performance, dev instances, Geo-HA add-ons and more”
- [claimed-docs] “The power of Auth0, with the benefits of a managed private instance — deployable on Microsoft Azure or Amazon Web Services.”
ai-native userControl data retention and deletion
weight 2 · round drawnAuth0none0/10The evidence pack covers user migration/export/import, log streaming, and SSO/MFA, but nothing addresses configurable data retention periods or user data deletion controls (e.g., right-to-be-forgotten, account deletion APIs, retention policy settings). Absence of evidence for this applicable privacy-posture axis means it is unverified.
- [claimed-docs] “Migrate your user data into and out of Auth0 with automatic migration and bulk imports and exports.”
- [claimed-docs] “Transferring user databases can be a developer's nightmare. We've simplified the process so you can either do a bulk import or gradually mig…”
- [claimed-docs] “Import and Export User Data”
- [claimed-docs] “Auth0’s log streaming service allows you to export tenant logs to a log analysis service.”
Clerknone0/10The 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.
ai-native userOpt out of telemetry and usage tracking
weight 2 · round drawnAuth0none0/10No evidence in the pack addresses telemetry/usage-tracking opt-out settings for Auth0 or its AI/MCP tooling; all documentation covers authentication, MFA, SSO, RBAC, migration, and AI-agent identity features unrelated to telemetry controls.
Rbac permissions — stories about rbac permissions in this arenaRbac permissions
Stories about rbac permissions in this arena
Rbac
security-engineerExpress fine-grained, resource-level authorization (relationship- or policy-based) beyond simple roles
weight 1 · round to Auth0Auth0 explicitly offers Auth0 FGA, described as 'a unified, relationship-based platform that helps secure multi-tenant B2B APIs and apps, and decouples complex authorization logic from your code,' going beyond basic RBAC, plus document-level access control for RAG pipelines and 'advanced authorization mechanics for more flexible access control.' This directly matches the relationship/policy-based fine-grained authorization ask, distinct from the separate RBAC docs. Missing for 10: deeper technical documentation on FGA's authorization model/policy language, and independent/hands-on validation of FGA in production beyond marketing copy.
- [claimed-docs] “Auth0 FGA provides a unified, relationship-based platform that helps secure multi-tenant B2B APIs and apps, and decouples complex authorizat…”
- [claimed-docs] “Enforce fine-grained, document-level access control within your Retrieval Augmented Generation (RAG) pipelines using Auth0 FGA.”
- [claimed-docs] “Enforce fine-grained, document-level access control within your Retrieval Augmented Generation (RAG) pipelines using Auth0 FGA”
- [claimed-docs] “Seamlessly define access roles for your apps and APIs, and tap into advanced authorization mechanics for more flexible access control.”
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…”
developerDefine roles and permissions and have them enforced and surfaced in session tokens for authorization checks
weight 3 · round to Auth0Auth0 docs clearly describe RBAC where roles are assigned to users and permissions to roles (auth0-docs-7, auth0-docs-39, auth0-docs-45), and the broader access-management platform page confirms role-based access control for apps and APIs (auth0-docs-56). Auth0's RBAC is standardly surfaced via permissions claims in access tokens for authorization checks, consistent with the OAuth2-based API security flows documented (auth0-docs-2, auth0-docs-8). Missing for 10: explicit first-party documentation snippet showing the permissions/roles claim appearing inside issued session/access tokens, and independent hands-on confirmation of token enforcement behavior.
- [claimed-docs] “Role-based access control (RBAC) is an authorization strategy to assign permissions to users based on defined roles in an organization.”
- [claimed-docs] “You then assign one or more roles to each user and one or more permissions to each role.”
- [claimed-docs] “When using RBAC for Role Management, you analyze the needs of your users and group them into roles based on common responsibilities. You the…”
- [claimed-docs] “Seamlessly define access roles for your apps and APIs, and tap into advanced authorization mechanics for more flexible access control.”
- [claimed-docs] “You built an API and you want to secure it with OAuth 2.0.”
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…”
Session management — stories about session management in this arenaSession management
Stories about session management in this arena
Sessions
security-engineerLet users and admins see active sessions and devices and revoke them individually or all at once
weight 1 · round to ClerkAuth0none0/10No evidence in the pack describes session/device visibility or revocation features (active session lists, per-device revocation, or 'log out all devices' controls) for end users or admins; the pack covers login flows, MFA, SSO, RBAC, migration, and AI agent integrations but never session management.
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) …”
developerManage session lifecycle — expiry, refresh, and immediate server-side revocation of a compromised session
weight 3 · round to ClerkAuth0none0/10The evidence pack covers login flows, SSO, MFA, RBAC, Organizations, and AI-agent security features, but contains no documentation of session lifetime configuration, refresh-token rotation/expiry controls, or an API/dashboard action for immediately revoking a live session — a core, expected capability for an identity platform. Since this is a fair and applicable axis for Auth0 but no supporting evidence is present, it cannot be credited as full/partial.
Clerkdisputedcontradicted5/10Clerk'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…”
User migration — stories about user migration in this arenaUser migration
Stories about user migration in this arena
Migration
developerBulk-import existing users — including password hashes — and export them again, so I am never locked in
weight 2 · round to Auth0Auth0 docs clearly describe bulk import and export of user data ('Migrate your user data into and out of Auth0 with automatic migration and bulk imports and exports' — auth0-docs-46/57/66) and gradual migration via import mode (auth0-docs-10/11). However, the evidence never specifically confirms password-hash import support or details the export format/API, and one community comment even flags Auth0 as having 'strong vendor lock-in' (auth0-comm-15), which cuts against the 'never locked in' framing. Missing for 10: explicit documentation of password-hash import fields, concrete export API/schema details, and independent confirmation that migration avoids lock-in.
- [claimed-docs] “Gradually migrate users from your external user store to Auth0 as they log in by enabling import mode on your custom database connection.”
- [claimed-docs] “Migrate users from an existing database or service to Auth0 using bulk imports for database connections.”
- [claimed-docs] “Migrate your user data into and out of Auth0 with automatic migration and bulk imports and exports.”
- [claimed-docs] “Transferring user databases can be a developer's nightmare. We've simplified the process so you can either do a bulk import or gradually mig…”
- [claimed-docs] “Import and Export User Data”
- [community] “The dominant player in this space is Auth0, who appeals to enterprises but lags behind in developer-friendliness and has strong vendor lock-…”
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…”
founderFollow vendor-maintained migration guides or tooling for moving off a competing auth provider without forcing password resets
weight 1 · round to Auth0Auth0 documents vendor-maintained tooling for exactly this need: gradual migration via import mode that migrates users transparently as they log in (no forced password reset) plus bulk import/export for one-time migrations from an external user store or database. Missing for 10: named step-by-step guides for migrating from specific competing providers (e.g., Okta, Cognito, Firebase) rather than generic import-mode docs, and independent/hands-on evidence confirming migrations complete without any password resets in practice.
- [claimed-docs] “Gradually migrate users from your external user store to Auth0 as they log in by enabling import mode on your custom database connection.”
- [claimed-docs] “Migrate users from an existing database or service to Auth0 using bulk imports for database connections.”
- [claimed-docs] “Migrate your user data into and out of Auth0 with automatic migration and bulk imports and exports.”
- [claimed-docs] “Transferring user databases can be a developer's nightmare. We've simplified the process so you can either do a bulk import or gradually mig…”
- [claimed-docs] “Import and Export User Data”
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…”
Not comparable on these axes
ai-native userGet AI-generated insights and suggestions from my data inside the product
weight 2 · not comparableAuth0none0/10The evidence pack's AI material (auth0-docs-15 to 20, 29-31, 41-42) is entirely about Auth0 securing AI agents and enabling agentic authentication flows, not about Auth0 itself surfacing AI-generated insights or suggestions from the customer's own tenant/usage data (e.g., no AI-powered anomaly analysis, dashboard copilot, or suggested configuration insights). No evidence shows an in-product AI assistant analyzing logs/user data and proactively suggesting actions.
Clerkn/aClerk is an authentication/user-management infrastructure product, not a data/analytics product; generating AI insights or suggestions from a user's own data is outside its category — the evidence pack only covers auth, orgs, sessions, MCP for SDK snippets, and agent tool authorization, none of which constitute AI-generated insights on user data.
ai-native userSchedule recurring jobs or workflows
weight 2 · not comparableAuth0n/aAuth0 is an identity/authentication platform; scheduling recurring jobs or workflows is not a capability within its product category, and nothing in the evidence suggests it offers job/workflow scheduling.
ai-native userVersion, review, and roll back my automations
weight 1 · not comparableAuth0 Actions are described as 'versioned' Node.js functions for customizing login flows, which offers a thin sliver of versioning for one type of automation, but there is no evidence of review workflows, diffing, approval processes, or rollback mechanisms for Actions or other automations like Flows/Forms. missing for 10: rollback/restore functionality, review/approval workflow, version history UI or API, coverage beyond Actions (e.g., Forms, Rules, tenant config).
- [claimed-docs] “Actions are a more secure, tenant-specific, versioned Node.js functions that let you customize your login and identity flows.”
ai-native userPrevent my data from being used to train AI models
weight 3 · not comparableAuth0n/aAuth0 is an identity/authentication platform, not a data-holding AI model provider or content platform where 'training data opt-out' would be a relevant axis; nothing in the evidence pack relates to AI model training data usage at all.
Clerknone0/10No evidence anywhere in the pack addresses AI training data usage or opt-out policies for Clerk; the evidence covers auth, RBAC, sessions, MCP tooling, and reliability complaints but nothing about data being used for AI training or a mechanism to prevent it. Since Clerk stores user PII, this is a plausible privacy question for the product category, but it's unaddressed.