Design MCP Authorization for APIs

AI Agents and API Access

AI agents provide goal-oriented experiences for users, where a human sets an objective using natural language and the agent can choose actions to fulfill that objective. An AI agent uses a large language model (LLM) to process user input and determine actions. To fulfill the user's objective, these actions can operate on local resources, or call remote resource servers like web APIs.

AI agents could call APIs in many use cases. For example, employees might use AI agents to conveniently access authorized corporate information. For organizations that use APIs to expose and monetize information, AI agents could become a new category of clients that can extend the reach of APIs.

Solutions must support secure API requests from AI agents, so that actions taken on behalf of users are properly authenticated and authorized. This article explains the security building blocks that organizations can use to enable the correct API access.

Model Context Protocol

AI technologies evolve rapidly. The Model Context Protocol (MCP) is an example of an AI technology that proposes standardized, interoperable and scalable ways to connect AI agents to data sources and tools. AI agents can use MCP clients that connect to remote MCP servers that provide API entry points.

The MCP draft authorization specification provides a security design based on the OAuth 2.1 Authorization Framework. OAuth provides an API security solution that can work for MCP clients and also for any other API clients. OAuth provides building blocks to help enable the following behaviors for MCP clients.

• Zero delay onboarding without human actions.
• User onboarding and user authentication.
• Human approval of the areas of data and the operations the MCP clients can access.
• Providing a restricted API message credential (access token) with which MCP clients call APIs.
• Ensuring the correct API authorization to restrict access.

API Architectures

To expose API data to MCP clients, organizations may need to provide MCP servers that implement a Streamable HTTP Transport. These HTTPS entry points must support authenticated API requests and implement authorization policies that align with AI security architecture principles.

MCP servers can be a thin proxy layer, like an API gateway or utility API, that forwards requests to existing APIs. The following diagram shows an architecture where various types of clients use access tokens to call APIs. Both MCP clients and MCP servers need to use access tokens securely.

AI agents present new challenges when securing API requests, especially in dynamic or untrusted environments. Organizations may have no control over AI agents or MCP clients. When exposing APIs to MCP clients, organizations risk exposing potential sensitive information, like intellectual property (IP), data owned by business partners, customers or users, to unauthorized parties. Therefore it is especially important that APIs correctly authorize access to data before granting AI agents access.

Securing the MCP Server

The following diagram illustrates a recommended token flow for the connection from an MCP client to the MCP server. The client runs OAuth flows and retrieves an opaque (or reference) access token that does not reveal any sensitive API information to the MCP client. The Phantom Token Pattern then delivers a JWT access token to the MCP server. The MCP server validates the JWT access token and, in particular, it rejects access tokens that do not contain the MCP server's audience. An MCP server could also require particular scopes from MCP clients.

MCP Authorization Lifecycle

To get an access token and connect to the MCP server, an MCP client follows the steps from the MCP authorization specification and runs OAuth flows that enable zero-delay onboarding. The following diagram visualizes the high level flow.

Before you implement the MCP authorization flow, do some early thinking about threats, since there are risks that untrusted MCP clients or MCP servers could potentially gain unexpected access to sensitive data.

• A malicious MCP client could try to register as an OAuth client and then authenticate a genuine user.
• A malicious MCP client could try to impersonate a trusted MCP client and then authenticate a genuine user.
• A malicious MCP server could try to impersonate a genuine MCP server, so that a trusted MCP client runs OAuth flows and sends it access tokens.

At the time of writing, many MCP-related technologies are adding support for MCP authorization to enable API access. The following sections explain the main parts of the flow and the security considerations at each stage.

Discovery

When an MCP client first attempts to access a secured MCP server, the MCP server returns an HTTP 401 response with a WWW-Authenticate response header that includes an OAuth Protected Resource Metadata URL for the MCP server.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error='"invalid_token", resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

The MCP client parses the resource_metadata value from the response header and fetches metadata from that endpoint. The metadata response provides the base URL of the authorization server.

{
    "resource": "https://mcp.example.com",
    "resource_name": "MCP Server",
    "authorization_servers": [
        "https://login.example.com"
    ]
}

