MCP Authorization

The Model Context Protocol (MCP) connects AI agents to tools and data sources through MCP servers. An MCP server might expose tools that read files, query databases, send emails, or modify infrastructure. These are not low-risk operations — they need the same access control you would apply to any protected API.

Two problems exist on opposite sides of the same connection.

On the server side: your MCP server exposes capabilities that carry real consequences. Without access control, any MCP client that connects can invoke any tool. There is no way to say "this client can read data but not write it" or "this client can access the research tools but not the admin tools."

On the client side: MCP clients are the applications and AI hosts that connect to your MCP servers — tools like Claude Desktop, VS Code, or custom-built agent platforms. Without a way to represent and govern these clients, you cannot control which clients access which servers, and you cannot revoke a client's access when it is decommissioned or compromised.

What needs to be solved

Protect your MCP server

An MCP server without access control trusts every client equally. Any connected client can invoke any tool, access any resource, and perform any action the server exposes. There is no boundary between a read-only analytics tool and a destructive administrative operation.

• MCP server capabilities need to be represented as a protected resource. Each tool or group of tools the server exposes should map to a named permission. This allows access decisions to happen at the capability level, not at the server level.

• Access must be differentiated by caller. One MCP client might need access to all tools. Another might need only a subset. The MCP server should not make this decision on its own — it should validate that the caller has been granted the specific permissions required for the requested tool.

• Roles should map consumers to permissions. Rather than assigning permissions to each consumer individually, define roles that carry the appropriate permissions and assign consumers to those roles. This keeps access management scalable as the number of clients and tools grows.

Access a protected MCP server

On the other side of the connection, MCP clients need to be governed. Without a formal representation of each client, there is no way to control what it can access, track what it has done, or revoke its access.

• MCP clients need their own identity. Each MCP client — whether it is a commercial AI host, a custom-built agent platform, or a developer tool — needs to be registered and given credentials. Anonymous or unregistered clients should not be able to connect to protected MCP servers.

• Each client's access must be scoped to specific resources. When registering an MCP client, you should be able to define which MCP servers it can access and which scopes it can request. A client registered for one MCP server should not be able to obtain tokens for another.

• The MCP client acts as the actor, not the subject. The MCP client is the intermediary — users and agents work through it to reach the MCP server. The token the MCP server receives should identify who is making the request (the user or agent) and which MCP client is acting on their behalf. This preserves accountability: the MCP server knows both what is being requested and who is behind it.

• Client access must be revocable. When an MCP client is decommissioned, compromised, or simply no longer trusted, its access should be revoked in one place. All tokens issued through that client should stop being accepted by the MCP servers it was connected to.

How to solve it

Represent the MCP server as a protected resource

Register your MCP server's capabilities as a resource in ThunderID. Each tool or group of tools becomes a scope — a named permission that describes what the caller is allowed to invoke. When an MCP client requests access, ThunderID issues a token that contains only the scopes that client has been granted. The MCP server validates the token on every request and checks whether the required scope is present before executing the tool.

1. Define the resource and its scopes. Register the MCP server as a resource server in ThunderID and define a scope for each tool or group of tools you want to protect independently. See the Resource Servers guide.
2. Create roles and assign permissions. Create roles that map to how your MCP clients should interact with the server. A role bundles one or more scopes into a reusable access level. One role might grant access to read-only tools, while another includes tools that modify data or infrastructure. See Authorization.
3. Assign consumers to roles. Bind the consumers — users, applications, or agents — to the appropriate roles. Users can be assigned directly or through groups. Applications receive their role assignment at registration, and agents receive theirs through group memberships. See Manage Users, Manage Applications, and Manage Agents.
4. Validate on every request. The MCP server checks the incoming token for the required scope before executing any tool. If the scope is missing, the request is denied. The MCP server never makes the authorization decision itself — it simply enforces what ThunderID has already decided. See Tokens.

Register and govern MCP clients

MCP clients need an identity in ThunderID before they can request tokens. How you register the client depends on what it is.

1. Register the MCP client as an agent. If the MCP client is an AI agent, register it as an agent in ThunderID. This gives it a Client ID and Client Secret — an identity it uses to authenticate with ThunderID when requesting tokens. See Manage Agents.
2. Register the MCP client as an application. If the MCP client is a non-agent application — such as Claude Desktop, VS Code, or a custom-built tool — register it as an application. See Manage Applications.
3. Register dynamically via DCR. MCP clients that support the MCP Authorization Specification can register themselves automatically. The client discovers the authorization server through the MCP server's protected resource metadata endpoint, then registers via ThunderID's DCR endpoint. ThunderID issues client credentials that the MCP client uses for all subsequent token requests. See Dynamic Client Registration.
4. Scope the client to specific MCP servers. Assign the client roles that grant access to the scopes defined on the MCP servers it needs to reach. A client registered to access one MCP server's scopes will not be able to obtain tokens valid for another. See Authorization.
5. Request tokens on behalf of users or agents. The MCP client authenticates with its own credentials and requests a token for the target MCP server. The issued token identifies the user or agent as the subject and the MCP client as the actor — so the MCP server knows both who is making the request and which client is facilitating it. See Agent Authentication for token exchange patterns.
6. Revoke access when needed. When an MCP client is decommissioned or compromised, disable or delete the agent or application in ThunderID. Tokens issued through that client will no longer be valid.

Coming soon

ThunderID will introduce first-class MCP client registration with client ID metadata support, allowing MCP servers to pass their own identity context during client registration. This will enable tighter binding between MCP clients and the servers they are authorized to access.

Related Guides

• Manage Agents — Create and manage agent identities with OAuth 2.0 credentials
• Agent Authentication — M2M and OBO token flows for agents
• MCP Server — Set up the ThunderID MCP server in VS Code and other MCP-compatible clients
• Dynamic Client Registration — Register clients dynamically via the DCR endpoint