Clerk vs Better Auth

Delegation

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

   weight 2 · round to Clerk
   Clerk~partialclaimed3/10

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

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

   proof ↗⚑ flag

   Better Auth—none0/10

   Better Auth documents a generic Device Authorization plugin (RFC 8628 approval flow) and a vague marketing line about 'agent delegation' for AI agents, but there is no documented CIBA-style or step-up approval mechanism that pauses an autonomous agent's transaction pending asynchronous human confirmation. No evidence ties any plugin to sensitive-transaction gating for agents.

   • [claimed-docs] “The Device Authorization plugin implements the code issuance and approval flow from the OAuth 2.0 Device Authorization Grant (RFC 8628) for …”
   • [claimed-docs] “The Device Authorization plugin implements the code issuance and approval flow from the OAuth 2.0 Device Authorization Grant (RFC 8628) for …”
   • [claimed-docs] “Auth for AI agents. MCP auth, token exchange, and agent delegation.”

   proof ↗⚑ flag

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

   weight 3 · round to Clerk
   Clerk~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Better Auth~partialclaimed4/10

   Better Auth explicitly markets 'Auth for AI agents. MCP auth, token exchange, and agent delegation' and documents an MCP plugin that lets an app act as an OAuth authorization server/protected resource for MCP clients, plus a Device Authorization plugin for consent-based token issuance on limited-input clients — these are directly relevant primitives for an agent obtaining delegated, short-lived tokens. However, there is no detailed documentation of an actual token-vault/exchange mechanism for arbitrary third-party APIs (only a marketing tagline plus generic OAuth-server framing), and no independent/hands-on evidence confirming this flow works as a user-consented delegation vault. Missing for 10: concrete docs/example of token exchange for third-party API scopes, evidence of short-lived token issuance tied to explicit user consent for agent tool calls, and independent verification of the 'token exchange'/'agent delegation' claims.

   • [claimed-docs] “Auth for AI agents. MCP auth, token exchange, and agent delegation.”
   • [claimed-docs] “The MCP plugin lets your app act as an OAuth authorization server and protected resource for Model Context Protocol clients.”
   • [claimed-docs] “The **MCP** plugin lets your app act as an OAuth authorization server and protected resource for [Model Context Protocol](https://modelconte…”
   • [claimed-docs] “The Device Authorization plugin implements the code issuance and approval flow from the OAuth 2.0 Device Authorization Grant (RFC 8628) for …”
   • [claimed-docs] “The Device Authorization plugin implements the code issuance and approval flow from the OAuth 2.0 Device Authorization Grant ([RFC 8628](htt…”

   proof ↗⚑ flag

Device flow

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

   weight 2 · round to Better Auth
   Clerk~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Better Auth✓fullclaimed8/10

   Better Auth ships a dedicated Device Authorization plugin implementing RFC 8628 explicitly for CLI/headless clients (smart TVs, CLI apps, IoT devices), and docs show it can be tested via the Better Auth CLI, directly matching the story. missing for 10: independent/hands-on third-party verification of the device flow in production and explicit agent-specific integration examples beyond docs.

   • [claimed-docs] “The Device Authorization plugin implements the code issuance and approval flow from the OAuth 2.0 Device Authorization Grant (RFC 8628) for …”
   • [claimed-docs] “The Device Authorization plugin implements the code issuance and approval flow from the OAuth 2.0 Device Authorization Grant (RFC 8628) for …”
   • [claimed-docs] “The Device Authorization plugin implements the code issuance and approval flow from the OAuth 2.0 Device Authorization Grant ([RFC 8628](htt…”
   • [claimed-docs] “You can test the device authorization flow right now using the Better Auth CLI”
   • [claimed-docs] “for limited-input devices such as smart TVs, CLI applications, IoT devices, and gaming consoles.”

   proof ↗⚑ flag

Machine identity

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

   weight 3 · round to Clerk
   Clerk✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   Better Auth~partialclaimed5/10

   Better Auth offers building blocks for service-to-service auth — an API Key plugin for authenticating requests without user login, a JWT plugin for token issuance/verification, and an MCP plugin that lets the app act as an OAuth authorization server for AI agent clients (docs-76: 'Auth for AI agents. MCP auth, token exchange, and agent delegation.') — but none of the evidence explicitly documents an OAuth2 client-credentials grant flow for machine-to-machine authentication. Device Authorization plugin explicitly requires human approval, so it doesn't satisfy the 'no human in the loop' requirement. missing for 10: explicit client-credentials grant documentation, example of service-to-service token issuance without any user context, independent/hands-on validation of M2M flows.

   • [claimed-docs] “The API Key plugin allows you to create and manage API keys for your application. It provides a way to authenticate and authorize API reques…”
   • [claimed-docs] “The JWT plugin provides endpoints to retrieve a JWT token and a JWKS endpoint to verify the token.”
   • [claimed-docs] “The **MCP** plugin lets your app act as an OAuth authorization server and protected resource for [Model Context Protocol](https://modelconte…”
   • [claimed-docs] “Auth for AI agents. MCP auth, token exchange, and agent delegation.”
   • [claimed-docs] “The Device Authorization plugin implements the code issuance and approval flow from the OAuth 2.0 Device Authorization Grant (RFC 8628) for …”

   proof ↗⚑ flag

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

   weight 3 · round to Clerk
   Clerk~partialclaimed7/10

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

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

   proof ↗⚑ flag

   Better Auth~partialclaimed6/10

   Better Auth explicitly markets 'Auth for AI agents: MCP auth, token exchange, and agent delegation' and ships an API Key plugin (create/manage/verify keys, custom expiration, rate limiting, remaining-count/refill) plus an MCP OAuth plugin and session/token revocation, which together give the building blocks for distinct, scoped, revocable machine identities separate from human credentials. However the docs don't show a concrete worked example of assigning narrowly-scoped per-agent permissions (vs. organization-level roles) or an 'instant revocation' guarantee specifically for agent identities, and there's no independent/hands-on validation of this agent-identity workflow. missing for 10: explicit per-agent scoped-permission example, documented instant-revocation SLA for API keys/agent tokens, independent corroboration of agent-identity isolation.

   • [claimed-docs] “The API Key plugin allows you to create and manage API keys for your application. It provides a way to authenticate and authorize API reques…”
   • [claimed-docs] “Create, manage, and verify API keys ... Built-in rate limiting ... Custom expiration times, remaining count, and refill systems”
   • [claimed-docs] “The **MCP** plugin lets your app act as an OAuth authorization server and protected resource for [Model Context Protocol](https://modelconte…”
   • [claimed-docs] “Auth for AI agents. MCP auth, token exchange, and agent delegation.”
   • [claimed-docs] “10:50 AMJohncreated a session 10:48 AMSarahupdated profile 10:45 AMAlexjoined organization 10:42 AMEmmarevoked token 10:38 AMMikeenabled…”
   • [claimed-docs] “A logged in user can also revoke their own sessions to log out from different devices or browsers.”

   proof ↗⚑ flag

Mcp

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

   weight 3 · round to Better Auth
   Clerk~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Better Auth✓fullprobed8/10

   Better Auth ships a first-party MCP plugin explicitly described as letting an app 'act as an OAuth authorization server and protected resource for Model Context Protocol clients,' directly matching the story of fronting an MCP server with spec-compliant OAuth for scoped tokens; it also supports JWT/JWKS verification and API keys that align with scoped, verifiable tokens. Missing for 10: independent hands-on validation of the MCP OAuth flow specifically (community evidence covers other features, not this plugin) and no explicit mention of granular scope definitions within the MCP plugin docs excerpted here.

   • [claimed-docs] “The MCP plugin lets your app act as an OAuth authorization server and protected resource for Model Context Protocol clients.”
   • [claimed-docs] “The **MCP** plugin lets your app act as an OAuth authorization server and protected resource for [Model Context Protocol](https://modelconte…”
   • [claimed-docs] “Auth for AI agents. MCP auth, token exchange, and agent delegation.”
   • [claimed-docs] “The JWT plugin provides endpoints to retrieve a JWT token and a JWKS endpoint to verify the token.”
   • [probe] “official MCP server documented at https://www.better-auth.com/docs/plugins/mcp”

   proof ↗⚑ flag

Agent access

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

   weight 2 · round drawn
   Clerk✓fullprobed9/10

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

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

   proof ↗⚑ flag

   Better Auth✓fullprobed9/10

   Direct probe confirms llms.txt is live and returns 200 with structured docs content, plus .md-suffixed doc pages are directly fetchable (docs-1 through docs-76 all reference .md doc URLs), and Better Auth also hosts a dedicated remote MCP server exposing documentation search/setup help to MCP-capable clients like Cursor and Claude Code. Missing for 10: no independent/third-party report of an agent actually consuming llms.txt or the MCP docs server successfully.

   • [probe] “PROBE llms.txt: HTTP 200 at https://www.better-auth.com/llms.txt # Better Auth > The most comprehensive authentication framework for TypeSc…”
   • [claimed-docs] “Better Auth hosts a remote MCP server that exposes documentation search, examples, and setup help to any MCP-capable client (Cursor, Codex, …”
   • [claimed-docs] “Better Auth hosts a **remote MCP server** that exposes documentation search, examples, and setup help to any MCP-capable client (Cursor, Cod…”
   • [probe] “PROBE docs-md: HTTP 200 at https://www.better-auth.com/docs/introduction.md # Introduction (/docs/introduction) Introduction to Better Auth…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Clerk~partialprobed5/10

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

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

   proof ↗⚑ flag

   Better Auth~partialprobed5/10

   Better Auth is a code-first, server-side library configured entirely in code (not a dashboard), which supports scriptable/CI-friendly setup, and it ships a CLI (used for generating schemas, testing device auth flow, etc.) that can run non-interactively. However, there is no direct evidence of automated/headless test suites, CI pipeline examples, or documentation explicitly addressing running Better Auth in CI/automation contexts, and one community report notes admin scripts/tests were 'hacky' due to header-based request design. missing for 10: explicit CI/automation documentation or examples, evidence of non-interactive CLI scripting for auth setup, and confirmation that the header-based request model doesn't hinder headless script/test usage.

   • [claimed-docs] “No dashboard clicks. Your auth lives in code version controlled, type-safe, and reviewable in PRs.”
   • [claimed-docs] “You can test the device authorization flow right now using the Better Auth CLI”
   • [claimed-docs] “The Device Authorization plugin implements the code issuance and approval flow from the OAuth 2.0 Device Authorization Grant (RFC 8628) for …”
   • [community] “Does Better Auth still have the weird design to be everything 'request header based'? Running admin scripts and tests was very hacky due to …”
   • [probe] “official CLI documented at https://www.better-auth.com/docs/concepts/cli”

   proof ↗⚑ flag

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

   weight 3 · round to Clerk
   Clerk✓fullprobed9/10

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

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

   proof ↗⚑ flag

   Better Auth✓fullprobed8/10

   Better Auth documents a hosted remote MCP server that exposes documentation search/setup help to MCP-capable clients like Cursor, Codex, and Claude Code, and separately ships an MCP plugin letting apps act as an OAuth authorization server for MCP clients — both confirmed by an independent probe of the docs page. Missing for 10: independent/hands-on community confirmation that agents successfully connect via this MCP server (only vendor docs/probe evidence, no user reports).

   • [claimed-docs] “Better Auth hosts a remote MCP server that exposes documentation search, examples, and setup help to any MCP-capable client (Cursor, Codex, …”
   • [claimed-docs] “Better Auth hosts a **remote MCP server** that exposes documentation search, examples, and setup help to any MCP-capable client (Cursor, Cod…”
   • [claimed-docs] “The **MCP** plugin lets your app act as an OAuth authorization server and protected resource for [Model Context Protocol](https://modelconte…”
   • [probe] “official MCP server documented at https://www.better-auth.com/docs/plugins/mcp”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Clerk✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Better Auth✓fullprobed8/10

   Better Auth documents an official CLI (better-auth/docs/concepts/cli) used for migrations, schema generation, and even testing the device authorization flow, confirming it's a real, functional tool rather than a stub. Missing for 10: independent hands-on community verification specifically of CLI usage/quality, and more detail on the full range of CLI subcommands beyond migration/device-auth testing.

   • [probe] “official CLI documented at https://www.better-auth.com/docs/concepts/cli”
   • [claimed-docs] “You can test the device authorization flow right now using the Better Auth CLI”
   • [claimed-docs] “The Device Authorization plugin implements the code issuance and approval flow from the OAuth 2.0 Device Authorization Grant (RFC 8628) for …”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Clerk✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Better Auth✓fullprobed8/10

   Better Auth exposes a well-documented server API (auth.api methods), client SDK (authClient), and machine-readable docs formats (llms.txt, docs.md) explicitly aimed at AI-native consumption, plus a documented CLI and MCP plugin for programmatic auth flows. missing for 10: a discoverable OpenAPI/Swagger schema (probe found all standard OpenAPI paths 404) and independent hands-on confirmation of API robustness by third parties.

   • [claimed-docs] “To authenticate a user on the server, you can use the auth.api methods.”
   • [claimed-docs] “const { data, error } = await authClient.signUp.email({ email, password, name, image, callbackURL: "/dashboard" }”
   • [claimed-docs] “`npx auth init`”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.better-auth.com/llms.txt # Better Auth > The most comprehensive authentication framework for TypeSc…”
   • [probe] “PROBE docs-md: HTTP 200 at https://www.better-auth.com/docs/introduction.md # Introduction (/docs/introduction) Introduction to Better Auth…”
   • [probe] “official CLI documented at https://www.better-auth.com/docs/concepts/cli”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.better-auth.com/openapi.json, https://www.better-auth.com/swagger.json, https://www.bett…”

   proof ↗⚑ flag

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

   weight 2 · round to Clerk
   Clerk✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   Better Auth~partialprobed6/10

   Better Auth's API Key plugin lets developers create and manage API keys with custom expiration, rate limiting, and refill systems, and the MCP plugin/OAuth support plus 'Auth for AI agents. MCP auth, token exchange, and agent delegation' messaging directly target scoped credentialing for agents. However, there's no explicit documentation of fine-grained scope/permission definitions per API key or agent-specific least-privilege templates, and no independent/hands-on verification of this specific agent-credential workflow. missing for 10: documented scope/permission granularity for API keys or agent tokens, worked example of issuing a least-privilege credential to an agent, independent corroboration of the agent-delegation feature working as claimed.

   • [claimed-docs] “The API Key plugin allows you to create and manage API keys for your application. It provides a way to authenticate and authorize API reques…”
   • [claimed-docs] “The API Key plugin allows you to create and manage API keys for your application.”
   • [claimed-docs] “Create, manage, and verify API keys ... Built-in rate limiting ... Custom expiration times, remaining count, and refill systems”
   • [claimed-docs] “Create, manage, and verify API keys”
   • [claimed-docs] “Auth for AI agents. MCP auth, token exchange, and agent delegation.”
   • [claimed-docs] “The **MCP** plugin lets your app act as an OAuth authorization server and protected resource for [Model Context Protocol](https://modelconte…”
   • [claimed-docs] “The MCP plugin lets your app act as an OAuth authorization server and protected resource for Model Context Protocol clients.”
   • [probe] “official MCP server documented at https://www.better-auth.com/docs/plugins/mcp”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Clerk
   Clerk✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Better Auth~partialprobed6/10

   Better Auth ships an official TypeScript SDK (the `better-auth` package and `authClient`), well documented with framework integrations across 20+ frameworks, plus a hosted MCP server for AI-agent-assisted setup/doc search — all of which support AI-native/agentic building. However, community feedback notes the client library is JS-only with no documented path for building SDKs in other languages, limiting broader AI-native/cross-platform SDK usage. Missing for 10: multi-language official SDKs, first-party API reference (OpenAPI probe 404), independent verification of agent-driven SDK usage beyond docs.

   • [claimed-docs] “Next.js, Nuxt, SvelteKit, Astro, Hono, and 20+ more.”
   • [claimed-docs] “import { betterAuth } from "better-auth"; export const auth = betterAuth({ //... });”
   • [claimed-docs] “No dashboard clicks. Your auth lives in code version controlled, type-safe, and reviewable in PRs.”
   • [claimed-docs] “Better Auth hosts a **remote MCP server** that exposes documentation search, examples, and setup help to any MCP-capable client (Cursor, Cod…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.better-auth.com/openapi.json, https://www.better-auth.com/swagger.json, https://www.bett…”
   • [community] “I'd love to use Better-Auth in an iOS app but the client library is all JS - there is virtually no documentation on how to write your own cl…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Clerk
   Clerk✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   Better Auth—none0/10

   No evidence of any webhook subscription feature in Better Auth's docs (rate limiting, sessions, MCP, plugins, etc. are covered, but no webhook/event subscription mechanism is mentioned anywhere in the pack).

   ⚑ flag

Agentic features

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

   weight 3 · round drawn
   Clerk—none0/10

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

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

   proof ↗⚑ flag

   Better Auth—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

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

   weight 2 · round to Clerk
   Clerk~partialprobed5/10

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

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

   proof ↗⚑ flag

   Better Auth~partialprobed4/10

   Better Auth hosts a remote MCP server (better-auth-docs-18/32/43/59, probe-4) that lets MCP-capable AI clients (Cursor, Claude Code, etc.) query documentation, examples, and setup help in natural language, giving AI-native users a way to 'operate' parts of the developer workflow conversationally. However, this only covers doc search/setup guidance, not actual operation of the auth product itself (e.g., managing users, configuring providers, running admin actions) via natural-language commands — that still requires writing code/CLI commands. Missing for 10: evidence of NL-driven execution of real auth operations (user management, config changes) rather than just documentation assistance, and independent confirmation of the MCP server's usefulness beyond vendor docs.

   • [claimed-docs] “Better Auth hosts a remote MCP server that exposes documentation search, examples, and setup help to any MCP-capable client (Cursor, Codex, …”
   • [claimed-docs] “Better Auth hosts a remote MCP server that exposes documentation search, examples, and setup help”
   • [claimed-docs] “Better Auth hosts a remote MCP server that exposes documentation search, examples, and setup help to any MCP-capable client”
   • [claimed-docs] “Better Auth hosts a **remote MCP server** that exposes documentation search, examples, and setup help to any MCP-capable client (Cursor, Cod…”
   • [probe] “official MCP server documented at https://www.better-auth.com/docs/plugins/mcp”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   Clerk—none0/10

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

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

   proof ↗⚑ flag

   Better Auth—none0/10

   The evidence pack shows only static markdown documentation with code snippets, and a direct probe for an OpenAPI/interactive API reference (Swagger, openapi.json, etc.) found all candidate paths returning 404, indicating no interactive, runnable API reference is exposed.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.better-auth.com/openapi.json, https://www.better-auth.com/swagger.json, https://www.bett…”

   proof ↗⚑ flag

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

   weight 2 · round to Clerk
   Clerk✓fullprobed9/10

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

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

   proof ↗⚑ flag

   Better Auth—none0/10

   The evidence pack shows an explicit probe for OpenAPI/swagger spec endpoints that all returned 404, and no documentation in the pack references an OpenAPI/machine-readable spec output for Better Auth's API surface. While Better Auth exposes many auth endpoints, there's no evidence of a downloadable machine-readable spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.better-auth.com/openapi.json, https://www.better-auth.com/swagger.json, https://www.bett…”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Clerk—none0/10

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

   ⚑ flag

   Better Auth—none0/10

   Better Auth's docs show it is self-hosted with your own database (SQLite/Postgres/MySQL) and no explicit sandbox/test-mode environment, test API keys, or documented way to isolate test traffic from production data is mentioned anywhere in the evidence pack. While a developer could manually stand up a separate database, there is no first-party 'sandbox environment' feature, staging mode, or test-data isolation guidance cited. Missing for 10: documented sandbox/staging environment, test API keys or test mode, guidance on isolating test data from production.

   • [claimed-docs] “Better Auth requires a database to store user data. You can easily configure Better Auth to use SQLite, PostgreSQL, or MySQL, and more!”
   • [claimed-docs] “You can easily configure Better Auth to use SQLite, PostgreSQL, or MySQL, and more!”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Clerk—none0/10

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

   ⚑ flag

   Better Auth—none0/10

   The evidence pack contains no mention of semantic versioning, API stability guarantees, or a documented deprecation policy for Better Auth's SDK/API; the only related probe (openapi.json/swagger.json) returned 404s, and no changelog or versioning docs are cited. missing for 10: versioning policy documentation, deprecation/changelog process, evidence of API stability guarantees for AI/agent consumers.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.better-auth.com/openapi.json, https://www.better-auth.com/swagger.json, https://www.bett…”

   proof ↗⚑ flag

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

   weight 2 · round to Clerk
   Clerk~partialclaimed4/10

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

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

   proof ↗⚑ flag

   Better Auth—none0/10

   The evidence describes admin, organization, and API-key plugins that manage individual users/keys/roles, but nowhere documents batch/bulk endpoints (e.g., bulk user import, bulk revoke, bulk key issuance) that an AI-native user could invoke in one call. Bulk operations are a plausible axis for an auth admin API, but no evidence supports it.

   • [claimed-docs] “It allows administrators to perform various operations such as creating users, managing user roles, banning/unbanning users, impersonating u…”
   • [claimed-docs] “The API Key plugin allows you to create and manage API keys for your application. It provides a way to authenticate and authorize API reques…”
   • [claimed-docs] “The API Key plugin allows you to create and manage API keys for your application.”
   • [claimed-docs] “such as creating users, managing user roles, banning/unbanning users, impersonating users, and more.”

   proof ↗⚑ flag

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

   weight 3 · round to Clerk
   Clerk~partialclaimed4/10

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

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

   proof ↗⚑ flag

   Better Auth—none0/10

   The evidence pack shows no documentation of an event-hook or rules-trigger system (e.g., 'on sign-up run X', webhooks, or automation rules) — only static configuration options like rate limits and session expiration. Auth frameworks commonly support such hooks, so the axis applies, but no evidence of it exists here.

   ⚑ flag

Deployment

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

   weight 2 · round to Better Auth
   Clerk—none0/10

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

   ⚑ flag

   Better Auth✓fullcommunity9/10

   Better Auth is a self-hosted, open-source TypeScript library installed directly into your app (npm install), storing all user data in a database you own and control (SQLite/PostgreSQL/MySQL/etc.), with no vendor dashboard or hosted service dependency — confirmed by docs and community reports of full data ownership ('You get all of your auth data in your own db', 'I own all the data', 'adding an extra user column is just a Postgres column'). Missing for 10: no independent security-audit/compliance documentation confirming enterprise self-hosting patterns beyond community anecdotes, and comm-17 flags speculative concern about future closed-source cloud dependency (not a current contradiction).

   • [claimed-docs] “npm install better-auth”
   • [claimed-docs] “You can easily configure Better Auth to use SQLite, PostgreSQL, or MySQL, and more!”
   • [claimed-docs] “Better Auth requires a database to store user data. You can easily configure Better Auth to use SQLite, PostgreSQL, or MySQL, and more!”
   • [community] “You get all of your auth data in your own db in 1 cli command. You are not tied to any db provider. Hundreds of auth features like OAuth pro…”
   • [community] “Setting up Auth with anonymous users upgraded to real accounts, organizations, multi-tenant capabilities, various sign-in options - haven't …”
   • [community] “One reason I prefer Better Auth is I retain flexibility designing the rest of the system - adding an extra user column is just a Postgres co…”
   • [community] “Can Vercel give any assurance they won't add a reliance on their closed-source cloud offering for the package, especially given their owners…”
   • [claimed-docs] “No dashboard clicks. Your auth lives in code version controlled, type-safe, and reviewable in PRs.”

   proof ↗⚑ flag

Sso

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

   weight 3 · round to Clerk
   Clerk✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   Better Auth✓fullclaimed6/10

   Better Auth's official SSO plugin explicitly supports OIDC, OAuth2, and SAML 2.0, which are the protocols used by Okta, Entra, and Google Workspace for workforce SSO (better-auth-docs-14). However, there is no documentation or community evidence naming specific IdP integrations (Okta/Entra/Google Workspace) or showing a hands-on enterprise SSO setup. missing for 10: named provider configuration guides (Okta/Entra/Google Workspace specifics), admin/dashboard SSO management, and independent/hands-on validation of the SSO plugin in production.

   • [claimed-docs] “This plugin supports OpenID Connect (OIDC), OAuth2 providers, and SAML 2.0.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Clerk—none0/10

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

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

   proof ↗⚑ flag

   Better Auth—none0/10

   Evidence shows SSO/SAML plugin, organization plugin, and admin plugin, but no mention of SCIM protocol support for syncing users/groups from IdPs or automated deprovisioning propagation. No SCIM endpoint, provisioning API, or directory sync capability is documented anywhere in the pack.

   ⚑ flag

Audit

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

   weight 2 · round to Clerk
   Clerk!disputedcontradicted3/10

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

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

   proof ↗⚑ flag

   Better Auth—none0/10

   The evidence pack shows only a marketing-page activity feed mockup listing generic events (session created, token revoked, 2FA enabled) with no documentation of tamper-evident logging, hashing/integrity guarantees, or any SIEM export/streaming/webhook mechanism for audit or admin activity. No dedicated audit-log feature, webhook events reference, or SIEM integration docs appear anywhere in the pack.

   • [claimed-docs] “10:50 AMJohncreated a session 10:48 AMSarahupdated profile 10:45 AMAlexjoined organization 10:42 AMEmmarevoked token 10:38 AMMikeenabled…”

   proof ↗⚑ flag

Webhooks

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

   weight 2 · round to Clerk
   Clerk✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   Better Auth—none0/10

   No evidence pack item documents a webhook system or event-stream API for auth events; the only related item (docs-63) shows a UI activity-feed mockup, not a subscribable webhook/event mechanism for external systems to sync with.

   • [claimed-docs] “10:50 AMJohncreated a session 10:48 AMSarahupdated profile 10:45 AMAlexjoined organization 10:42 AMEmmarevoked token 10:38 AMMikeenabled…”

   proof ↗⚑ flag

Frameworks

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

   weight 3 · round to Clerk
   Clerk~partialcommunity6/10

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

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

   proof ↗⚑ flag

   Better Auth~partialprobed5/10

   Better Auth is confirmed framework-agnostic with support for Next.js, Nuxt, SvelteKit, Astro, Hono and 20+ frameworks, and server-side session verification via auth.api methods, but the evidence pack lacks any explicit mention of edge-runtime middleware, Next.js middleware helpers, or edge-verified session checks. missing for 10: explicit Next.js middleware/edge-runtime route-protection docs, evidence of edge-compatible session verification, independent hands-on confirmation of edge middleware usage.

   • [claimed-docs] “Next.js, Nuxt, SvelteKit, Astro, Hono, and 20+ more.”
   • [claimed-docs] “To authenticate a user on the server, you can use the auth.api methods.”
   • [claimed-docs] “import { betterAuth } from "better-auth"; export const auth = betterAuth({ //... });”
   • [probe] “PROBE docs-md: HTTP 200 at https://www.better-auth.com/docs/introduction.md # Introduction (/docs/introduction) Introduction to Better Auth…”

   proof ↗⚑ flag

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

   weight 2 · round to Clerk
   Clerk✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   Better Auth—none0/10

   Better Auth's evidence shows only client SDK methods (authClient.signUp.email, etc.) and API-level primitives (session, 2FA, organization plugins) — there is no mention of prebuilt UI components or hosted sign-in/sign-up/profile pages anywhere in the docs pack. Community commentary explicitly contrasts it with Clerk as 'more hackable,' implying it is headless rather than shipping ready-made UI.

   • [claimed-docs] “const { data, error } = await authClient.signUp.email({ email, password, name, image, callbackURL: "/dashboard" }”
   • [claimed-docs] “const { data, error } = await authClient.signUp.email({ email, password, name, image”
   • [claimed-docs] “To sign up a user you need to call the client method `signUp.email`”
   • [community] “Better auth is great! I love how it's way more hackable than something like Clerk. We were able to add a plugin to allow auth via iframe pos…”

   proof ↗⚑ flag

Hardening

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

   weight 1 · round to Clerk
   Clerk✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   Better Auth~partialclaimed6/10

   Better Auth documents a built-in rate limiter with customizable rules, including strict per-path limits like 3 requests/10s on /sign-in/email, which directly mitigates brute-force and credential-stuffing attacks, plus secure password hashing (scrypt) and 2FA/backup codes as additional layers. However, there is no evidence of dedicated bot/CAPTCHA detection, IP reputation, breached-password checks, or anomaly-based bot mitigation beyond simple rate limiting. missing for 10: explicit bot detection/CAPTCHA integration, credential-stuffing-specific defenses (e.g., breached password screening), independent security audit or hands-on validation of these protections.

   • [claimed-docs] “You can easily customize these settings by passing the rateLimit object to the betterAuth function.”
   • [claimed-docs] “Better Auth includes a built-in rate limiter to help manage traffic and prevent abuse.”
   • [claimed-docs] “rateLimit: { window: 10, max: 100 }”
   • [claimed-docs] “Better Auth provides custom rules for specific paths. For example: * `/sign-in/email`: Is limited to 3 requests within 10 seconds.”
   • [claimed-docs] “Better Auth uses the `scrypt` algorithm to hash passwords by default.”
   • [claimed-docs] “Two-Factor Authentication (2FA) adds an extra security step when users log in.”
   • [claimed-docs] “Generating backup codes for account recovery”

   proof ↗⚑ flag

Mfa

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

   weight 3 · round to Clerk
   Clerk✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   Better Auth~partialclaimed7/10

   Better Auth's 2FA plugin documents TOTP authenticator app setup, backup code generation, and enabling/disabling 2FA with trusted device management (better-auth-docs-39, -40, -48, -53, -69), directly satisfying the core MFA requirement. However, the evidence pack contains no explicit documentation of step-up enforcement (e.g., requiring re-verification for sensitive actions or conditional MFA triggers) beyond basic enable/disable. Missing for 10: explicit step-up/conditional enforcement policy documentation, independent hands-on confirmation of TOTP+backup-code flow working end-to-end.

   • [claimed-docs] “Two-Factor Authentication (2FA) adds an extra security step when users log in... Generating backup codes for account recovery”
   • [claimed-docs] “totp (default) sets up an authenticator app... otp enables email/SMS-based codes immediately”
   • [claimed-docs] “Generating backup codes for account recovery”
   • [claimed-docs] “To enable two-factor authentication, call twoFactor.enable.”
   • [claimed-docs] “Additional features include: * Generating backup codes for account recovery * Enabling/disabling 2FA * Managing trusted devices”
   • [claimed-docs] “Managing trusted devices”

   proof ↗⚑ flag

Passwordless

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

   weight 2 · round to Better Auth
   Clerk~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Better Auth✓fullcommunity8/10

   Better Auth ships a passkey plugin (WebAuthn) referenced in docs/site (better-auth-docs-19, better-auth-docs-44) and independently corroborated by a hands-on community comparison noting the passkey plugin requires just 7 lines of server code (better-auth-comm-14). Magic links and passwordless are also listed as first-class supported methods (better-auth-docs-44 'Passkeys, magic links, API keys, JWTs, and more'). Missing for 10: dedicated docs page excerpt for magic-link/email-OTP plugin configuration details and independent hands-on verification of magic link/email OTP specifically (only passkeys got hands-on confirmation).

   • [claimed-docs] “plugins: [ twoFactor(), passkey(), organization(), ]”
   • [claimed-docs] “Passkeys, magic links, API keys, JWTs, and more.”
   • [community] “Contrast Microsoft's lengthy passkey guide for .NET Core to better-auth's passkey plugin, which is 7 lines of server code total with virtual…”

   proof ↗⚑ flag

Flows

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

   weight 3 · round to Better Auth
   Clerk~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Better Auth✓fullclaimed7/10

   Better Auth documents built-in social OAuth (Google, GitHub, Apple, Discord), an SSO plugin supporting OIDC/OAuth2/SAML, a JWT plugin with JWKS, and even the Device Authorization Grant (RFC 8628) — all abstracting protocol details behind config/plugins rather than requiring manual implementation. However, the evidence pack never explicitly calls out PKCE handling or refresh-token rotation mechanics for the authorization code flow, so full protocol-detail coverage isn't directly confirmed. missing for 10: explicit PKCE flow documentation, explicit refresh-token lifecycle docs, independent hands-on test of OAuth flow correctness.

   • [claimed-docs] “Better Auth supports multiple social providers, including Google, GitHub, Apple, Discord, and more.”
   • [claimed-docs] “This plugin supports OpenID Connect (OIDC), OAuth2 providers, and SAML 2.0.”
   • [claimed-docs] “The JWT plugin provides endpoints to retrieve a JWT token and a JWKS endpoint to verify the token.”
   • [claimed-docs] “The Device Authorization plugin implements the code issuance and approval flow from the OAuth 2.0 Device Authorization Grant (RFC 8628) for …”
   • [claimed-docs] “The Device Authorization plugin implements the code issuance and approval flow from the OAuth 2.0 Device Authorization Grant (RFC 8628) for …”

   proof ↗⚑ flag

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

   weight 2 · round to Better Auth
   Clerk~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Better Auth✓fullcommunity8/10

   Docs and marketing pages explicitly state built-in support for social providers (Google, GitHub, Apple, Discord, and more) configured via a `socialProviders` config block, plus a dedicated SSO plugin supporting OIDC, OAuth2, and SAML 2.0 for enterprise IdPs, all achievable through configuration rather than custom code. Community testimonials corroborate that OAuth providers (Google, Apple, GitHub) work out-of-the-box with minimal code. Missing for 10: an exhaustive named list of all supported providers, and independent hands-on verification of configuring a less-common/niche provider beyond the commonly cited ones.

   • [claimed-docs] “Better Auth supports multiple social providers, including Google, GitHub, Apple, Discord, and more.”
   • [claimed-docs] “**Social provider (Google, GitHub, Apple, and more)**”
   • [claimed-docs] “Social provider (Google, GitHub, Apple, and more)”
   • [claimed-docs] “This plugin supports OpenID Connect (OIDC), OAuth2 providers, and SAML 2.0.”
   • [claimed-docs] “Single Sign-On (SSO) allows users to authenticate with multiple applications using a single set of credentials. This plugin supports OpenID …”
   • [claimed-docs] “Enterprise ready. SSO, SAML 2.0, SCIM, and directory sync.”
   • [community] “You get all of your auth data in your own db in 1 cli command. You are not tied to any db provider. Hundreds of auth features like OAuth pro…”

   proof ↗⚑ flag

Provider

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

   weight 2 · round to Better Auth
   Clerk~partialclaimed5/10

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

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

   proof ↗⚑ flag

   Better Auth✓fullprobed7/10

   The docs explicitly state the MCP plugin lets an app 'act as an OAuth authorization server and protected resource for... clients' (issuing tokens), and the Device Authorization plugin implements RFC 8628 for third-party/limited-input clients — both directly support turning the app into an OAuth provider. However, evidence is scoped mainly to MCP-client and device-flow use cases rather than a generic, broadly-documented 'OAuth provider for any third-party app' plugin with client registration/management. Missing for 10: explicit generic OAuth Provider plugin docs (client registration, scopes, consent screen) for arbitrary third-party apps beyond MCP/device flows, and independent/hands-on confirmation of this specific capability.

   • [claimed-docs] “The MCP plugin lets your app act as an OAuth authorization server and protected resource for Model Context Protocol clients.”
   • [claimed-docs] “The **MCP** plugin lets your app act as an OAuth authorization server and protected resource for [Model Context Protocol](https://modelconte…”
   • [claimed-docs] “The Device Authorization plugin implements the code issuance and approval flow from the OAuth 2.0 Device Authorization Grant (RFC 8628) for …”
   • [claimed-docs] “The Device Authorization plugin implements the code issuance and approval flow from the OAuth 2.0 Device Authorization Grant ([RFC 8628](htt…”
   • [probe] “official MCP server documented at https://www.better-auth.com/docs/plugins/mcp”

   proof ↗⚑ flag

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

   weight 2 · round to Better Auth
   Clerk~partialprobed6/10

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

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

   proof ↗⚑ flag

   Better Auth✓fullprobed7/10

   Better Auth is explicitly code/API-first — 'No dashboard clicks. Your auth lives in code' — and virtually every capability (signup, 2FA, sessions, admin operations like banning/impersonating, organization management, API keys) is exposed via auth.api server methods or the authClient SDK rather than a separate GUI, meaning there is no UI-only feature gap by design. missing for 10: no explicit UI product to compare against for full parity claims, no OpenAPI spec discovered (probe found 404s) to formally enumerate API surface, and no independent hands-on confirmation that admin/org UI-equivalent actions are 100% API-reachable.

   • [claimed-docs] “No dashboard clicks. Your auth lives in code version controlled, type-safe, and reviewable in PRs.”
   • [claimed-docs] “To authenticate a user on the server, you can use the auth.api methods.”
   • [claimed-docs] “It allows administrators to perform various operations such as creating users, managing user roles, banning/unbanning users, impersonating u…”
   • [claimed-docs] “The organization plugin allows you to manage your organization's members and teams. Organizations simplifies user access and permissions man…”
   • [claimed-docs] “The API Key plugin allows you to create and manage API keys for your application. It provides a way to authenticate and authorize API reques…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.better-auth.com/openapi.json, https://www.better-auth.com/swagger.json, https://www.bett…”

   proof ↗⚑ flag

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

   weight 3 · round to Better Auth
   Clerk—none0/10

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

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

   proof ↗⚑ flag

   Better Auth~partialcommunity6/10

   Better Auth stores all auth data in your own standard SQL database (SQLite/Postgres/MySQL) rather than a vendor silo, and community reviewers explicitly praise that 'you get all of your auth data in your own db' and 'you are not tied to any db provider,' which inherently satisfies data-ownership/exit concerns. However there is no dedicated documented export feature, standard open export format (e.g., CSV/JSON dump tool), or migration-out guide beyond the reverse (Auth0-to-BetterAuth) migration guide. Missing for 10: explicit data-export tooling/documentation, a formal 'leave the platform' guide, and independent verification of export completeness.

   • [claimed-docs] “Better Auth requires a database to store user data. You can easily configure Better Auth to use SQLite, PostgreSQL, or MySQL, and more!”
   • [community] “You get all of your auth data in your own db in 1 cli command. You are not tied to any db provider. Hundreds of auth features like OAuth pro…”
   • [community] “Setting up Auth with anonymous users upgraded to real accounts, organizations, multi-tenant capabilities, various sign-in options - haven't …”
   • [community] “One reason I prefer Better Auth is I retain flexibility designing the rest of the system - adding an extra user column is just a Postgres co…”

   proof ↗⚑ flag

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

   weight 2 · round to Better Auth
   Clerk~partialclaimed4/10

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

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

   proof ↗⚑ flag

   Better Auth✓fullcommunity7/10

   Community evidence repeatedly confirms Better Auth is open source and self-hostable (own DB, no vendor lock-in), and users treat it as a codebase they can read/extend (e.g., adding custom plugins). However, no direct citation of the specific license (e.g., MIT) or a link to the source repository/license file is provided. Missing for 10: explicit license name confirmation, direct link to GitHub repo/license file.

   • [community] “You get all of your auth data in your own db in 1 cli command. You are not tied to any db provider. Hundreds of auth features like OAuth pro…”
   • [community] “Setting up Auth with anonymous users upgraded to real accounts, organizations, multi-tenant capabilities, various sign-in options - haven't …”
   • [community] “We have been using better-auth (open source) for a while, it was immediately a better experience compared to existing TypeScript auth librar…”
   • [community] “One reason I prefer Better Auth is I retain flexibility designing the rest of the system - adding an extra user column is just a Postgres co…”
   • [claimed-docs] “No dashboard clicks. Your auth lives in code version controlled, type-safe, and reviewable in PRs.”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Better Auth
   Clerk—none0/10

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

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

   proof ↗⚑ flag

   Better Auth✓fullcommunity8/10

   Better Auth is an open-source, code-first library installed via npm into your own codebase, storing all data in your own SQLite/PostgreSQL/MySQL database with no vendor lock-in ('You are not tied to any db provider', 'Your auth lives in code version controlled'), which community reviews confirm as a self-hosting advantage. missing for 10: no explicit dedicated 'self-hosting guide' or deployment/infra doc, and no independent audit of production self-hosted deployments beyond community testimonials.

   • [claimed-docs] “npm install better-auth”
   • [claimed-docs] “You can easily configure Better Auth to use SQLite, PostgreSQL, or MySQL, and more!”
   • [claimed-docs] “Better Auth requires a database to store user data. You can easily configure Better Auth to use SQLite, PostgreSQL, or MySQL, and more!”
   • [claimed-docs] “No dashboard clicks. Your auth lives in code version controlled, type-safe, and reviewable in PRs.”
   • [community] “You get all of your auth data in your own db in 1 cli command. You are not tied to any db provider. Hundreds of auth features like OAuth pro…”
   • [community] “Setting up Auth with anonymous users upgraded to real accounts, organizations, multi-tenant capabilities, various sign-in options - haven't …”
   • [community] “One reason I prefer Better Auth is I retain flexibility designing the rest of the system - adding an extra user column is just a Postgres co…”

   proof ↗⚑ flag

Orgs

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

   weight 2 · round drawn
   Clerk~partialclaimed5/10

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

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

   proof ↗⚑ flag

   Better Auth~partialclaimed5/10

   Better Auth ships an organization plugin for multi-tenant orgs (teams/roles) and a separate SSO plugin supporting OIDC/OAuth2/SAML 2.0, plus a marketing claim of 'SSO, SAML 2.0, SCIM, and directory sync' for enterprise readiness — together implying per-org SSO with provisioning is achievable. However, the evidence never explicitly documents binding an SSO connection to a specific organization, domain verification/ownership checks, or just-in-time (JIT) user provisioning on SSO login. Missing for 10: explicit docs on per-organization SSO connection scoping, domain verification workflow, and JIT provisioning behavior on first SSO login.

   • [claimed-docs] “The organization plugin allows you to manage your organization's members and teams. Organizations simplifies user access and permissions man…”
   • [claimed-docs] “This plugin supports OpenID Connect (OIDC), OAuth2 providers, and SAML 2.0.”
   • [claimed-docs] “Single Sign-On (SSO) allows users to authenticate with multiple applications using a single set of credentials. This plugin supports OpenID …”
   • [claimed-docs] “Enterprise ready. SSO, SAML 2.0, SCIM, and directory sync.”
   • [claimed-docs] “Multi-tenancy built in. Teams, roles, invitations, and access control.”

   proof ↗⚑ flag

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

   weight 3 · round to Clerk
   Clerk✓fullcommunity8/10

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

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

   proof ↗⚑ flag

   Better Auth~partialcommunity6/10

   The organization plugin explicitly supports members, teams, roles/permissions, and multi-tenancy (docs-13, docs-26, docs-54, docs-71, docs-75), and community reports confirm real-world use of organizations/multi-tenant setups (better-auth-comm-3). However, invitation flows are asserted only implicitly via 'members and teams' management and marketing copy ('Multi-tenancy built in... invitations') without dedicated docs excerpts detailing the invitation API/flow itself. missing for 10: explicit documentation of invitation creation/acceptance endpoints, role-based permission examples, and independent hands-on verification of the invitation flow specifically.

   • [claimed-docs] “The organization plugin allows you to manage your organization's members and teams. Organizations simplifies user access and permissions man…”
   • [claimed-docs] “The organization plugin allows you to manage your organization's members and teams.”
   • [claimed-docs] “Organizations simplifies user access and permissions management. Assign roles and permissions to streamline project management, team coordin…”
   • [claimed-docs] “Assign roles and permissions to streamline project management, team coordination, and partnerships.”
   • [claimed-docs] “Multi-tenancy built in. Teams, roles, invitations, and access control.”
   • [community] “Setting up Auth with anonymous users upgraded to real accounts, organizations, multi-tenant capabilities, various sign-in options - haven't …”

   proof ↗⚑ flag

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

   weight 2 · round to Better Auth
   Clerk—none0/10

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

   ⚑ flag

   Better Auth~partialcommunity5/10

   Better Auth is a self-hosted library where you bring your own database (SQLite/PostgreSQL/MySQL/etc.), and community comments confirm 'you own all the data' and it's 'not tied to any db provider,' which implicitly lets a developer choose the physical location/region of their data store. However, there is no explicit region/residency feature, configuration flag, or documentation addressing data-residency requirements directly. missing for 10: explicit residency/region controls or docs, compliance statements (GDPR/data-locality), multi-region deployment guidance.

   • [claimed-docs] “Better Auth requires a database to store user data. You can easily configure Better Auth to use SQLite, PostgreSQL, or MySQL, and more!”
   • [community] “You get all of your auth data in your own db in 1 cli command. You are not tied to any db provider. Hundreds of auth features like OAuth pro…”
   • [community] “Setting up Auth with anonymous users upgraded to real accounts, organizations, multi-tenant capabilities, various sign-in options - haven't …”
   • [community] “One reason I prefer Better Auth is I retain flexibility designing the rest of the system - adding an extra user column is just a Postgres co…”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round to Better Auth
   Clerk—none0/10

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

   ⚑ flag

   Better Auth~partialcommunity4/10

   Better Auth stores auth data in the developer's own database (SQLite/Postgres/MySQL) rather than a vendor-hosted store, and community comments emphasize 'I own all the data' and full schema control, plus docs show users can revoke their own sessions and rotate secrets — giving some data-deletion control. However there is no explicit documentation of a data retention policy, account/user deletion API, or GDPR-style erasure workflow in the evidence pack. Missing for 10: explicit user/account deletion API docs, data retention policy statements, and compliance (e.g. GDPR/CCPA erasure) documentation.

   • [claimed-docs] “A logged in user can also revoke their own sessions to log out from different devices or browsers.”
   • [claimed-docs] “Better Auth supports non-destructive rotation of `BETTER_AUTH_SECRET`... No database migrations or downtime are required.”
   • [community] “You get all of your auth data in your own db in 1 cli command. You are not tied to any db provider. Hundreds of auth features like OAuth pro…”
   • [community] “Setting up Auth with anonymous users upgraded to real accounts, organizations, multi-tenant capabilities, various sign-in options - haven't …”
   • [community] “One reason I prefer Better Auth is I retain flexibility designing the rest of the system - adding an extra user column is just a Postgres co…”

   proof ↗⚑ flag

3. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Clerk—none0/10

   No evidence in the pack mentions telemetry, usage tracking, analytics data collection, or an opt-out mechanism for Clerk's own product telemetry; this is an applicable axis (Clerk is a SaaS/dev-tool product that could plausibly collect usage telemetry) but nothing addresses it.

   ⚑ flag

   Better Auth—none0/10

   The evidence pack contains no mention of telemetry, analytics collection, or any opt-out mechanism for Better Auth's CLI or library; while telemetry opt-out is a fair question for a dev tool/CLI like this, no documentation or community evidence addresses it.

   ⚑ flag

Rbac

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

   weight 1 · round to Better Auth
   Clerk~partialcommunity3/10

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

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

   proof ↗⚑ flag

   Better Auth~partialclaimed4/10

   Better Auth's organization plugin lets teams assign roles and permissions per-org/team, and the admin plugin manages user roles, which provides some resource-scoped (team/org) access control beyond a single global role — but this is still fundamentally RBAC, not a documented policy- or relationship-based (ReBAC/ABAC) authorization engine with custom resource-level rules or relationship graphs. missing for 10: no evidence of a policy engine, attribute-based rules, or relationship-based (Zanzibar-style) permission model; no docs describing per-resource ACLs beyond org/team roles.

   • [claimed-docs] “The organization plugin allows you to manage your organization's members and teams. Organizations simplifies user access and permissions man…”
   • [claimed-docs] “Organizations simplifies user access and permissions management. Assign roles and permissions to streamline project management, team coordin…”
   • [claimed-docs] “Assign roles and permissions to streamline project management, team coordination, and partnerships.”
   • [claimed-docs] “It allows administrators to perform various operations such as creating users, managing user roles, banning/unbanning users, impersonating u…”
   • [claimed-docs] “such as creating users, managing user roles, banning/unbanning users, impersonating users, and more.”
   • [claimed-docs] “Multi-tenancy built in. Teams, roles, invitations, and access control.”

   proof ↗⚑ flag

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

   weight 3 · round to Clerk
   Clerk~partialcommunity7/10

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

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

   proof ↗⚑ flag

   Better Auth~partialclaimed6/10

   Better Auth's organization and admin plugins support assigning roles/permissions and managing access control (better-auth-docs-13, better-auth-docs-54, better-auth-docs-71, better-auth-docs-15, better-auth-docs-75), and the JWT plugin can issue tokens for verification (better-auth-docs-7). However, there is no explicit documentation showing that custom roles/permissions are automatically embedded into session/JWT claims for authorization checks — the JWT and role/permission systems appear documented separately rather than as an integrated enforcement pipeline. missing for 10: explicit docs on custom permission schemas beyond built-in roles, evidence that role/permission data is serialized into JWT/session claims, and independent/hands-on confirmation of authorization checks using token claims.

   • [claimed-docs] “The organization plugin allows you to manage your organization's members and teams. Organizations simplifies user access and permissions man…”
   • [claimed-docs] “Organizations simplifies user access and permissions management. Assign roles and permissions to streamline project management, team coordin…”
   • [claimed-docs] “Assign roles and permissions to streamline project management, team coordination, and partnerships.”
   • [claimed-docs] “It allows administrators to perform various operations such as creating users, managing user roles, banning/unbanning users, impersonating u…”
   • [claimed-docs] “managing user roles, banning/unbanning users, impersonating users, and more.”
   • [claimed-docs] “The JWT plugin provides endpoints to retrieve a JWT token and a JWKS endpoint to verify the token.”
   • [claimed-docs] “Multi-tenancy built in. Teams, roles, invitations, and access control.”

   proof ↗⚑ flag

Sessions

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

   weight 1 · round to Clerk
   Clerk~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Better Auth~partialclaimed5/10

   Docs confirm users can revoke their own sessions to log out of other devices/browsers, and session config (expiry, updateAge) is documented, but there's no evidence of a UI/API for listing all active sessions with device metadata, nor for admin-side viewing/revoking of a specific user's sessions (admin plugin covers banning/impersonation, not session listing/revocation). missing for 10: documented endpoint/UI for listing sessions with device info, admin-initiated session revocation for other users, independent/hands-on confirmation of multi-device session management.

   • [claimed-docs] “A logged in user can also revoke their own sessions to log out from different devices or browsers.”
   • [claimed-docs] “session: { expiresIn: 60 * 60 * 24 * 7, updateAge: 60 * 60 * 24 }”
   • [claimed-docs] “The session expires after 7 days by default. But whenever the session is used and the updateAge is reached, the session expiration is update…”
   • [claimed-docs] “It allows administrators to perform various operations such as creating users, managing user roles, banning/unbanning users, impersonating u…”

   proof ↗⚑ flag

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

   weight 3 · round to Better Auth
   Clerk!disputedcontradicted5/10

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

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

   proof ↗⚑ flag

   Better Auth✓fullclaimed8/10

   Docs show configurable session expiry and rolling refresh via `session: { expiresIn, updateAge }`, and explicit server-side revocation of user sessions (self-revocation for logging out compromised sessions on other devices), plus admin plugin capable of banning/impersonating users tied to session control. Missing for 10: no explicit documentation of an admin-initiated forced revocation of another user's specific session (only self-revocation and broader ban/impersonate flows are shown), and no independent hands-on test confirming revocation propagation latency.

   • [claimed-docs] “session: { expiresIn: 60 * 60 * 24 * 7, updateAge: 60 * 60 * 24 }”
   • [claimed-docs] “The session expires after 7 days by default. But whenever the session is used and the updateAge is reached, the session expiration is update…”
   • [claimed-docs] “A logged in user can also revoke their own sessions to log out from different devices or browsers.”
   • [claimed-docs] “It allows administrators to perform various operations such as creating users, managing user roles, banning/unbanning users, impersonating u…”
   • [claimed-docs] “managing user roles, banning/unbanning users, impersonating users, and more.”

   proof ↗⚑ flag

Migration

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

   weight 2 · round to Better Auth
   Clerk~partialclaimed4/10

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

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

   proof ↗⚑ flag

   Better Auth~partialcommunity5/10

   Better Auth documents a migration guide specifically for moving from Auth0 that explicitly covers importing email/password users with proper password hash handling, plus social accounts and 2FA data (docs-8, docs-30, docs-41). However, there is no evidence of a generic bulk-import tool for arbitrary user stores, nor any documented export functionality to avoid lock-in — the 'own your data in your own DB' claim is community sentiment (better-auth-comm-1) rather than a documented export feature. missing for 10: a generic (non-Auth0-specific) bulk import mechanism, explicit export/dump tooling, and independent confirmation that migrated password hashes work end-to-end.

   • [claimed-docs] “we'll walk through the steps to migrate a project from Auth0 to Better Auth — including email/password with proper hashing, social/external …”
   • [claimed-docs] “we'll walk through the steps to migrate a project from Auth0 to Better Auth”
   • [claimed-docs] “we'll walk through the steps to migrate a project from Auth0 to Better Auth including email/password with proper hashing, social/external ac…”
   • [community] “You get all of your auth data in your own db in 1 cli command. You are not tied to any db provider. Hundreds of auth features like OAuth pro…”

   proof ↗⚑ flag

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

   weight 1 · round to Better Auth
   Clerk~partialclaimed5/10

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

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

   proof ↗⚑ flag

   Better Auth~partialclaimed6/10

   Better Auth publishes a vendor-maintained Auth0 migration guide covering email/password migration 'with proper hashing,' social accounts, and 2FA, which implies preserving existing password hashes rather than forcing resets [better-auth-docs-8, better-auth-docs-30, better-auth-docs-41]. However, this guide is limited to Auth0 specifically — there's no evidence of similar guides/tooling for other major competitors (Clerk, Cognito, Firebase, Okta), and no explicit statement or independent confirmation that end users won't be forced to reset passwords during migration. Missing for 10: migration guides for other competing providers, explicit no-password-reset guarantee, and independent/hands-on confirmation of a smooth Auth0 migration.

   • [claimed-docs] “we'll walk through the steps to migrate a project from Auth0 to Better Auth — including email/password with proper hashing, social/external …”
   • [claimed-docs] “we'll walk through the steps to migrate a project from Auth0 to Better Auth”
   • [claimed-docs] “we'll walk through the steps to migrate a project from Auth0 to Better Auth including email/password with proper hashing, social/external ac…”

   proof ↗⚑ flag