# AuthPlane vs Keycloak for MCP Auth: MCP-Native vs the Identity Heavyweight - Published: 2026-08-19 - Tag: COMPARISON - URL: https://authplane.ai/blog/authplane-vs-keycloak/ - Excerpt: Keycloak's RFC 8707 support is experimental and undocumented for MCP; its MCP guide still prescribes manual audience mapping. AuthPlane does it by default. A source-verified comparison of two self-hosted options. --- *Two open-source, self-hosted options for securing an MCP server. One is a full identity platform that recently learned MCP. The other was built for it. Where they actually differ.* ## TL;DR Keycloak and AuthPlane are the two that share a quadrant: open source and self-hosted. The split is a general-purpose identity platform versus a server built only for MCP. The gap that decides most evaluations: Keycloak's Resource Indicators support is experimental and its MCP guide doesn't use it, so the documented path is binding audiences by hand with a per-scope mapper. AuthPlane does it by default. Keycloak if you already run it and want one platform for human identity plus MCP. AuthPlane if MCP authorization is the job and you want it agent-aware and small. If you're comparing self-hosted ways to put OAuth in front of an MCP server, the shortlist is short, and Keycloak is on it. It's the mature, widely deployed, open-source identity platform, and it now has a real MCP guide. So this isn't the usual story of a heavyweight that hasn't noticed MCP. It's a closer call, and it comes down to a few specific differences. ## Is Keycloak a good MCP authorization server? It can be, with one real caveat. Keycloak is a Cloud Native Computing Foundation project, Apache-2.0, with a decade of production behind it as an identity provider for human login, SSO, and federation. Its MCP support is recent but moving fast: the dedicated MCP guide arrived in Keycloak 26.5 (January 2026), experimental Client ID Metadata Document (CIMD) support in 26.6 (April 2026), and experimental token-exchange delegation plus documented Claude Code and VS Code integration in 26.7 (July 2026). The caveat is Resource Indicators, and it's the next section, because it's what most often shapes the decision. The answer there is more interesting than a flat yes or no. Everything else about Keycloak's OAuth core is solid: OAuth 2.1, RFC 8414 metadata, Dynamic Client Registration, and CIMD behind an experimental flag (`bin/kc.sh start --features=cimd`). If Keycloak is already in your stack, extending it to MCP is a reasonable afternoon. If it isn't, you'd be adopting a broad identity platform to solve a narrower problem. ## Does Keycloak support RFC 8707 Resource Indicators? Yes, but with three caveats that matter more than the headline. This is the one place where reading Keycloak's guide will mislead you, so read this part slowly. Keycloak has shipped a Resource Indicators implementation since 26.6 (April 2026). It reads the `resource` parameter, validates it, enforces that the value on the token request matches the authorization request, and sets the access token's audience accordingly. If you enable it, Keycloak does bind audiences from `resource`. The catch is in how you enable it and whether the MCP path uses it. - **It's experimental.** The feature is flagged EXPERIMENTAL in Keycloak's own feature registry, so it's off by default. You opt in with `--features=resource-indicators`, and Keycloak reserves the right to change it in a breaking way. - **Keycloak's MCP guide doesn't use it.** The guide still lists RFC 8707 as "Not supported," still states that Keycloak can't recognize the `resource` parameter, and still walks you through the manual workaround. If you follow the official MCP integration guide, you'll build the mapper setup, because that's what it tells you to do. - **It's modelled around clients, not MCP resources.** The `resource` has to resolve to a registered client, either as `urn:client:` or by giving a client a `resource_url` attribute that matches. Keycloak's own guide hints at the gap when it says the community is still working to process `resource` "as the MCP specification expects." So there's still per-server setup, just one client attribute rather than a mapper per scope. The documented Keycloak path is still manual. For a server at `https://example.com/mcp` with three scopes, you create a client scope for each and add an Audience mapper to each with the server URL in the Included Custom Audience field. Three scopes, three mappers, one server. Add another server and you repeat it. AuthPlane does this by default, with no feature flag and no client mapping. Register the MCP server once, and a token issued for that server is audience-bound to its exact URI. If you're running one MCP server and don't mind the setup, either path works. If you're running several, or you'd rather not depend on an experimental flag, this is the line item that tends to decide it. ## What is AuthPlane, and how is it different? AuthPlane is an open-source OAuth 2.1 authorization server built specifically for MCP. The server is AGPL-3.0, the SDKs are Apache-2.0. It ships as a single Go binary with an embedded admin UI and runs alongside your MCP server, validating tokens locally against the JWKS so nothing sits in your request path. The two differ in shape more than in quality. Keycloak is a general identity platform that added an MCP guide. AuthPlane is an MCP authorization server, so what would be features buried inside a larger system for Keycloak (audience binding, agent identity, protected-resource metadata, MCP SDK integration) are its entire job. On audience binding specifically, AuthPlane reads the `resource` parameter and stamps that exact URI into the token's audience whenever a grant targets a registered resource, matching on scheme, host, port, path, and trailing slash, with one audience per token. When a grant supplies no resource, the audience falls back to the issuer. The cost of that focus is maturity: AuthPlane is a v0.1.x project from a new org, and its docs don't pretend otherwise. ## Agent identity and delegation Keycloak has no MCP-specific agent identity model. It supports standard OAuth token exchange, and 26.7 added an experimental token-exchange delegation feature: a delegation scope that checks whether the requesting user is authorized to act on behalf of a target user. That's useful, and it's early. What it isn't is a first-class agent object with a stable identifier. AuthPlane models this directly. Tokens issued to a client registered as an agent carry an explicit `agent_id` and a delegation chain built on the RFC 8693 `act` claim, so a downstream MCP server can read the current actor without walking a nested tree. Non-agent traffic (service-to-service, admin) is issued without those claims, so your server can tell the two apart. One caveat applies to any product here: RFC 8693 treats the nested actors in a chain as informational, not as an enforced access-control path, and AuthPlane's chain nests up to five hops with an eight-entry flattened claim. So the value is attribution and audit, not a cryptographically enforced full chain. ## Spec currency: where both actually stand They land close here, and the precise version keeps anyone from overclaiming. Keycloak's guide currently reports "Partially Supported" for MCP 2025-11-25, the partial being RFC 8707, which its guide doesn't use even though the code ships it experimentally. AuthPlane targets 2025-11-25 as well, with audience binding on by default. To be fair to both: as of writing, neither has published support for the newer 2026-07-28 revision. Keycloak's guide still lists 2025-11-25 as the latest version it covers, and AuthPlane's docs still document 2025-11-25 too. So on spec version they're even, and the difference within 2025-11-25 is how each handles RFC 8707. ## Operational surface: a platform vs a binary Keycloak gives you a lot: realms, user stores, federation, clustering, authorization services, and broad protocol support, all valuable when human identity is part of the job. It's also a JVM platform with the configuration and operational footprint that implies. AuthPlane gives you one Go binary with an embedded admin UI and a narrow MCP scope. If you need the identity platform, Keycloak's breadth is a genuine advantage. If MCP authorization is the whole job, that breadth is surface you operate without using. ## AuthPlane vs Keycloak, side by side Keycloak cells are verified against its source code at the 26.7.1 tag, not only its guide, since the two disagree on Resource Indicators. {% table %} - Dimension - AuthPlane - Keycloak --- - Hosting - Self-hosted, single Go binary - Self-hosted, JVM identity platform --- - License - AGPL-3.0 server, Apache-2.0 SDKs - Apache-2.0 --- - Built for - MCP authorization and agent delegation - General identity (SSO, federation); MCP added recently --- - MCP support - Targets the 2025-11-25 spec - MCP guide since 26.5; guide reports 2025-11-25 partial; CIMD and Resource Indicators experimental --- - Resource Indicators (RFC 8707) - Supported by default, automatic audience binding - Experimental since 26.6 (off by default); MCP guide still documents the scope + Audience mapper workaround --- - Agent identity - Explicit `agent_id` + RFC 8693 chain on agent tokens - No MCP agent model; experimental token-exchange delegation (26.7) --- - Operational surface - Single binary, embedded admin UI - Realms, user stores, federation, clustering, policies --- - Maturity - Early, v0.1.x, new org - Mature, widely deployed, CNCF project {% /table %} ## When is Keycloak the right call? Keycloak is the better choice when identity is bigger than MCP for you. Specifically: - You already run Keycloak and have the operational expertise in house. - You need a full human-identity platform, with SSO, federation, and user management, and MCP is one use case inside it. - You can live with the manual mapper workaround the MCP guide documents (or with enabling the experimental Resource Indicators flag), plus the experimental status of CIMD and token-exchange delegation. - You want a long-established, broadly deployed open-source platform behind your auth. ## When is AuthPlane the right call? AuthPlane is the better choice when MCP authorization is the job and you want it agent-aware and small: - You want an MCP-focused authorization server without operating a full identity platform. - You want RFC 8707 audience binding on by default, not behind an experimental flag or per-server mappers. - You want an explicit `agent_id` and delegation chain represented in the tokens. - You want a single binary with an embedded admin UI and a small configuration surface. Both are open source and self-hosted, which makes this the cleanest head-to-head in the field: stand each one up against a staging MCP server for an afternoon and see which answers your requirements. If Keycloak's already in your stack, extending it can win on effort alone. If it isn't, and MCP is the job you're solving, AuthPlane is built for it. ## Frequently asked questions **Does Keycloak support RFC 8707 Resource Indicators for MCP?** Partly. Keycloak has shipped an experimental Resource Indicators feature since 26.6 (April 2026) that reads the `resource` parameter and binds the token audience from it, enabled with `--features=resource-indicators`. But it's off by default, subject to breaking changes, and requires the resource to map to a registered client. Keycloak's own MCP guide doesn't use it. The guide still lists RFC 8707 as "Not supported" and documents a manual workaround with a per-scope Audience mapper instead. AuthPlane supports RFC 8707 by default and binds the audience to the registered resource URI automatically. **Is Keycloak a good MCP authorization server?** It can be, especially if you already run it. Keycloak added a dedicated MCP guide in 26.5, experimental CIMD in 26.6, and experimental token-exchange delegation in 26.7. The main caveat is that its guide still reports only partial 2025-11-25 support, because it doesn't use the experimental Resource Indicators feature the code now ships. **Are AuthPlane and Keycloak both open source and self-hosted?** Yes. Keycloak is Apache-2.0. AuthPlane's server is AGPL-3.0 with Apache-2.0 SDKs. Both run inside your own environment. The difference is general-purpose identity versus a purpose-built MCP authorization server. **Does Keycloak support agent identity and delegation?** Keycloak supports standard OAuth token exchange and, in 26.7, an experimental token-exchange delegation feature that checks whether a user is authorized to act on behalf of another. It doesn't document a dedicated MCP agent identity model like AuthPlane's `agent_id` and actor-chain claims. **Is AuthPlane lighter to run than Keycloak?** In footprint, yes. AuthPlane is a single Go binary with an embedded admin UI and a narrow MCP scope. Keycloak is a full JVM identity platform with far more functionality and a correspondingly larger configuration and operational surface. Lighter isn't automatically better: if you need the platform, its breadth is why you're there. ## Sources *Primary sources and source code, accessed August 2026. Keycloak claims verified against the 26.7.1 release tag, not documentation alone.* - Keycloak, [Integrating with Model Context Protocol (MCP)](https://www.keycloak.org/securing-apps/mcp-authz-server): conformance table, CIMD flag, and the mapper workaround; note this guide still lists RFC 8707 as "Not supported." - Keycloak source, [Profile.java at tag 26.7.1](https://raw.githubusercontent.com/keycloak/keycloak/26.7.1/common/src/main/java/org/keycloak/common/Profile.java): `RESOURCE_INDICATORS` feature, flagged experimental. - Keycloak, [26.5.0 released](https://www.keycloak.org/2026/01/keycloak-2650-released) (Jan 2026): dedicated MCP integration guide. - Keycloak, [26.6.0 released](https://www.keycloak.org/2026/04/keycloak-2660-released) (Apr 2026): experimental CIMD support. - Keycloak, [26.7.0 released](https://www.keycloak.org/2026/07/keycloak-2670-released) (Jul 2026): experimental token-exchange delegation; Claude Code and VS Code integration. - Model Context Protocol, [Authorization specification, 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) (current). - IETF, [RFC 8707, Resource Indicators for OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc8707). - IETF, [RFC 8693, OAuth 2.0 Token Exchange](https://datatracker.ietf.org/doc/html/rfc8693). *Last updated: August 19, 2026. The MCP auth landscape moves fast. Keycloak's Resource Indicators feature may graduate from experimental and its MCP guide may be updated; verify feature flags and version numbers against vendor sources.*