MCP security: Implementing robust authentication and authorization

The Model Context Protocol (MCP) is increasingly relevant in today’s agentic AI ecosystem because it standardizes how AI agents access tools, data sources, and external systems. As agents move from passive chatbots to autonomous actors capable of planning and executing tasks, MCP provides a structured, interoperable interface layer that enables tool invocation with enhanced security, controlled access to external systems, and more consistent policy enforcement across heterogeneous environments.. In essence, MCP forms the connective tissue between LLM-driven reasoning and real-world system execution in modern agent architectures.

As discussed in our previous blog, MCP security: The current situation, we highlighted the growing security risks associated with using MCP, detailing recent real-world vulnerabilities, including prompt injection attacks in GitHub integrations, sandbox-escape flaws in Anthropic's FileSystem server, and widespread misconfigurations of exposed servers. 

In this blog post we're taking a look at authentication and authorization mechanisms needed to make secure connections between MCP servers, clients, and other components within the agentic systems. Since MCP acts as a powerful bridge to sensitive enterprise data, relying on implicit trust or unverified connections is no longer viable. We'll explore how to implement robust identity verification and enforce granular access controls, providing assurance that your LLMs strictly adhere to the principle of least privilege when interacting with external tools.

Modern MCP specifications define that MCP servers act as OAuth 2.1 resource servers, while MCP hosts  act as OAuth clients on behalf of the user. As a security measure, an MCP server should require a valid OAuth access token for any request. Following OAuth 2.1 provides the most up-to-date protections. For example, Proof Key for Code Exchange (PKCE) is mandatory for authorization code flows.

Protecting your MCP server requires robust authentication to handle user login and consent. Rather than a one-size-fits-all OAuth integration, however, the optimal authorization strategy depends heavily on your deployment scenario:

• Open MCP ecosystems (the CIMD approach): For standalone MCP servers expected to integrate with a wide variety of third-party AI clients where there is no pre-existing relationship, the MCP specification is shifting. While the protocol initially relied on Dynamic Client Registration (DCR), DCR places a heavy burden on servers to manage unbounded client databases and trust self-asserted metadata. Instead, the community is transitioning toward Client ID Metadata Documents (CIMD) (SEP-991) as the recommended default. With CIMD, clients simply host a static JSON metadata file at an HTTPS URL. This provides a decentralized way for servers to verify client identity and establish trust dynamically without requiring prior coordination.
• Enterprise Kubernetes/Red Hat OpenShift environments: In tightly controlled containerized environments, relying on individual client registration, whether DCR or CIMD, is often impractical and unnecessary. The best practice in these scenarios is to offload authentication to an external OpenID Connect (OIDC) provider and utilize OAuth Token Exchange. This allows the platform's ingress or API gateway to centrally verify the user, enhancing security by exchanging the initial token for an internal token that grants the MCP server-scoped access to backend resources.
• Internal/service-to-service deployments: For MCP servers that don't directly face end users, but act as backend utilities for internal enterprise agents, traditional user login and consent flows can be replaced entirely. In these closed ecosystems, connection security should focus on using mutual TLS (mTLS) or secure machine-to-machine (M2M) OAuth client credentials.

Authorization server integration: Keycloak example

There are 2 approaches to handling OAuth in MCP servers: embedded or external authorization server. Embedding means your MCP server has its own identity provider (IdP) internally and presents login options and issue tokens itself. This can work, but it significantly increases complexity. Essentially, you’re building an OAuth provider from scratch.

The preferred approach in enterprise contexts is to delegate to an external OAuth/OIDC provider. In this model, the MCP server relies on an external authorization server, for example, the Red Hat build of Keycloak, to handle the heavy lifting of authentication and token issuance. The MCP server then simply acts as an OAuth relying party, verifying tokens and enforcing scope and role checks on incoming requests. 

This separation follows best practices and lets you reuse robust identity infrastructure such as enterprise single sign-on and multifactor authentication. This is essential for aligning with Red Hat’s security value proposition to customers and partners.

For example, when using Keycloak, you'll register your MCP server as a confidential host in Keycloak and configure Keycloak’s authorization server metadata endpoint in your MCP server. When an unauthenticated request is made to the MCP server, it responds with a 401 and a WWW-Authenticate: resource_metadata header pointing to its metadata URL.

The MCP host, or agent, will discover the Keycloak endpoints, such as auth URL or token URL, from that metadata and initiate an OAuth 2.1 authorization code flow. Keycloak handles user login and consent, then issues an access token back to the MCP host, which in turn calls the MCP server with the token. The MCP server must validate the token, checking signature, expiry, issuer, and scopes and audience.

