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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 Auth0
   Auth0✓fullclaimed9/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 to Better Auth
   Auth0✓fullprobed7/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 Better Auth
   Auth0—none0/10

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

   ⚑ flag

   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 Auth0
   Auth0✓fullcommunity7/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 drawn
   Auth0✓fullcommunity7/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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
   Auth0~partialprobed7/10

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

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

   proof ↗⚑ flag

   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
   Auth0~partialcommunity5/10

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

   No evidence in the pack addresses telemetry/usage-tracking opt-out settings for Auth0 or its AI/MCP tooling; all documentation covers authentication, MFA, SSO, RBAC, migration, and AI-agent identity features unrelated to telemetry controls.

   ⚑ 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 Auth0
   Auth0✓fullclaimed7/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 Better Auth
   Auth0—none0/10

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

   ⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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