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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   Better Auth~partialclaimed4/10

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

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

   proof ↗⚑ flag

Device flow

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

   weight 2 · round to WorkOS
   WorkOS✓fullclaimed9/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   Better Auth✓fullprobed9/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   WorkOS~partialprobed5/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   Better Auth~partialprobed6/10

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

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

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to WorkOS
   WorkOS✓fullclaimed7/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 Better Auth
   WorkOS~partialclaimed4/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   Better Auth✓fullcommunity8/10

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

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

   proof ↗⚑ flag

Flows

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

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

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

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

   proof ↗⚑ flag

   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 drawn
   WorkOS✓fullcommunity8/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

   Better Auth✓fullcommunity8/10

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

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

   proof ↗⚑ flag

Orgs

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

   weight 2 · round drawn
   WorkOS~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

   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

Rbac

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

   weight 1 · round to WorkOS
   WorkOS~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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