Using Keycloak as an MCP authorization server

Introduction

MCP, or Model Context Protocol, is an open standard protocol for connecting AI applications with external systems. With MCP, AI agents can access local files, databases, search engines, enterprise systems, workflows, and other resources through a unified interface.

Why MCP authorization matters

As the resources handled by MCP servers become more important, authorization becomes increasingly critical. We need to control who is allowed to perform which operations, from which client, and on which resources. When AI agents access calendars, internal databases, ticket management systems, source code repositories, customer information, and similar resources, simply exposing an MCP server is not sufficient. Even if a user has been authenticated, that does not mean every operation should be authorized.

This becomes especially important in enterprise use cases. For example, an organization cannot unconditionally allow access to internal MCP servers from unmanaged or unapproved agents, or from AI agents that employees are using independently. Even if the user is a full-time employee of the company, it is still necessary to determine whether the agent is a trusted client, which department or business purpose it is being used for, and what scope of data and operations should be authorized.

This is why the MCP specification includes an Authorization section. The MCP 2026-07-28 Authorization specification defines authorization flows for HTTP-based transports and references standards such as OAuth 2.1, OAuth 2.0 Authorization Server Metadata, Dynamic Client Registration, Protected Resource Metadata, and OAuth Client ID Metadata Document.

In MCP, authorization is the mechanism by which an MCP client obtains an appropriate access token when accessing an MCP server, and then uses that token to access protected resources. MCP authorization primarily involves the following three parties.

A protected MCP server using an HTTP-based transport also needs an authorization server, which may be co-hosted with the MCP server or operated separately.

So, should you implement an MCP authorization server yourself? In many cases, the answer is no. Implementing an authorization server means satisfying OAuth 2.1 and a number of related standards and security requirements. A custom implementation carries significant security responsibility, and in practice, it is usually more realistic to rely on an existing IAM product. The rest of this article examines how Keycloak maps to these requirements.

Keycloak as an MCP authorization server

Keycloak is an open source Identity and Access Management, or IAM, solution. It provides a foundation for adding authentication and authorization capabilities to applications and services, and supports standard protocols such as OpenID Connect, OAuth, and SAML. Keycloak has been developed as an open source IAM project since around 2014. In 2023, it was accepted into the Cloud Native Computing Foundation, or CNCF, under the Linux Foundation as an Incubating maturity level project.

Keycloak provides broad support for the MCP Authorization specification. The support status by MCP version is as follows.

The following table summarizes how the relevant standards referenced by the MCP Authorization specification are supported by Keycloak.

The support status for MCP Authorization Extensions is as follows.

In addition to supporting OAuth 2.1, Keycloak experimentally supports CIMD.*2 As a result, Keycloak already provides many of the capabilities required for an MCP authorization server.

Looking ahead, the roadmap around the 26.8.0 milestone, which is scheduled for release at the end of September 2026, is expected to include promoting CIMD to preview status, tracking updates to the CIMD specification, promoting Resource Indicators to preview status, and continuing to align with the MCP Authorization specification.*3

*1 Although RFC 8707 Resource Indicators are not supported in the official release, the Keycloak documentation describes a workaround using OAuth 2.0 scopes: Token audience binding and validation. In addition, the initial implementation PR, Initial experimental support for Resource Indicators #46763, has already been merged.

*2 To use CIMD in Keycloak, enable the feature with --features=cimd and configure Client Policies. For details on configuring Client Policies, see the official guide: Setting up the client profile for OAuth Client ID Metadata Document.

*3 Keycloak's review of MCP 2026-07-28 resulted in documentation updates rather than additional implementation changes. Keycloak 26.7 remains partially supported because it does not natively support RFC 8707 Resource Indicators; the workaround described in *1 applies.

*4 This is currently being addressed in Issue #48818.

*5 The OAuth Client Credentials Extension, draft, requests a token for an MCP server by adding the resource parameter to client_credentials. Keycloak supports the standard Client Credentials Grant, but as of 26.7, it does not support OAuth 2.0 Resource Indicators, which require the resource parameter.

References:

• Authorization - Model Context Protocol

• MCP Authorization Extensions

• Integrating with Model Context Protocol (MCP)

Conclusion

A protected MCP server using an HTTP-based transport needs an authorization architecture that covers token issuance, client registration, audience validation, and the other requirements of the relevant MCP specification.

Keycloak provides support for many of these requirements, although the availability and maturity of individual capabilities vary by Keycloak and MCP version. Teams evaluating it for this role should check which features are supported, experimental, preview, or planned in the versions they intend to deploy.