The MCP client appends the path /.well-known/oauth-authorization-server to the authorization server base URL and calls that URL to fetch information about how to integrate with the authorization server.

{
    "issuer": "https://login.example.com",
    "registration_endpoint": "https://login.example.com/oauth/v2/oauth-registration",
    "authorization_endpoint": "https://login.example.com/oauth/v2/oauth-authorize",
    "token_endpoint": "https://login.example.com/oauth/v2/oauth-token",
    ...
}

Client Registration

To get an access token and call APIs, the MCP client requires an OAuth client registration at the authorization server. In some use cases it may be possible to pre-register static clients. In other use cases, MCP clients may need to create an OAuth client at runtime. For that, MCP clients use the Dynamic Client Registration (DCR) standard.

When APIs expose secure data, you need a mechanism to establish trust so that some MCP clients and users (like those from business partners) gain access whereas others do not. To establish trust, DCR can require an initial access token that a client can retrieve in various ways. See the DCR Authentication Methods article for further information.

You may not be able to control the DCR code used by an MCP client, so you might decide to allow any MCP client to register at the authorization server without a client credential, as in the following example, where the client requests a client scope of trades/read, to gain access to financial trading information from APIs.

POST /oauth/v2/oauth-registration HTTP/1.1
Host: login.example.com
Content-Type: application/json
Accept: application/json
{
    "client_name": "Simple OAuth MCP Client",
    "grant_types": [
        "authorization_code"
    ],
    "redirect_uris": [
        "https://www.aiagent.example/callback"
    ],
    "response_types": [
        "code"
    ],
    "scope": "trades/read",
    "token_endpoint_auth_method": "client_secret_post"
}

Dynamic clients have many potential client settings, some of which the client does not provide. The authorization server should dictate any security-related settings. To do so, the authorization server should apply a DCR policy. The policy should require the client to use Proof Key for Code Exchange (PKCE), limit the allowed scopes, set the audiences and lifetimes of access tokens, and decide whether to issue refresh tokens to the MCP client.

The authorization server stores dynamic clients in a data source. You could use your authorization server’s features to store MCP clients in a dedicated tenant, realm, or profile, to separate them from more trusted OAuth clients. The authorization server then returns a registration response that includes the dynamic client's settings and assigns each dynamic client a distinct client credential.

The following DCR response shows some example client settings that include a client secret, a short access token lifetime, and no refresh token details. The MCP client should persist its client ID and client credential and use them on subsequent OAuth operations.

{
    "access_token_ttl": 900,
    "client_id": "01e43975-ad69-4206-ae05-8b8753d1ced6",
    "client_id_issued_at": 1749822290,
    "client_name": "Simple OAuth MCP Client",
    "client_secret": "ckuaoh0fkNom9ZE8kAheu5aDqOsfW4IF6FmEkrTe0v0",
    "client_secret_expires_at": 0,
    "default_acr_values": [
        "urn:se:curity:authentication:email:email"
    ],
    "grant_types": [
        "authorization_code"
    ],
    "post_logout_redirect_uris": [],
    "redirect_uris": [
        "https://www.aiagent.example/callback"
    ],
    "require_proof_key": true,
    "requires_consent": true,
    "response_types": [
        "code"
    ],
    "scope": "trades/read",
    "subject_type": "public",
    "token_endpoint_auth_method": "client_secret_post",
    "token_endpoint_auth_methods": [
        "client_secret_post"
    ]
}

MCP clients run within an MCP host application on various platforms, like console applications, web applications, desktop applications or mobile applications. MCP clients that run within web application hosts typically cannot call your MCP server directly due to cross-origin restrictions, and instead do so via a backend component like an API. For any environment, the client credential is distinct per user and therefore improves security.

User Onboarding, Authorization, and Consent

In some cases, an administrator might pre-create authorized user accounts in the authorization server so that only AI agents that those users operate can gain API access to sensitive data. In other cases, genuine users might use a self-signup flow and provide Know Your Customer (KYC) information, along with a user-level proof like a one-time password from keyfobs given only to authorized users. Some user onboarding designs might require custom registration flows using the authorization server's extensibility features.

