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

   The evidence pack documents OAuth2/OIDC flows, device authorization grant, client credentials, and fine-grained authorization services, but nowhere mentions CIBA (Client-Initiated Backchannel Authentication) or any mechanism for out-of-band human approval tied to a specific agent-initiated transaction. Device grant is a different flow (device-initiated, browser-based user authorization) rather than a backend-initiated async approval-of-transaction pattern.

   • [claimed-docs] “Server Administration Guide, "Device authorization grant": "This is used by clients running on internet-connected devices that have limited …”
   • [claimed-docs] “OIDC layers reference, "Client credentials": "Client Credentials are used when clients (applications and services) want to obtain access on …”
   • [claimed-docs] “Authorization Services guide: fine-grained, resource-level authorization — "A resource is part of the assets of an application and the organ…”

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

   Keycloak provides the underlying OAuth2/OIDC building blocks that such a flow would need — identity brokering to link user accounts with third-party IdPs (keycloak-docs-25, keycloak-docs-46, kc-supp-social-brokering), client-credentials/service-account flows for machine access (kc-supp-client-credentials), a device grant suited to limited-input clients (kc-supp-device-grant), and token introspection/revocation for short-lived token lifecycle management (keycloak-docs-52, keycloak-docs-53). However, none of the evidence documents an explicit 'token vault' or RFC 8693 token-exchange feature for retrieving/exchanging stored third-party IdP tokens on behalf of a user for downstream API calls, nor any agent-specific consent UX. Missing for 10: explicit token exchange/RFC8693 support docs, documented retrieval of brokered IdP access tokens for calling third-party APIs, and agent/tool-specific delegated-consent flow documentation.

   • [claimed-docs] “If you've enabled social login or identity brokering users can also link their accounts with additional providers to allow them to authentic…”
   • [claimed-docs] “Keycloak can also authenticate users with existing OpenID Connect or SAML 2.0 Identity Providers. Again, this is just a matter of configurin…”
   • [claimed-docs] “Keycloak site, Identity Brokering and Social Login: "Enabling login with social networks is easy to add through the admin console. It's just…”
   • [claimed-docs] “OIDC layers reference, "Client credentials": "Client Credentials are used when clients (applications and services) want to obtain access on …”
   • [claimed-docs] “Server Administration Guide, "Device authorization grant": "This is used by clients running on internet-connected devices that have limited …”
   • [claimed-docs] “The introspection endpoint is used to retrieve the active state of a token. In other words, you can use it to validate an access or refresh …”
   • [claimed-docs] “The token revocation endpoint is used to revoke tokens. Both refresh tokens and access tokens are supported by this endpoint.”

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

   Keycloak's Server Administration Guide explicitly documents the 'Device authorization grant' for clients with limited input/no browser, and the OIDC endpoints reference lists the device authorization endpoint (/protocol/openid-connect/auth/device) used to obtain a device code and user code — exactly the flow needed for CLIs/headless agents to authenticate without long-lived secrets. This is paired with client-credentials/service-account support for other machine flows, giving a complete non-interactive auth story. Missing for 10: independent/hands-on community evidence specifically validating CLI or agent use of the device flow (community citations cover other topics, not this flow).

   • [claimed-docs] “Server Administration Guide, "Device authorization grant": "This is used by clients running on internet-connected devices that have limited …”
   • [claimed-docs] “It lists endpoints and other configuration options relevant to the OpenID Connect implementation in Keycloak.”
   • [claimed-docs] “Keycloak exposes a set of endpoints that applications and services can use to authenticate and authorize their users.”

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

   Keycloak natively documents the OAuth2 client_credentials grant explicitly for service-to-service (non-user) authentication, backed by service accounts, client_id/secret or JWT auth, plus supporting infrastructure (token introspection, revocation, dynamic client registration) that lets machine clients authenticate and manage tokens without human interaction. This is first-party documented and corroborated by broad community usage as a stable OAuth2/OIDC provider in production. Missing for 10: independent hands-on validation specifically of the client-credentials flow (vs. general Keycloak stability reports).

   • [claimed-docs] “OIDC layers reference, "Client credentials": "Client Credentials are used when clients (applications and services) want to obtain access on …”
   • [claimed-docs] “The dynamic client registration endpoint is used to dynamically register clients.”
   • [claimed-docs] “The introspection endpoint is used to retrieve the active state of a token. In other words, you can use it to validate an access or refresh …”
   • [claimed-docs] “The token revocation endpoint is used to revoke tokens. Both refresh tokens and access tokens are supported by this endpoint.”
   • [claimed-docs] “It lists endpoints and other configuration options relevant to the OpenID Connect implementation in Keycloak.”
   • [claimed-docs] “Authorization Services guide: fine-grained, resource-level authorization — "A resource is part of the assets of an application and the organ…”

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

   Keycloak supports OAuth2 client-credentials grant for machine-to-machine service accounts (distinct non-human identities), fine-grained authorization services to scope permissions per client, and a token revocation endpoint that can immediately revoke access/refresh tokens — the core building blocks needed to give each agent its own least-privilege, revocable identity. However, this requires assembling generic OAuth2 primitives (service accounts + authz policies + revocation endpoint) rather than a purpose-built 'agent identity' feature, and there is no evidence of agent-specific provisioning at scale or hands-on confirmation that revocation is truly instant in practice. Missing for 10: dedicated agent/non-human-identity lifecycle tooling, evidence of bulk/scaled machine-identity issuance, and independent confirmation of revocation latency/behavior.

   • [claimed-docs] “OIDC layers reference, "Client credentials": "Client Credentials are used when clients (applications and services) want to obtain access on …”
   • [claimed-docs] “Authorization Services guide: fine-grained, resource-level authorization — "A resource is part of the assets of an application and the organ…”
   • [claimed-docs] “The token revocation endpoint is used to revoke tokens. Both refresh tokens and access tokens are supported by this endpoint.”
   • [claimed-docs] “Keycloak provides fine-grained authorization services as well. This allows you to manage permissions for all your services from the Keycloak…”
   • [claimed-docs] “A realm in Keycloak is equivalent to a tenant. Each realm allows an administrator to create isolated groups of applications and users.”

   proof ↗⚑ flag

   Better Auth~partialclaimed6/10

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

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

   proof ↗⚑ flag

