AI Agent Security · MCP Authorization
Keycloak as the authorization server for MCP
The Model Context Protocol expects remote MCP servers to be protected with OAuth. We set Keycloak up as that authorization server — discovery, PKCE, client registration and tokens bound to the right MCP server — and fill the gaps where the spec and Keycloak differ.
- OAuth 2.1 with PKCE
- Discovery and client registration
- Tokens scoped per MCP server
Standards & integrations
- OAuth 2.1
- PKCE
- RFC 8414 metadata
- RFC 9728 resource metadata
- RFC 7591 dynamic registration
- RFC 8707 resource indicators
Overview
What the MCP authorization spec asks for
Under the MCP authorization specification, a remote MCP server acts as an OAuth resource server. It publishes metadata pointing clients to an authorization server, and clients obtain tokens with the authorization code flow and PKCE, often registering themselves on the fly. Keycloak covers most of this natively: discovery metadata, PKCE, dynamic client registration with policies, and token validation. Where the spec moves faster than Keycloak — binding tokens to a specific resource, or newer client registration methods — we close the gap with configuration, a gateway or an extension.
What we deliver
- MCP authorization architecture for your servers and clients
- Keycloak realm with discovery, PKCE and registration policies
- Audience and scope design per MCP server and tool
- Resource metadata and token validation in each MCP server
- Gap closures for spec features Keycloak doesn't cover natively
- End-to-end test suite with real MCP clients
Capabilities
What MCP Authorization covers
Configured, tested and documented on upstream Keycloak — then handed over or operated by us.
Discovery end to end
Each MCP server publishes protected resource metadata pointing to your Keycloak realm, and Keycloak publishes the authorization server metadata clients expect.
Controlled client registration
Dynamic client registration is open to MCP clients, with Keycloak's registration policies limiting trusted hosts, redirect URIs and scopes.
PKCE enforced
Client policies require PKCE with S256 for every MCP client, so intercepted authorization codes are useless.
Tokens bound to one MCP server
Each MCP server has its own audience, set through client scopes and audience mappers, so a token for one server can't be replayed against another.
Tool-level authorization
Scopes per tool, or Keycloak Authorization Services policies, decide which tools a user or agent may call on each server.
Validation inside your servers
We add token validation to your MCP servers — signature, issuer, audience, expiry and scope — using the SDKs and middleware you already use.
Compatibility
MCP spec requirements and Keycloak
How each requirement is met. Both the spec and Keycloak move quickly, so we recheck this against your exact version.
| Platform | Integration | Notes |
|---|---|---|
| Authorization code with PKCE | Native | S256 PKCE, enforceable per client through client policies. |
| Authorization server metadata | Native | Published per realm under the well-known discovery endpoints. |
| Protected resource metadata (RFC 9728) | MCP server configuration | Served by each MCP server, pointing clients to the Keycloak realm. |
| Dynamic client registration (RFC 7591) | Native, with policies | Anonymous registration limited by client registration policies. |
| Client ID metadata documents | Gateway or extension | A newer registration option in the spec; support depends on your Keycloak version. |
| Resource indicators (RFC 8707) | Configuration or extension | Audience-bound tokens through client scopes and audience mappers; native handling varies by version. |
| Token validation | Native (JWKS or introspection) | MCP servers check signature, issuer, audience, expiry and scope. |
| Token revocation | Native | Revocation endpoint combined with short token lifetimes. |
How it works
From first call to production
Review servers and clients
We list your MCP servers, the tools they expose and the clients that will connect, and agree who may use which tools.
Configure realm, registration and audiences
The Keycloak realm, registration policies, client scopes and audiences are defined as code, with gaps in spec support closed where needed.
Wire servers and test with real clients
Each MCP server gets resource metadata and token validation, then we test sign-in and tool calls end to end with the clients you use.
Use cases
Where teams put it to work
Internal MCP servers over company systems
Expose CRM, ticketing or document tools to AI clients without giving any client more access than its user has.
MCP servers for customers and partners
Offer MCP access to your product with the same identities, consent and MFA as your web application.
Platform teams standardising MCP
Give every team a single, reviewed pattern for protecting new MCP servers instead of each one inventing its own.
FAQ
MCP Authorization questions, answered
Does Keycloak support the MCP authorization spec?
Much of it natively: authorization code with PKCE, authorization server metadata and dynamic client registration. Some newer pieces, such as resource indicators and client ID metadata documents, aren't handled the way the spec describes in every Keycloak version. We check yours and fill gaps with configuration, a gateway or an extension.
Is open dynamic client registration safe?
Only with guardrails. Keycloak's client registration policies control who can register, which redirect URIs and scopes are allowed, and how many clients can be created. We tune them for the clients you expect.
Where does the protected resource metadata live?
On the MCP server. It's a small JSON document that tells clients which authorization server to use; we add it to each server alongside token validation.
Ready to roll out MCP Authorization?
Walk us through your requirements on a free strategy call. We'll come back with an architecture, a delivery plan and a fixed scope.