With OAuth's design, you should have full control over user-level behaviors, since user registration, user authentication, and user consent are all externalized from the MCP client's implementation. Instead, the MCP client only needs to run a code flow and you use the authorization server to control the user-level experience.

The flow can use built-in authentication methods or custom ones that you develop using the authorization server's SDK. The code flow can also require users to consent to the AI agent's requested level of API access.

Access Tokens

When a code flow completes, the MCP client receives an authorization code that it can redeem for an access token with which to call the MCP server. To do so, the dynamic client sends the authorization code and its client credential and receives a token response. The following example response contains a short-lived opaque access token and no refresh token. The MCP client sends the opaque access token on every subsequent request to the MCP server.

{
    "access_token": "_0XBPWQQ_2fb1bc61-0e98-413c-a44d-d8a46d3bd2f2",
    "expires_in": 900,
    "scope": "trades/read",
    "token_type": "bearer"
}

When issuing access tokens, take special care over the data that MCP clients can access, since some types of data may require you to comply with regulations in areas like data sovereignty and personally identifiable infomation (PII). Do not issue JWT access tokens to AI agents, since they are easily readable and could disclose PII or other data intended only for APIs. Use the following techniques to issue secure, least-privilege and short-lived access tokens.

• Issue opaque access tokens to AI agents, so that they cannot read confidential token data intended for APIs.
• Use audience restrictions so that access tokens for MCP clients are only accepted at MCP server entry points.
• Issue scoped access tokens to restrict the areas of data an AI agent can access, and prefer read-only scopes.
• Use claims like user, role, tenant, and country identifiers to lock down user-level access tokens.
• Use a short lifetime for access tokens issued to AI agents.

Audience restrictions should ensure that access tokens from MCP clients only pass validation at the MCP server. Other API entry points should reject access tokens from MCP clients. The MCP server can use OAuth Token Exchange to get a new access token before calling upstream APIs, to change the audience of the access token. The MCP server can also downscope or upscope the access token.

Upstream APIs should then validate access tokens on every request and implement the main resouce authorization. To validate access tokens correctly, APIs should follow JWT Security Best Practices. The API must then use scopes and claims to implement the correct authorization rules and restrict access to sensitive data.

MCP Tools and API Sessions

Once the MCP client has an access token it completes its streamable HTTP connection to the MCP server and the server uses Server Side Events (SSE) to return data to the client in the JSON-RPC response format. The following example response payload is for a request from the MCP client for a list of the server's MCP tools.

HTTP/1.1 200 OK
Content-Type: text/event-stream

event: message
data: {"result":{"tools":[{"name":"fetch-trades","description":"A tool to fetch secured information about financial trades","inputSchema":{"type":"object"}}]},"jsonrpc":"2.0","id":2}

The user can instruct the AI agent to run tools that initiate requests to the MCP server, where those tools can call upstream APIs. In future, a typical MCP client session with an organization's APIs might use steps similar to those listed below.

• The MCP client runs an initial OAuth flow to connect to the MCP server.
• The MCP client requests an initial scope like mcp.
• The MCP client gets a list of tools for which the user is authorized.
• The user runs a tool, for example to get information about authorized financial trades.
• The MCP server returns an insufficient_scope response to the MCP client.
• The MCP client run a new OAuth flow to request an access token with the required scope.
• The user authenticates with Single Sign-On and consents to the MCP client's use of that scope.

OAuth-secured APIs return a response of the following form to inform MCP clients of the scopes they need to request. The MCP client then needs to terminate its connection, get a new access token and reconnect.

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope", scope="trades/read"

Another event that can cause MCP clients to need to renew their connection with the MCP server is access token expiry. When the MCP client's access token expires, MCP servers should again return their HTTP 401 response. If the MCP client has a refresh token it can silently renew its access token without impacting the user. Otherwise, the MCP client should consider the user's session expired and present the user with an option to re-authenticate.

Federation

When users interact with an AI agent, its MCP clients can connect to MCP servers from multiple organizations. According to the Token Handling section of the draft MCP authorization specification (and OAuth best security practices), each MCP server must only accept access tokens from trusted authorization servers, which is most likely a single authorization server under the organization's control. To get a correct access token for multiple MCP servers in different security domains - that is, from different organizations - the AI agent needs to trigger a new OAuth flow at each organization's authorization server.