Mcp

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

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

   Keycloak is a standards-compliant OAuth2/OIDC provider with the core primitives an MCP OAuth flow needs — dynamic client registration, discovery metadata, token introspection/revocation, client-credentials grants for machine clients, and fine-grained authorization services — all documented in first-party docs. However, no evidence anywhere in the pack mentions MCP specifically, any MCP-server integration guide, resource-indicator/audience-restricted tokens for MCP's spec, or a reference implementation fronting an MCP server, so it's inferred generic capability rather than a demonstrated MCP-specific flow. Missing for 10: explicit MCP-server integration documentation or tutorial, evidence of audience/resource-scoped token issuance tailored to MCP's OAuth profile, and independent/hands-on confirmation of using Keycloak to gate an MCP server.

   • [claimed-docs] “/realms/{realm-name}/.well-known/openid-configuration”
   • [claimed-docs] “It lists endpoints and other configuration options relevant to the OpenID Connect implementation in Keycloak.”
   • [claimed-docs] “The dynamic client registration endpoint is used to dynamically register clients.”
   • [claimed-docs] “you can use it to validate an access or refresh token”
   • [claimed-docs] “The introspection endpoint is used to retrieve the active state of a token. In other words, you can use it to validate an access or refresh …”
   • [claimed-docs] “The token revocation endpoint is used to revoke tokens. Both refresh tokens and access tokens are supported by this endpoint.”
   • [claimed-docs] “OIDC layers reference, "Client credentials": "Client Credentials are used when clients (applications and services) want to obtain access on …”
   • [claimed-docs] “Authorization Services guide: fine-grained, resource-level authorization — "A resource is part of the assets of an application and the organ…”
   • [claimed-docs] “Keycloak is based on standard protocols and provides support for OpenID Connect, OAuth 2.0, and SAML.”

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

   Direct probes show no llms.txt (404), no markdown docs endpoint, and no OpenAPI/agent-oriented docs endpoint; only standard human-facing documentation exists.

   • [probe] “PROBE llms.txt: HTTP 404 at https://www.keycloak.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.keycloak.org/documentation.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.keycloak.org/openapi.json, https://www.keycloak.org/swagger.json, https://www.keycloak.o…”

   proof ↗⚑ flag

   Better Auth✓fullprobed9/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Better Auth
   Keycloak!disputedcontradicted4/10

   Keycloak documents strong headless/CI primitives: running from a container image with `start-dev` (keycloak-docs-2, keycloak-docs-45), an Operator for declarative management (keycloak-docs-43, keycloak-docs-54), the kcadm.sh Admin CLI and REST API for scripted administration (kc-supp-kcadm), realm import/export as JSON (keycloak-docs-10), and health REST endpoints for readiness checks (keycloak-docs-17) — all standard building blocks for CI automation. However, hands-on community reports concretely contradict smooth CI/IaC usage: configuration is stored in the database rather than files, making it hard to manage via yaml/configmaps or test changes before production (keycloak-comm-19), the Admin API is described as inconsistent and hard to keep idempotent for Ansible-driven automation (keycloak-comm-13), and one operator explicitly states Keycloak 'doesn't play well with infrastructure-as-code ideas' and is best treated as a 'pet' not 'cattle' (keycloak-comm-3). Missing for 10: first-party CI/CD pipeline examples or GitHub Actions templates, evidence of clean idempotent automation workflows, and resolution of the documented IaC friction.

   • [claimed-docs] “docker run -p 127.0.0.1:8080:8080 -e KC_BOOTSTRAP_ADMIN_USERNAME=admin -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:26.7.3…”
   • [claimed-docs] “Run Keycloak from a container image.”
   • [claimed-docs] “Manage Keycloak OIDC and SAML clients declaratively using the operator.”
   • [claimed-docs] “Install Keycloak using the Operator.”
   • [claimed-docs] “Server Administration Guide documents the Admin CLI: Keycloak "packages the Admin CLI server distribution with the execution scripts in the …”
   • [claimed-docs] “Import and export realms as JSON files.”
   • [claimed-docs] “Check if an instance has finished its start up and is ready to serve requests by calling its health REST endpoints.”
   • [community] “My biggest problem with Keycloak is its configuration. It stores its configuration in the database. It means that I can't just configure it …”
   • [community] “I use various home made Ansible roles and I find the Keycloak API to be inconsistent... it's very hard to keep an idempotency with the actua…”
   • [community] “In my experience, Keycloak is best treated as a 'pet' in the pet v.s. cattle spectrum. It takes a while to warm up, so you don't want to be …”

   proof ↗⚑ flag

   Better Auth~partialprobed5/10

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

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

   proof ↗⚑ flag

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

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

   Keycloak is an identity/access management server; no evidence of an official MCP server for connecting AI agents, and probes for llms.txt/openapi endpoints returned 404. Since Keycloak is not itself an AI agent but a platform/service, this axis applies, and absence of evidence means 'none'.

   • [probe] “PROBE llms.txt: HTTP 404 at https://www.keycloak.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.keycloak.org/documentation.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.keycloak.org/openapi.json, https://www.keycloak.org/swagger.json, https://www.keycloak.o…”

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

   Keycloak ships an official Admin CLI (kcadm.sh) documented in the Server Administration Guide, enabling scripted realm/user/role/client management equivalent to the Admin REST API — well suited for automation by AI agents or scripts. Missing for 10: no independent/hands-on corroboration of kcadm reliability, and no explicit AI-agent-oriented tooling or examples beyond generic scripting support.

   • [claimed-docs] “Server Administration Guide documents the Admin CLI: Keycloak "packages the Admin CLI server distribution with the execution scripts in the …”
   • [claimed-docs] “Documentation for the Adminstration RESTful API”

   proof ↗⚑ flag

   Better Auth✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Keycloak✓fullcommunity8/10

   Keycloak documents an Admin REST API and a full set of OIDC/OAuth2 protocol endpoints (well-known config, token introspection/revocation, dynamic client registration, device grant), plus the kcadm CLI and SCIM endpoints for scripted/agentic driving of the product. Community reports confirm the API is used in real automation (Ansible) though one report notes inconsistency/idempotency friction, a minor caveat rather than a failure. missing for 10: a discoverable OpenAPI/Swagger spec (probe shows 404s) and stronger independent corroboration of full API completeness.

   • [claimed-docs] “Documentation for the Adminstration RESTful API”
   • [claimed-docs] “Keycloak exposes a set of endpoints that applications and services can use to authenticate and authorize their users.”
   • [claimed-docs] “It lists endpoints and other configuration options relevant to the OpenID Connect implementation in Keycloak.”
   • [claimed-docs] “The dynamic client registration endpoint is used to dynamically register clients.”
   • [claimed-docs] “The introspection endpoint is used to retrieve the active state of a token. In other words, you can use it to validate an access or refresh …”
   • [claimed-docs] “The token revocation endpoint is used to revoke tokens. Both refresh tokens and access tokens are supported by this endpoint.”
   • [claimed-docs] “Server Administration Guide documents the Admin CLI: Keycloak "packages the Admin CLI server distribution with the execution scripts in the …”
   • [claimed-docs] “Server Administration Guide, "Managing users and groups through SCIM": built-in SCIM endpoints per realm ("Enabling SCIM for a realm", "Obta…”
   • [claimed-docs] “OIDC layers reference, "Client credentials": "Client Credentials are used when clients (applications and services) want to obtain access on …”
   • [community] “I use various home made Ansible roles and I find the Keycloak API to be inconsistent... it's very hard to keep an idempotency with the actua…”

   proof ↗⚑ flag

   Better Auth✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Keycloak
   Keycloak~partialclaimed7/10

   Keycloak's client credentials grant lets service accounts (which cover automated/agent clients) authenticate via client_id/secret or JWT, and its Authorization Services/fine-grained authorization let admins define exact least-privilege policies and scopes per client, which is the core mechanism needed to issue scoped API credentials to a non-human actor like an AI agent. However, none of the evidence specifically addresses AI-agent use cases, dynamic/short-lived credential issuance workflows for agents, or independent hands-on validation of scoped-credential setups. Missing for 10: agent-specific tooling or examples, dynamic/ephemeral credential issuance patterns, independent/hands-on confirmation that scoped client-credentials setups work as intended for agentic workloads.

   • [claimed-docs] “OIDC layers reference, "Client credentials": "Client Credentials are used when clients (applications and services) want to obtain access on …”
   • [claimed-docs] “Authorization Services guide: fine-grained, resource-level authorization — "A resource is part of the assets of an application and the organ…”
   • [claimed-docs] “Keycloak provides fine-grained authorization services as well. This allows you to manage permissions for all your services from the Keycloak…”
   • [claimed-docs] “The dynamic client registration endpoint is used to dynamically register clients.”

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

   Evidence covers Keycloak's REST APIs, OIDC endpoints, admin CLI (kcadm), and protocol standards, but nothing documents official client SDKs/libraries for developers (let alone AI-native/agentic use) — and probes confirm no machine-readable API spec (openapi.json 404) or llms.txt is exposed. Missing for 10: any mention of official SDKs (Java, Node, Python, etc.), agent/AI-specific integration libraries, or programmatic SDK documentation.

   • [claimed-docs] “Documentation for the Adminstration RESTful API”
   • [claimed-docs] “Keycloak exposes a set of endpoints that applications and services can use to authenticate and authorize their users.”
   • [claimed-docs] “Server Administration Guide documents the Admin CLI: Keycloak "packages the Admin CLI server distribution with the execution scripts in the …”
   • [probe] “PROBE llms.txt: HTTP 404 at https://www.keycloak.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.keycloak.org/documentation.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.keycloak.org/openapi.json, https://www.keycloak.org/swagger.json, https://www.keycloak.o…”

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

   No evidence in the pack mentions webhooks or an event-subscription mechanism for external systems; Keycloak's admin/account consoles, REST APIs, and SPI extensibility are documented, but nothing indicates a webhook subscription feature for events like login, user creation, etc. missing for 10: any documentation of webhook config, event listener SPI exposed as webhooks, or third-party corroboration of webhook support.

   ⚑ 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
   Keycloak—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

   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

Api quality

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

   weight 2 · round drawn
   Keycloak—none0/10

   Evidence shows only a link to 'Documentation for the Administration RESTful API' (keycloak-docs-6) with no mention of an interactive, runnable API explorer; probes for OpenAPI/Swagger specs and machine-readable docs all returned 404s, indicating no interactive API reference is exposed.

   • [claimed-docs] “Documentation for the Adminstration RESTful API”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.keycloak.org/openapi.json, https://www.keycloak.org/swagger.json, https://www.keycloak.o…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://www.keycloak.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.keycloak.org/documentation.md”

   proof ↗⚑ flag

   Better Auth—none0/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Keycloak
   Keycloak~partialprobed4/10

   Keycloak exposes machine-readable OIDC discovery metadata (the /.well-known/openid-configuration endpoint documented in the OIDC layers guide), which is a standard machine-readable description of its authentication/authorization endpoints — a partial equivalent to an API spec for that subsystem. However, direct probes for a full OpenAPI/Swagger spec (openapi.json, swagger.json, etc.) all returned 404, and the docs only reference prose documentation for the Admin REST API rather than a downloadable machine-readable spec covering the full REST surface. Missing for 10: a published OpenAPI/Swagger document for the Admin REST API or other REST endpoints, and any docs explicitly stating such a spec is downloadable.

   • [claimed-docs] “/realms/{realm-name}/.well-known/openid-configuration”
   • [claimed-docs] “It lists endpoints and other configuration options relevant to the OpenID Connect implementation in Keycloak.”
   • [claimed-docs] “Documentation for the Adminstration RESTful API”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.keycloak.org/openapi.json, https://www.keycloak.org/swagger.json, https://www.keycloak.o…”

   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 to Keycloak
   Keycloak!disputedcontradicted4/10

   Keycloak docs show a local dev-mode Docker instance (start-dev), realm-based tenant isolation, and JSON import/export of realms, which could be used to build a sandbox separate from production. However, a hands-on community report explicitly states that because Keycloak stores its configuration in the database rather than files, 'there's no easy supported way to test some changes before production,' directly contradicting the idea of frictionless sandbox testing. missing for 10: no first-party guidance on a supported staging/sandbox workflow, no evidence of data-masking or safe test-data seeding, and the one concrete community account says testing before production is hard.

   • [claimed-docs] “docker run -p 127.0.0.1:8080:8080 -e KC_BOOTSTRAP_ADMIN_USERNAME=admin -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:26.7.3…”
   • [claimed-docs] “A realm in Keycloak is equivalent to a tenant. Each realm allows an administrator to create isolated groups of applications and users.”
   • [claimed-docs] “Import and export realms as JSON files.”
   • [claimed-docs] “Switch to a production ready database such as PostgreSQL.”
   • [community] “My biggest problem with Keycloak is its configuration. It stores its configuration in the database. It means that I can't just configure it …”

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

   Evidence documents Keycloak's Admin REST API and OIDC endpoints exist, but nothing describes API versioning schemes or a documented deprecation policy; one community comment even calls the API 'inconsistent' for automation purposes. Missing for 10: any documentation of API version numbers, backward-compatibility guarantees, or a formal deprecation/sunset policy.

   • [claimed-docs] “Documentation for the Adminstration RESTful API”
   • [claimed-docs] “Keycloak exposes a set of endpoints that applications and services can use to authenticate and authorize their users.”
   • [community] “I use various home made Ansible roles and I find the Keycloak API to be inconsistent... it's very hard to keep an idempotency with the actua…”

   proof ↗⚑ flag

   Better Auth—none0/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Keycloak
   Keycloak~partialcommunity5/10

   Keycloak exposes an Admin REST API and the kcadm CLI for scripting operations across realms, users, roles, and clients, plus realm import/export as JSON, which together enable programmatic/bulk administration. However, there's no documented dedicated bulk-operation endpoint, and community feedback notes the API is inconsistent and hard to use idempotently for automation (keycloak-comm-13), undercutting reliability for large-scale scripted changes. Missing for 10: explicit bulk/batch API documentation, first-party examples of bulk user/client management, and independent confirmation that automation at scale works smoothly.

   • [claimed-docs] “Server Administration Guide documents the Admin CLI: Keycloak "packages the Admin CLI server distribution with the execution scripts in the …”
   • [claimed-docs] “Documentation for the Adminstration RESTful API”
   • [claimed-docs] “Import and export realms as JSON files.”
   • [community] “I use various home made Ansible roles and I find the Keycloak API to be inconsistent... it's very hard to keep an idempotency with the actua…”

   proof ↗⚑ flag

   Better Auth—none0/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round to Keycloak
   Keycloak~partialclaimed3/10

   Keycloak documents built-in automated triggers like brute-force lockout policies that fire actions (temporary/permanent account lockout) based on login-failure events, and its SPI-based extensibility could theoretically support custom event listeners, but there is no documented general-purpose rules/automation engine for user-defined event-triggered actions. missing for 10: a documented rules/automation engine or webhook system letting users define arbitrary triggers/actions, independent evidence of custom event-listener usage, and any AI-native automation tooling.

   • [claimed-docs] “Server Administration Guide, brute force protection events: "User disabled by permanent lockout — Brute force protection disabled the user a…”
   • [claimed-docs] “Extensible - Customize through code”

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

   Keycloak is explicitly self-hosted (Docker/container image, Operator install) and lets operators run their own production database (e.g., switch to PostgreSQL) and realm data entirely under their control, with no mandatory SaaS dependency; community reports corroborate years of stable self-hosted production use. missing for 10: no explicit first-party statement on data residency/air-gapped deployment guarantees beyond generic self-hosting instructions.

   • [claimed-docs] “docker run -p 127.0.0.1:8080:8080 -e KC_BOOTSTRAP_ADMIN_USERNAME=admin -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:26.7.3…”
   • [claimed-docs] “This command starts Keycloak exposed on the local port 8080 and creates an initial admin user with the username `admin` and password `admin`…”
   • [claimed-docs] “Run Keycloak from a container image.”
   • [claimed-docs] “Install Keycloak using the Operator.”
   • [claimed-docs] “Switch to a production ready database such as PostgreSQL.”
   • [community] “We have been using it for 6-7 years now. Have been able to run very stable and integrated a lot of external IdP's to offer proper SSO on mul…”
   • [community] “We've been using Keycloak in production as a multi-tenant SSO solution for our service delivery. We've been incredibly impressed with the st…”
   • [community] “After Okta rudely told us, a paying customer, to pay extra or leave, we decided to survey alternatives. Four years ago, we found Keycloak an…”

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

   Keycloak's identity brokering natively supports both SAML 2.0 and OIDC identity providers configured via the admin console, and production users confirm integrating multiple external IdPs for SSO in real deployments. Missing for 10: explicit named walkthroughs/screenshots for Okta, Entra, or Google Workspace specifically, and independent hands-on verification of these exact IdP integrations rather than generic SAML/OIDC brokering docs.

   • [claimed-docs] “Keycloak can also authenticate users with existing OpenID Connect or SAML 2.0 Identity Providers.”
   • [claimed-docs] “Keycloak can also authenticate users with existing OpenID Connect or SAML 2.0 Identity Providers. Again, this is just a matter of configurin…”
   • [claimed-docs] “Keycloak site, Identity Brokering and Social Login: "Enabling login with social networks is easy to add through the admin console. It's just…”
   • [community] “We have been using it for 6-7 years now. Have been able to run very stable and integrated a lot of external IdP's to offer proper SSO on mul…”
   • [community] “After Okta rudely told us, a paying customer, to pay extra or leave, we decided to survey alternatives. Four years ago, we found Keycloak an…”

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

   Keycloak's Server Administration Guide documents built-in SCIM support for managing users and groups per realm, including enabling SCIM, obtaining the SCIM API base URL, and setting up a service account client — directly matching the story's sync mechanism. However, evidence is first-party docs only with no independent/hands-on corroboration that deprovisioning in the source IdP actually propagates through SCIM to revoke app access, and no detail on directionality (Keycloak as SCIM client vs server) or deprovisioning semantics. Missing for 10: independent corroboration of real-world SCIM deprovisioning flow, clarity on SCIM client vs server mode, and details on how revocation cascades to relying-party access.

   • [claimed-docs] “Server Administration Guide, "Managing users and groups through SCIM": built-in SCIM endpoints per realm ("Enabling SCIM for a realm", "Obta…”

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

   The evidence pack contains no mention of audit logging, event listeners, admin event tracking, tamper-evidence, or SIEM export/streaming capabilities—only general docs on protocols, admin console, federation, and community sentiment. Audit-log export to SIEM is a fair expectation for an IAM platform, so this is 'none' rather than 'na', but nothing in the pack substantiates it.

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

   The evidence pack contains no mention of webhooks, event streams, or an event listener SPI for auth events (sign-ups, sign-ins, user changes); it only covers OIDC/SAML protocols, admin console, REST API, and federation topics. Missing for 10: any documentation of webhook/event-stream subscription mechanism, event listener SPI, or third-party event-forwarding examples.

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

   Evidence shows only generic OIDC/SAML protocol support and endpoints (well-known config, introspection, revocation) but no mention of a first-party Next.js SDK, edge middleware, or session verification at the edge; Keycloak's client adapters for specific frameworks are not referenced anywhere in the pack.

   • [claimed-docs] “/realms/{realm-name}/.well-known/openid-configuration”
   • [claimed-docs] “Keycloak exposes a set of endpoints that applications and services can use to authenticate and authorize their users.”
   • [claimed-docs] “It lists endpoints and other configuration options relevant to the OpenID Connect implementation in Keycloak.”
   • [claimed-docs] “you can use it to validate an access or refresh token”

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

   Keycloak ships hosted, production-ready login/registration/forgot-password/account-management pages out of the box (keycloak-docs-3, -27, -28, -32, -33, -13, -51) and supports full UI customization via its theming system (keycloak-docs-7, -26, -41) and self-registration/profile/2FA management through the Account Console (keycloak-docs-13, -48, -51). This directly covers sign-in, sign-up, and profile management via hosted pages/customizable themes. Missing for 10: independent/hands-on evidence validating ease of theme customization in practice, and no mention of embeddable prebuilt UI component libraries (e.g., React/Vue widgets) beyond server-rendered hosted pages — the story leans on hosted pages more than 'components' but that gap in evidence keeps quality below top marks.

   • [claimed-docs] “To secure the first application, you start by registering the application with your Keycloak instance”
   • [claimed-docs] “Themes - Customize look and feel”
   • [claimed-docs] “Through the account management console users can manage their own accounts. They can update the profile, change passwords, and setup two-fac…”
   • [claimed-docs] “Customize look and feel”
   • [claimed-docs] “This command starts Keycloak exposed on the local port 8080 and creates an initial admin user with the username `admin` and password `admin`…”
   • [claimed-docs] “Set **Valid redirect URIs** to `https://www.keycloak.org/app/*`”
   • [claimed-docs] “Allowing users to self-register”
   • [claimed-docs] “Enabling forgot password”
   • [claimed-docs] “Creating themes and providers to customize the Keycloak server”
   • [claimed-docs] “Users can also manage sessions as well as view history for the account.”
   • [claimed-docs] “Fill in the form with the following values: **Client type**: `OpenID Connect` **Client ID**: `myclient`”
   • [claimed-docs] “As a user in the Account Console, you can manage your account including modifying your profile, adding two-factor authentication, and includ…”

   proof ↗⚑ flag

   Better Auth—none0/10

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

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

   proof ↗⚑ flag

Hardening

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

   weight 1 · round to Keycloak
   Keycloak✓fullcommunity8/10

   Keycloak documents built-in brute-force detection with temporary and permanent account lockout events (kc-supp-brute-force), and CVE-2023-6927 evidence shows security issues (redirect URI validation) are patched, not indicating brute-force protection failure. Standard OIDC/OAuth flows plus WebAuthn/passkey support (kc-supp-passkeys) further harden auth flows against credential-based attacks. Missing for 10: no explicit bot-detection/CAPTCHA feature documentation, no independent third-party testing or benchmark of brute-force protection effectiveness against real attacks.

   • [claimed-docs] “Server Administration Guide, brute force protection events: "User disabled by permanent lockout — Brute force protection disabled the user a…”
   • [claimed-docs] “Server Administration Guide documents "W3C Web Authentication (WebAuthn)" setup ("Enable WebAuthn authentication in the default browser flow…”
   • [claimed-docs] “Through the account management console users can manage their own accounts. They can update the profile, change passwords, and setup two-fac…”
   • [community] “CVE-2023-6927 Keycloak vulnerability allows bypassing redirect URI validation which can be used as a vector for stealing authorization codes…”

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

   Docs confirm Keycloak supports enabling two-factor authentication via the account console and reference WebAuthn/passkey setups, showing MFA capability exists, but no evidence explicitly describes TOTP authenticator app enrollment, backup/recovery codes, or configurable step-up authentication policies. missing for 10: explicit TOTP authenticator app documentation, backup codes mechanism, step-up/conditional MFA enforcement details, and independent confirmation of these specific features.

   • [claimed-docs] “Through the account management console users can manage their own accounts. They can update the profile, change passwords, and setup two-fac…”
   • [claimed-docs] “As a user in the Account Console, you can manage your account including modifying your profile, adding two-factor authentication, and includ…”
   • [claimed-docs] “Server Administration Guide documents "W3C Web Authentication (WebAuthn)" setup ("Enable WebAuthn authentication in the default browser flow…”
   • [claimed-docs] “Server Administration Guide, brute force protection events: "User disabled by permanent lockout — Brute force protection disabled the user a…”

   proof ↗⚑ flag

   Better Auth~partialclaimed7/10

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

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

   proof ↗⚑ flag

Passwordless

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

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

   Keycloak's admin docs explicitly document WebAuthn and a dedicated Passkeys section (conditional UI/autofill, modal UI, passkey mediation, loginless WebAuthn), showing first-class passwordless/passkey support. However, there is no evidence of built-in magic-link or email OTP sign-in as first-class methods—these are not mentioned anywhere in the pack. Missing for 10: documentation of magic-link authentication, native email OTP flow, and independent/hands-on confirmation of passkey UX.

   • [claimed-docs] “Server Administration Guide documents "W3C Web Authentication (WebAuthn)" setup ("Enable WebAuthn authentication in the default browser flow…”
   • [claimed-docs] “Through the account management console users can manage their own accounts. They can update the profile, change passwords, and setup two-fac…”
   • [claimed-docs] “As a user in the Account Console, you can manage your account including modifying your profile, adding two-factor authentication, and includ…”

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

   Keycloak's official docs show standard OIDC discovery, client registration with redirect URIs (implying auth code+PKCE flow), token introspection/revocation endpoints, and explicit support for refresh tokens and client credentials grants, all abstracting protocol details behind admin console configuration and standard endpoints. Community evidence corroborates long-term production use for OAuth2/OIDC SSO across many stacks, though some note it requires OAuth/OIDC familiarity to configure well. Missing for 10: explicit first-party documentation/code sample showing PKCE flag toggling or client library code eliminating hand-rolled protocol logic.

   • [claimed-docs] “/realms/{realm-name}/.well-known/openid-configuration”
   • [claimed-docs] “Keycloak exposes a set of endpoints that applications and services can use to authenticate and authorize their users.”
   • [claimed-docs] “It lists endpoints and other configuration options relevant to the OpenID Connect implementation in Keycloak.”
   • [claimed-docs] “you can use it to validate an access or refresh token”
   • [claimed-docs] “The introspection endpoint is used to retrieve the active state of a token. In other words, you can use it to validate an access or refresh …”
   • [claimed-docs] “The token revocation endpoint is used to revoke tokens. Both refresh tokens and access tokens are supported by this endpoint.”
   • [claimed-docs] “OIDC layers reference, "Client credentials": "Client Credentials are used when clients (applications and services) want to obtain access on …”
   • [claimed-docs] “Set **Valid redirect URIs** to `https://www.keycloak.org/app/*`”
   • [claimed-docs] “Fill in the form with the following values: **Client type**: `OpenID Connect` **Client ID**: `myclient`”
   • [community] “My company used Keycloak for a long time... it works great, but it's hard to understand unless you already know oauth/oidc, and it is a huge…”
   • [community] “We have been using it for 6-7 years now. Have been able to run very stable and integrated a lot of external IdP's to offer proper SSO on mul…”

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

   Keycloak's docs explicitly state that social login and identity brokering (OIDC/SAML IdPs) are enabled purely through admin console configuration with 'no code or changes to your application required,' and community evidence corroborates real-world use integrating many external IdPs for SSO. Missing for 10: no evidence enumerating the exact list/breadth of pre-built social providers, and no independent hands-on account specifically validating the configuration-only social login flow.

   • [claimed-docs] “Enabling login with social networks is easy to add through the admin console.”
   • [claimed-docs] “Enabling login with social networks is easy to add through the admin console. It's just a matter of selecting the social network you want to…”
   • [claimed-docs] “Keycloak can also authenticate users with existing OpenID Connect or SAML 2.0 Identity Providers. Again, this is just a matter of configurin…”
   • [claimed-docs] “Keycloak site, Identity Brokering and Social Login: "Enabling login with social networks is easy to add through the admin console. It's just…”
   • [claimed-docs] “If you've enabled social login or identity brokering users can also link their accounts with additional providers to allow them to authentic…”
   • [community] “We have been using it for 6-7 years now. Have been able to run very stable and integrated a lot of external IdP's to offer proper SSO on mul…”

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

   Keycloak is designed exactly for this: developers register their app as a realm/client, and Keycloak issues OAuth2/OIDC tokens (with discovery, introspection, revocation, dynamic client registration, client credentials for machine clients) so third-party clients can authenticate against the developer's own Keycloak-backed app, effectively 'Sign in with my app'. Missing for 10: independent hands-on case study of a developer specifically building a public-facing 'Sign in with X' third-party integration, and clearer docs on scoping/consent screens for external clients.

   • [claimed-docs] “To secure the first application, you start by registering the application with your Keycloak instance”
   • [claimed-docs] “/realms/{realm-name}/.well-known/openid-configuration”
   • [claimed-docs] “A realm in Keycloak is equivalent to a tenant. Each realm allows an administrator to create isolated groups of applications and users.”
   • [claimed-docs] “The dynamic client registration endpoint is used to dynamically register clients.”
   • [claimed-docs] “The introspection endpoint is used to retrieve the active state of a token. In other words, you can use it to validate an access or refresh …”
   • [claimed-docs] “The token revocation endpoint is used to revoke tokens. Both refresh tokens and access tokens are supported by this endpoint.”
   • [claimed-docs] “OIDC layers reference, "Client credentials": "Client Credentials are used when clients (applications and services) want to obtain access on …”
   • [claimed-docs] “Keycloak exposes a set of endpoints that applications and services can use to authenticate and authorize their users.”

   proof ↗⚑ flag

   Better Auth✓fullprobed7/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Better Auth
   Keycloak~partialprobed7/10

   Keycloak documents a comprehensive Admin REST API (kc-docs-6, kc-supp-kcadm) that the kcadm CLI wraps, and the same operations (realms, users, roles, clients, permissions) are said to be available via API as via the Admin Console — strong first-party support for API-as-UI-parity. However, a hands-on report notes the API is 'inconsistent' and hard to use idempotently for automation (keycloak-comm-13), SCIM explicitly excludes protected admin resources ('never through SCIM', kc-supp-scim), and no discoverable OpenAPI/machine-readable spec was found (keycloak-probe-3), undermining full AI-native parity and discoverability. missing for 10: independent corroboration that all UI-only workflows (e.g. theme customization, some fine-grained authz UI flows) have equal API parity, a public/discoverable OpenAPI spec, and resolution of reported API inconsistency for automation.

   • [claimed-docs] “Documentation for the Adminstration RESTful API”
   • [claimed-docs] “Server Administration Guide documents the Admin CLI: Keycloak "packages the Admin CLI server distribution with the execution scripts in the …”
   • [community] “I use various home made Ansible roles and I find the Keycloak API to be inconsistent... it's very hard to keep an idempotency with the actua…”
   • [claimed-docs] “Server Administration Guide, "Managing users and groups through SCIM": built-in SCIM endpoints per realm ("Enabling SCIM for a realm", "Obta…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.keycloak.org/openapi.json, https://www.keycloak.org/swagger.json, https://www.keycloak.o…”

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

   Keycloak documents realm import/export as JSON, giving admins a way to extract configuration and user data in an open format, and being self-hosted/open-source avoids vendor lock-in. However, there is no documented end-user-facing 'export my data' feature for individual account holders (only admin console/CLI export), and no mention of exporting in other open standards (e.g., CSV, SCIM bulk export) beyond JSON realm dumps. Missing for 10: end-user self-service data export UI, broader open-format support, and independent confirmation of export completeness/fidelity.

   • [claimed-docs] “Import and export realms as JSON files.”
   • [claimed-docs] “Through the admin console administrators can centrally manage all aspects of the Keycloak server.”
   • [claimed-docs] “Server Administration Guide documents the Admin CLI: Keycloak "packages the Admin CLI server distribution with the execution scripts in the …”

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

   The evidence pack contains extensive product documentation and community commentary but no citation identifies an open-source license (e.g., Apache 2.0), a public source repository, or any statement about being able to read Keycloak's source code. Missing for 10: explicit license statement, link to source repository (e.g., GitHub), any confirmation of open licensing terms.

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

   Keycloak ships docker images and a documented self-host quickstart (docker run with KC_BOOTSTRAP_ADMIN_*), operator install, production DB setup, and reverse-proxy/clustering guides, and multiple community users confirm years of stable self-hosted production use. Missing for 10: independent benchmark/security audit beyond anecdotal community reports and no first-party statement addressing high resource usage some users report.

   • [claimed-docs] “docker run -p 127.0.0.1:8080:8080 -e KC_BOOTSTRAP_ADMIN_USERNAME=admin -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:26.7.3…”
   • [claimed-docs] “This command starts Keycloak exposed on the local port 8080 and creates an initial admin user with the username `admin` and password `admin`…”
   • [claimed-docs] “Run Keycloak from a container image.”
   • [claimed-docs] “Install Keycloak using the Operator.”
   • [claimed-docs] “Switch to a production ready database such as PostgreSQL.”
   • [claimed-docs] “Configure Keycloak with a reverse proxy, API gateway, or load balancer.”
   • [community] “We have been using it for 6-7 years now. Have been able to run very stable and integrated a lot of external IdP's to offer proper SSO on mul…”
   • [community] “We've been using Keycloak in production as a multi-tenant SSO solution for our service delivery. We've been incredibly impressed with the st…”
   • [community] “I've run keycloak securing internet facing apps with ~1000 users for years. It's so stable, I usually forget it's even there.”
   • [community] “After Okta rudely told us, a paying customer, to pay extra or leave, we decided to survey alternatives. Four years ago, we found Keycloak an…”

   proof ↗⚑ flag

   Better Auth✓fullcommunity8/10

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

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

   proof ↗⚑ flag

Orgs

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

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

   Keycloak documents an 'Organizations' feature in the realm admin guide allowing creation of named, realm-scoped organizations, and separately documents identity brokering/federation and first-broker-login style provisioning generally, but the evidence pack never shows organization-specific domain verification or org-linked JIT provisioning end-to-end. Missing for 10: evidence of domain verification per organization, evidence of binding a distinct SSO/IdP connection to each organization, and explicit documentation of JIT user provisioning tied to org membership.

   • [claimed-docs] “Server Administration Guide, "Managing organizations": "In the Organizations section, you can manage all the organizations in your realm. Cr…”
   • [claimed-docs] “Keycloak site, Identity Brokering and Social Login: "Enabling login with social networks is easy to add through the admin console. It's just…”
   • [claimed-docs] “Keycloak site, User Federation: "Keycloak has built-in support to connect to existing LDAP or Active Directory servers. You can also impleme…”
   • [claimed-docs] “A realm in Keycloak is equivalent to a tenant. Each realm allows an administrator to create isolated groups of applications and users.”

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

   Keycloak ships a dedicated 'Organizations' feature (Server Admin Guide: create organizations, set unique names within a realm) that is designed exactly for multi-tenant B2B scenarios, going beyond the older realm-as-tenant model. However, the evidence pack only documents organization creation/naming and does not show the membership management or invitation-flow mechanics in detail (e.g., inviting users by email, org-scoped roles, self-registration into an org). Missing for 10: documented invitation-flow API/UI details, membership assignment mechanics, and independent/hands-on confirmation that these work smoothly in production.

   • [claimed-docs] “Server Administration Guide, "Managing organizations": "In the Organizations section, you can manage all the organizations in your realm. Cr…”
   • [claimed-docs] “A realm in Keycloak is equivalent to a tenant. Each realm allows an administrator to create isolated groups of applications and users.”
   • [claimed-docs] “Allowing users to self-register”

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

   Keycloak is self-hosted software that can be run via Docker/container images against a database the operator chooses (e.g., PostgreSQL), which inherently lets an operator pick the physical region/infrastructure for data storage. However, there is no explicit documentation addressing data residency, region selection, or compliance controls as a named feature. Missing for 10: explicit residency/region documentation, multi-region deployment guidance, data localization/compliance statements.

   • [claimed-docs] “docker run -p 127.0.0.1:8080:8080 -e KC_BOOTSTRAP_ADMIN_USERNAME=admin -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:26.7.3…”
   • [claimed-docs] “Run Keycloak from a container image.”
   • [claimed-docs] “Switch to a production ready database such as PostgreSQL.”

   proof ↗⚑ flag

   Better Auth~partialcommunity5/10

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

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

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round to Better Auth
   Keycloak~partialclaimed3/10

   Keycloak lets admins manage/delete users via the Admin Console and Admin REST API, and users can view/manage some of their own account data (profile, sessions) via the Account Console, which indirectly supports data control and deletion. However, there is no explicit documentation of data-retention policies, automated data expiry, GDPR-style export/erasure workflows, or user-initiated account deletion. Missing for 10: explicit retention policy configuration, documented self-service account/data deletion, data export tooling, and GDPR/compliance-specific retention controls.

   • [claimed-docs] “Documentation for the Adminstration RESTful API”
   • [claimed-docs] “Through the account management console users can manage their own accounts. They can update the profile, change passwords, and setup two-fac…”
   • [claimed-docs] “Users can also manage sessions as well as view history for the account.”
   • [claimed-docs] “Server Administration Guide documents the Admin CLI: Keycloak "packages the Admin CLI server distribution with the execution scripts in the …”

   proof ↗⚑ flag

   Better Auth~partialcommunity4/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Keycloak—none0/10

   No evidence in the pack addresses telemetry collection or an opt-out mechanism for Keycloak; the only related item (keycloak-docs-44) describes self-hosted operational metrics for monitoring, not vendor usage tracking. Since telemetry opt-out is a plausible question for any self-hosted server software, and no evidence supports or denies it, this is 'none' rather than 'na'.

   ⚑ flag

   Better Auth—none0/10

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

   ⚑ flag

Rbac

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

   weight 1 · round to Keycloak
   Keycloak✓fullclaimed9/10

   Keycloak's Authorization Services documentation explicitly describes resource-level, policy-based fine-grained authorization beyond RBAC, using resources, scopes, and policies evaluated via UMA permission tickets — going well past simple role checks (kc-supp-authz-services, keycloak-docs-49, keycloak-docs-24, keycloak-docs-37). This is well-documented first-party capability with a dedicated guide, and community evidence corroborates general production stability though doesn't specifically validate this subsystem in depth. Missing for 10: independent/hands-on community validation specifically of the fine-grained authorization services feature (relationship-based policies, custom policy scripts) rather than general product reviews.

   • [claimed-docs] “Authorization Services guide: fine-grained, resource-level authorization — "A resource is part of the assets of an application and the organ…”
   • [claimed-docs] “If role based authorization doesn't cover your needs, Keycloak provides fine-grained authorization services as well. This allows you to mana…”
   • [claimed-docs] “Keycloak provides fine-grained authorization services as well. This allows you to manage permissions for all your services from the Keycloak…”
   • [claimed-docs] “Centrally manage fine-grained permissions for applications and services”
   • [claimed-docs] “Keycloak provides fine-grained authorization services as well. This allows you to manage permissions for all your services from the Keycloak…”

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

   Keycloak's docs explicitly describe role-based authorization plus fine-grained/UMA-based authorization services managed centrally via the admin console and REST API (keycloak-docs-24, keycloak-docs-49, kc-supp-authz-services), and its OIDC layer issues signed access tokens that carry these claims, validated via introspection endpoints (keycloak-docs-38, keycloak-docs-40, keycloak-docs-52). This matches standard Keycloak behavior where realm/client roles are embedded in JWT access tokens for downstream authorization checks. Missing for 10: an explicit first-party quote showing role claims embedded in the JWT payload, and independent/hands-on confirmation of token-based enforcement in production.

   • [claimed-docs] “Keycloak provides fine-grained authorization services as well. This allows you to manage permissions for all your services from the Keycloak…”
   • [claimed-docs] “If role based authorization doesn't cover your needs, Keycloak provides fine-grained authorization services as well. This allows you to mana…”
   • [claimed-docs] “It lists endpoints and other configuration options relevant to the OpenID Connect implementation in Keycloak.”
   • [claimed-docs] “you can use it to validate an access or refresh token”
   • [claimed-docs] “The introspection endpoint is used to retrieve the active state of a token. In other words, you can use it to validate an access or refresh …”
   • [claimed-docs] “Authorization Services guide: fine-grained, resource-level authorization — "A resource is part of the assets of an application and the organ…”
   • [claimed-docs] “/realms/{realm-name}/.well-known/openid-configuration”

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

   Keycloak's Account Console lets users view and manage their own sessions and history, while the Admin Console/Admin REST API lets admins manage users' sessions and permissions, and single sign-out revokes sessions across all connected apps — covering the core of the story for both personas. Missing for 10: explicit documentation of a per-device 'revoke individually vs revoke all' UI/API call-out and independent/hands-on confirmation of this specific workflow.

   • [claimed-docs] “Users can also manage sessions as well as view history for the account.”
   • [claimed-docs] “They can also manage users, including permissions and sessions.”
   • [claimed-docs] “Through the account management console users can manage their own accounts. They can update the profile, change passwords, and setup two-fac…”
   • [claimed-docs] “Keycloak provides single-sign out, which means users only have to logout once to be logged-out of all applications that use Keycloak.”
   • [claimed-docs] “As a user in the Account Console, you can manage your account including modifying your profile, adding two-factor authentication, and includ…”

   proof ↗⚑ flag

   Better Auth~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round to Better Auth
   Keycloak✓fullclaimed7/10

   Keycloak's docs show explicit server-side session/token revocation (token revocation endpoint, single sign-out) and admin/user session management (admin console 'manage sessions', account console lets users view/manage sessions), plus introspection for validating token state. Refresh is implied via standard OIDC refresh tokens and the introspection/revocation endpoints supporting both access and refresh tokens. missing for 10: explicit documentation of session/token expiry (idle/max lifespan) configuration and refresh-token rotation policy, and independent hands-on confirmation that revocation immediately kills active sessions

   • [claimed-docs] “The token revocation endpoint is used to revoke tokens. Both refresh tokens and access tokens are supported by this endpoint.”
   • [claimed-docs] “The introspection endpoint is used to retrieve the active state of a token. In other words, you can use it to validate an access or refresh …”
   • [claimed-docs] “They can also manage users, including permissions and sessions.”
   • [claimed-docs] “Users can also manage sessions as well as view history for the account.”
   • [claimed-docs] “Keycloak provides single-sign out, which means users only have to logout once to be logged-out of all applications that use Keycloak.”
   • [claimed-docs] “you can use it to validate an access or refresh token”
   • [claimed-docs] “Through the admin console administrators can centrally manage all aspects of the Keycloak server.”

   proof ↗⚑ flag

   Better Auth✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Migration

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

   weight 2 · round drawn
   Keycloak~partialclaimed5/10

   Keycloak documents realm import/export as JSON files (keycloak-docs-10), which is the standard mechanism for bulk user migration, and the Admin CLI/REST API (kc-supp-kcadm) can further script user data extraction and loading. However, the evidence pack never explicitly confirms that password hashes are preserved/portable in this export-import flow, nor is there any hands-on or community confirmation of successful password-hash migration to/from Keycloak. Missing for 10: explicit documentation of password hash format/algorithm compatibility during import, worked example of exporting and re-importing credentials, and independent/community verification that this round-trip works without lock-in issues.

   • [claimed-docs] “Import and export realms as JSON files.”
   • [claimed-docs] “Server Administration Guide documents the Admin CLI: Keycloak "packages the Admin CLI server distribution with the execution scripts in the …”

   proof ↗⚑ flag

   Better Auth~partialcommunity5/10

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

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

   proof ↗⚑ flag

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

   weight 1 · round to Better Auth
   Keycloak~partialclaimed4/10

   Keycloak's user federation SPI lets teams implement a custom provider for existing user stores (e.g., a legacy password database), which is the standard technique used to migrate users without forcing resets, and identity brokering/account linking also support gradual migration. However, there is no vendor-maintained migration guide or tooling specifically targeting competing auth providers (Auth0, Okta, Firebase, etc.) in the evidence pack. Missing for 10: explicit vendor migration guides/tooling for specific competitor providers, documented password-hash-preserving import workflow, and case studies of password-reset-free migrations.

   • [claimed-docs] “You can also implement your own provider if you have users in other stores, such as a relational database.”
   • [claimed-docs] “Keycloak has built-in support to connect to existing LDAP or Active Directory servers.”
   • [claimed-docs] “Keycloak can also authenticate users with existing OpenID Connect or SAML 2.0 Identity Providers.”
   • [claimed-docs] “Keycloak site, User Federation: "Keycloak has built-in support to connect to existing LDAP or Active Directory servers. You can also impleme…”
   • [claimed-docs] “Keycloak site, Identity Brokering and Social Login: "Enabling login with social networks is easy to add through the admin console. It's just…”
   • [claimed-docs] “Import and export realms as JSON files.”

   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