Auth0 vs Keycloak

Delegation

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

   weight 2 · round to Auth0
   Auth0✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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

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

   weight 3 · round to Auth0
   Auth0✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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

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

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

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

   proof ↗⚑ flag

   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

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

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

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

   proof ↗⚑ flag

   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

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

   weight 3 · round to Auth0
   Auth0✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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

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

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

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

   proof ↗⚑ flag

   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

Agent access

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

   weight 2 · round to Auth0
   Auth0✓fullprobed9/10

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

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

   proof ↗⚑ flag

   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

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

   weight 2 · round to Auth0
   Auth0~partialprobed6/10

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

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

   proof ↗⚑ flag

   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

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

   weight 3 · round to Auth0
   Auth0✓fullprobed9/10

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

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

   proof ↗⚑ flag

   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

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Auth0✓fullprobed7/10

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

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

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Auth0✓fullprobed8/10

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

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

   proof ↗⚑ flag

   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

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

   weight 2 · round to Auth0
   Auth0✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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

7. ai-native userBuild against official SDKs

   weight 2 · round to Auth0
   Auth0~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Auth0
   Auth0~partialclaimed5/10

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

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

   proof ↗⚑ flag

   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

Agentic features

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

   weight 3 · round drawn
   Auth0—none0/10

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

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

   proof ↗⚑ flag

   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

Api quality

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

   weight 2 · round drawn
   Auth0—none0/10

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

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

   proof ↗⚑ flag

   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

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

   weight 2 · round to Keycloak
   Auth0—none0/10

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

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

   proof ↗⚑ flag

   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

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

   weight 1 · round to Keycloak
   Auth0—none0/10

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

   ⚑ flag

   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

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

   weight 2 · round drawn
   Auth0—none0/10

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

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

   proof ↗⚑ flag

   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

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

   weight 2 · round to Keycloak
   Auth0~partialclaimed4/10

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

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

   proof ↗⚑ flag

   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

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

   weight 3 · round to Auth0
   Auth0✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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

Deployment

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

   weight 2 · round to Keycloak
   Auth0~partialclaimed4/10

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

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

   proof ↗⚑ flag

   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

Sso

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

   weight 3 · round drawn
   Auth0✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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

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

   weight 2 · round to Keycloak
   Auth0~partialclaimed3/10

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

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

   proof ↗⚑ flag

   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

Audit

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

   weight 2 · round to Auth0
   Auth0~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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

Webhooks

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

   weight 2 · round to Auth0
   Auth0~partialclaimed5/10

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

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

   proof ↗⚑ flag

   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

Frameworks

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

   weight 3 · round drawn
   Auth0—none0/10

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

   ⚑ flag

   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

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

   weight 2 · round drawn
   Auth0✓fullcommunity7/10

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

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

   proof ↗⚑ flag

   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

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

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

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

   proof ↗⚑ flag

   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

Mfa

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

   weight 3 · round to Auth0
   Auth0✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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

Passwordless

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

   weight 2 · round to Auth0
   Auth0✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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

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

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

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

   proof ↗⚑ flag

   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

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

   weight 2 · round to Keycloak
   Auth0✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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

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

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

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

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Auth0~partialprobed7/10

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

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

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Auth0~partialcommunity5/10

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

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

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Auth0—none0/10

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

   ⚑ flag

   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

4. ai-native userSelf-host the core product

   weight 3 · round to Keycloak
   Auth0—none0/10

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

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

   proof ↗⚑ flag

   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

Orgs

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

   weight 2 · round to Auth0
   Auth0~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Auth0~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Auth0~partialclaimed4/10

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

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

   proof ↗⚑ flag

   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

2. ai-native userControl data retention and deletion

   weight 2 · round to Keycloak
   Auth0—none0/10

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

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

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Auth0—none0/10

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

   ⚑ flag

   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

Rbac

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

   weight 1 · round to Keycloak
   Auth0✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Auth0✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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

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

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

   ⚑ flag

   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

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

   weight 3 · round to Keycloak
   Auth0—none0/10

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

   ⚑ flag

   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

Migration

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

   weight 2 · round to Auth0
   Auth0~partialcommunity6/10

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

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

   proof ↗⚑ flag

   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

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

   weight 1 · round to Auth0
   Auth0✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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