In cases where employees use AI agents to utilize the tools of third-party MCP servers, enterprise administrators should be able to enforce their organizational login policy at various providers of MCP servers. To do so, the corporate authorization server could act as an External Identity Provider (IDP) to the MCP provider's authorization server. In a typical flow, the authorization server of the MCP server provider is likely to first prompt for a corporate email address, then detect the organization from the email suffix, then route to the corporate authorization server. This type of login also enables Single-Sign On to improve user experiences.

In future, third-party providers may enable AI agents to find and use APIs from other organizations, such as those for a particular industry sector. As MCP solutions evolve, additional techniques could enable the use of cross-organization APIs with the correct access tokens.

• An MCP server might transfer an MCP client to an external MCP server so that the client can get a correct external access token and invoke a tool at the external MCP server.
• When organizations trust each other, an MCP client might instead remain at a single MCP server, that uses token exchange to get tokens from an external organization and call its APIs.

Hardening MCP Authorization

The current draft of the MCP authorization specification could result in MCP clients and MCP servers that implement only basic OAuth 2.1 flows. For example, AI agents in user-facing applications might run as public clients that do not store tokens securely, or MCP servers might not verify an MCP client with a high level of assurance. For APIs that expose high worth data, those behaviors could introduce unacceptable risks.

OAuth can go beyond the recommendations in the draft MCP authorization specification to provide high security ecosystems. For example, organizations in particular industries could use financial-grade techniques to develop high security AI agents and MCP servers using techniques from hardened profiles like Open Banking or other open secure ecosystems.

The following techniques would provide strong security guarantees, where each client and server uses the strongest security to prove its non-human identity (NHI) to recipients.

• Authorization servers could require Hardened DCR, where a third-party authority approves AI agents.
• Web AI agents could provide guarantees that they follow Web Best Practices and use strong browser defenses.
• Mobile AI agents could provide guarantees that they follow Mobile Best Practices and use application attestation.
• All cross-organization MCP requests could be sent by APIs that use Sender-constrained Access Tokens.

Example Deployment

The Implementing MCP Authorization for APIs code example provides an end-to-end deployment that uses MCP authorization. An MCP client calls a stateless MCP server that acts as a proxy to an existing OAuth-secured API. You can run the example on a local computer and connect any standards-based MCP client to the MCP server, to enable secured AI agent access to APIs.

The example shows how to provide a secured MCP server entry point and issue opaque access tokens to MCP clients. The MCP server receives a JWT access token and validates the token to ensure that it meets the MCP server's requirements. The MCP server then invokes MCP tool logic to call the upstream API. The logic uses token exchange to get a new access token with a different audience, suitable for the upstream API.

In particular, the example shows how to use the Curity Identity Server to take control over security at each stage of the MCP authorization flow and issue least privilege access tokens to MCP clients.

A CIAM Ecosystem

AI agents provide great potential to expose enriched information to users, but they require the use of open standards. To expose data in such an ecosystem, use OAuth standards to control data security. OAuth is a family of specifications for securing APIs at scale, while also considering user privacy and client environments. If you already use OAuth to secure APIs, a thin MCP server layer may be sufficient for your initial AI use cases. If you don't yet use OAuth security, consider security modernization as part of your AI initiatives.

OAuth in a dynamic ecosystem places greater demands on the authorization server. To meet those demands, an authorization server needs Customer Identity and Access Management (CIAM) qualities, with strong support for security standards. You also need extensibility in the important places, like user onboarding and user authentication. Even more importantly, you must be able to issue confidential and least privilege access tokens.

In summary, securing API requests from AI agents involves a lifecycle that begins with discovery and registration and extends through token issuance and access control across one or more APIs. Following these steps ensures that AI-driven API access remains secure and scalable.

Last updated: 2025-06-23

Gary Archer

Product Marketing Engineer at Curity

Join our Newsletter

Get the latest on identity management, API Security and authentication straight to your inbox.

Email

Subscribe

I agree to Curity's Privacy Policy

Start Free Trial

Try the Curity Identity Server for Free. Get up and running in 10 minutes.

Start Free Trial