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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 Clerk
   Clerk~partialclaimed7/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 Clerk
   Clerk~partialprobed5/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 Clerk
   Clerk!disputedcontradicted3/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

   ⚑ flag

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

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

   ⚑ flag

   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
   Clerk~partialcommunity3/10

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

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

   proof ↗⚑ flag

   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 to Keycloak
   Clerk~partialcommunity7/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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
   Clerk!disputedcontradicted5/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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