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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   Keycloak~partialclaimed6/10

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

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

   proof ↗⚑ flag

Mcp

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

   weight 3 · round to WorkOS
   WorkOS✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   Keycloak—none0/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Keycloak
   WorkOS—none0/10

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   Keycloak—none0/10

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

   ⚑ flag

Frameworks

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

   weight 3 · round drawn
   WorkOS—none0/10

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

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

   proof ↗⚑ flag

   Keycloak—none0/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   WorkOS✓fullcommunity7/10

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

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

   proof ↗⚑ flag

   Keycloak✓fullclaimed7/10

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

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

   proof ↗⚑ flag

Hardening

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

   weight 1 · round to Keycloak
   WorkOS~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   Keycloak~partialclaimed4/10

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

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

   proof ↗⚑ flag

Passwordless

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

   weight 2 · round to WorkOS
   WorkOS✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   Keycloak~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   WorkOS—none0/10

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   Keycloak~partialclaimed4/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round drawn
   WorkOS~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

   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

Rbac

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

   weight 1 · round to Keycloak
   WorkOS~partialclaimed5/10

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

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

   proof ↗⚑ flag

   Keycloak✓fullclaimed9/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round drawn
   WorkOS✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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