You should also make sure that your MCP server only accepts tokens intended for itself. For example, verify the token’s audience or a resource indicator claim to prevent misuse. Recent updates to the MCP spec specifically recommend resource indicators (RFC 8707) for this purpose, so tokens are scoped to one MCP server and cannot be replayed on another.

Consent and scoping

It is important that auth implementations are designed such that users explicitly consent to what the MCP server can do. OAuth scopes are designed to be granular. For example, if your MCP server exposes a “sendEmail” tool and a “readContacts” tool, define separate scopes, such as email.send and contacts.read. Only allow the server to perform an action if the token grants the corresponding scope. 

This enforces least privilege and limits impact if the access token is stolen or misplaced. On initial connection, the user should see a consent screen provided by Keycloak or your IdP listing the scopes and tools the agent is requesting, and they must approve it. The MCP server should also implement enforcement of scope checks on each request. For example, if a request tries to invoke a tool not allowed by the token’s scopes, it will reject it with 403 Forbidden.

Avoiding "confused deputy" and impersonation attacks

A primary risk in an OAuth-based MCP flow is the "confused deputy" problem. For instance, if your MCP server uses a single static OAuth client ID to access a third-party API, and it forwards user auth flows incorrectly, an attacker could trick it into obtaining tokens not intended for it.

As an MCP server developer, follow the official MCP authorization spec guidelines to prevent token redirect exploits and ensure that user consent is always tied to the correct requesting client. Use state parameters and redirect URI validation to thwart hijacking. Additionally, consider audience restriction as noted above: the token your server accepts is expected to include an identifier for your server or resource so it cannot be replayed elsewhere.

Integrate Role-Based Access Control (RBAC)

Beyond OAuth scopes, enterprise deployments often require finer-grained authorization. It’s a good practice to map OAuth tokens to internal roles and permissions. For example, a token might convey the user’s roles in its claims. If using Keycloak, you can include realm or client roles in the JSON web token (JWT). Your MCP server can then allow certain sensitive tools only to users with an admin role.

This adds defense in depth, which is another core element of Red Hat’s security principles. Implement token claim checking in middleware before tool execution—Keycloak integration makes this straightforward, as it can issue JWTs with custom claims for user roles or group membership.

Secure token handling

Treat access tokens and refresh tokens as secrets. Store them server-side only as needed and with strong encryption. Make sure clients and servers implement the secure token storage guidance in OAuth 2.1 section 7.1.

If your MCP server needs to perform onward API calls using user tokens, avoid long-lived tokens. Long-lived tokens remain valid for an extended period beyond reasonable use such as days, months, or years. Use short expiration and leverage refresh tokens if the user session is long and secure refresh flows properly.

Never log tokens or expose them to the client user interface (UI) or large language model (LLM). Invalidation and revocation should be honored—if the user revokes access via the IdP, the MCP server should detect token revocation using JWT introspection or by trying to use a token and handling a 401 from downstream. Consider using sender-constrained tokens such as mTLS or demonstrating proof-of-possession (DPoP) for high-security scenarios so that stolen tokens are useless without the client’s key.

Here's an example external auth flow. The following shows how an MCP server might be configured to use Keycloak as an external auth provider (OIDC). This illustrates mapping environment settings for OAuth:

# (Example configuration for using Keycloak OIDC in an MCP server). The MCP server would use these to discover JWKS for token validation and OAuth endpoints.undefinedOIDC_ISSUER_URL="https://keycloak.example.com/realms/MyRealm"undefinedOIDC_CLIENT_ID="mcp-server-id"undefinedOIDC_CLIENT_SECRET="<client-secret>"

In code, you can use a library to validate JWTs against Keycloak’s JSON web key set (JWKS) and check claims.

from jose import jwt # using python-jose for exampleundefinedjwks = requests.get(f"{OIDC_ISSUER_URL}/protocol/openid-connect/undefinedcerts").json()undefinedtoken = get_auth_header_token(request)undefinedclaims = jwt.decode(token, jwks) # verifies signature and expiryundefinedif claims["aud"] != "mcp-server-id":undefinedraise Unauthorized("Token audience mismatch")undefinedif "email.send" not in claims.get("scope",undefined""):

raise Forbidden("Scope email.send required to use this tool")

This is just an illustration—in practice use well-tested JWT validation libraries or frameworks that can also verify the issuer. More information is available in the Keycloak Getting Started Guide and the Server Administration Pages, which discuss how to register a new OIDC client in Keycloak. The key point is to validate every request’s token and enforce scopes and permissions programmatically.

Final thoughts

By integrating with a robust identity provider and following OAuth 2.1 flows, you can establish a strong authentication and authorization foundation for your MCP server. Adopting modern standards like OAuth 2.1, using external identity providers such as Keycloak, and enforcing strict, granular access through scopes, helps you build an essential layer of defense against the increasingly complicated  threat landscape of the agentic AI ecosystem.