When an AI agent connects to an MCP server, the agent must verify its identity (MCP authentication) and define the functions it is allowed to execute once granted access (MCP authorization) to ensure security for both the MCP client and the system. It is critical to differentiate between these two types of access control checks.

When security checks are used incorrectly or interchangeably, security gaps arise that pose challenges for users and administrators of traditional systems. In MCP environments, the lack of defined security checks creates more serious risks than in traditional systems.

This guide provides detailed descriptions of MCP authentication and authorization, how they function within the model context protocol ecosystem, and what it takes to implement these concepts for successful enterprise adoption in a live production environment.

What Is MCP Authentication?

MCP authentication is the first point of verification between an MCP client and an MCP server. Prior to executing any command via tools, the client must identify and authenticate itself to establish trust. To authenticate to remote MCP servers (HTTP/HTTPS), the most common authorization mechanism used is OAuth 2.1 with PKCE.

When an agent successfully authenticates with an authorization server, the client exchanges credentials for an OAuth token, often through a token exchange initiated at the metadata endpoint. The MCP server will not permit a connection unless the agent has a valid OAuth token.

Unlike the standard connection methods, local MCP servers that connect via STDIO transport do not require an agent to authenticate. Instead, they use the host process trust boundary, often configured via environment variables in basic use cases.

The most commonly used credential types are as follows:

• OAuth 2.1 Access Tokens: Short-lived (typically one hour) and limited in scope, this is the recommended credential type for secure access in production-grade systems.
• API keys: Easy to use, with no expiration or fine-grained access control; this credential type is considered risky when managing many users across external systems.
• JWTs: Claims about the identity of users such as user, role, and tenant are embedded inside the JWT, though they carry added complexity due to the need for additional authorization logic.
  

Since the June 2025 update to the MCP specification, servers are now treated as OAuth resource servers, and validate tokens but do not issue tokens to users. Instead, the responsibility for issuing tokens has been moved to external identity providers such as Okta, Azure AD, and Auth0.

This creates a single point of MCP authentication and brings SSO, MFA, and identity-level auditability into the MCP ecosystem without needing custom implementations.

What Is MCP Authorization?

Authentication establishes the client's identity, while MCP authorization determines the client's capabilities.

Authorization governs access control at a very detailed level, providing restrictions on which tools may be invoked, which data may be accessed, and under what conditions those actions may be taken. Authorization is evaluated continuously, rather than as a one-time evaluation, for each tool invocation.

In MCP systems, authorization typically uses a layered approach. The authorization layers found in MCP systems include:

• Scope-based Permissions: Permissions defined at token issuance that establish the outer limits of all possible OAuth scopes and actions taken.
• Role-Based Access Control (RBAC): Mapping of permissions to roles to ensure that any user and all AI agents accessing the same role have the same rights to access those resources.
• Resource-level Controls: Restricting secure access to specific datasets, tools, or environments.
• Contextual Policies: Applying runtime conditions such as time, request patterns, or risk signals to the above

The final layer of authorization represents the most interesting aspect of the modern MCP authorization framework. A token that has been authorized to call the read_file method at 9 AM can also be denied the ability to call the same method at 2 AM based upon another policy applicable to the first two reference parameters.

Authentication vs Authorization in MCP: The Key Differences

While authentication and authorization are sometimes confused, they represent a two-tiered approach in the context of MCP. The two areas provide different levels of access control, and the failure modes of each differ accordingly.

If authentication is correct but proper authorization is not enforced, each authenticated client becomes a superuser.

The failure modes often oppose each other:

• Weak MCP authentication allows incorrect identities through.
• Weak MCP authorization allows correct identities to perform excessive actions.

Production-style MCP systems require both types of control enforced independently

How MCP Authentication and Authorization Work Together in a Real MCP Flow?

Below is an actual example of a sequence of steps that take place when an agent contacts a remote MCP server. This will either lead to a successful tool call or result in failure.

Step 1: The agent attempts to connect to the MCP server as an MCP client. The MCP server does not recognize the client as having an open session, so it returns a 401 Unauthorized response along with authorization server metadata pointing to the authorization server.

Step 2: The agent sends a redirect request to the authorization server (either Okta, Azure AD, or Auth0), where the OAuth flow with PKCE is completed. The user or service authenticates and consents to the requested OAuth scopes, receiving an authorization code.

Step 3: After receiving an authorization code from the authorization server, the agent uses the authorization code flow to obtain an access token from the token endpoint. An access token provides the agent with temporary secure access while confirming the authenticity of communication and limiting the agent to the approved OAuth scopes claimed on behalf of the requesting application.

Step 4: Upon obtaining an access token, the agent communicates with MCP by including the access token in the Authorization header as a bearer token. The MCP server validates the token's signature, expiration date, and issuing entity against the authorization server's public keys during token validation to confirm the agent's identity.

Step 5: When the agent calls the MCP server with the tools:read scope, the MCP server first checks whether the access tokens' scopes match the requested action. Since the tools: read scope does not permit destructive actions, the MCP server returns a 403 Forbidden Response Code and logs the access denial as part of the authorization flow.

Step 6: To prevent unauthorized automation workflows from reaching misconfigured servers, a policy engine or an MCP gateway is placed in front of the MCP server. The policy engine checks that each tool invocation does not exceed any rate limits or violate any context-based policies or scope-based rules prior to allowing the request to pass through to the server logic.

Where Teams Go Wrong With MCP Authentication and Authorization?

Even teams using both layers often misuse them.

• Treating a valid token as blanket permission: Some companies use valid tokens for overall access, so developers usually establish new tokens that give them rights they should not have and via these tokens use them to access production database resources at either a developer level only or through using token-authentication security to gain access to the database resources in error when they were initially established in a manner that provided such rights to the developer.
• Authorization skipped for internal MCP servers: A network boundary alone does not guarantee you won't be able to access them. Someone who has internal access can access all internal resources on the internal sales order-processing application server.
• Static API keys used without a proper authorization stack: Static API keys may not have OAuth scopes, expiration, or revocation mechanisms. If a static API key is released in a log file or repository, the only resolution is to rotate the credentials, which is operationally disruptive at scale.
• Relying on OAuth scopes alone without RBAC at the gateway level: OAuth scopes define what the token can perform within a session, while roles define what the person is assigned to perform. If RBAC is not enforced at the gateway level, an automated pipeline will have the same access as a human engineer.
• Not re-evaluating access once permission has been granted at the start of a session: When an AI agent is granted permission to perform its function at the beginning of the session, if the agent's role changes during the session, all permissions granted prior to that change will continue to apply for the entire period. This is a significant risk in agentic systems where autonomous agents may operate across extended sessions.

What Enterprise Implementation of MCP Authentication and Authorization Requires? 

It is not feasible for teams or individual server implementations to handle MCP authentication and MCP authorization at scale on their own. Rather, they should be implemented across multiple servers at a platform level.

To accomplish this, the following must be taken into account:

• Centralized identity management via an identity provider: All MCP authentication requests across MCP servers must go through the same identity provider, whether that is Okta, Azure AD, or Auth0. Authentication configuration that is distributed will not scale and will create fragmentation in audit trails.
• Infrastructure-enforced short-lived scoped tokens: All MCP servers must enforce short-lived access tokens with defined OAuth scopes through the infrastructure. The team cannot correctly define token expiration or scope for each deployment, but the infrastructure will enforce them consistently.
• RBAC by server and role with immediate policy propagation: When a team changes the role of a user or team member, the change must propagate immediately to all servers and become effective without waiting for the next deployment cycle.
• Unique combined audit trails for access and authorization logs: Both access logs and MCP authorization logs are required by different teams. Both teams need access to combined audit trails using a common request ID for future investigations.
• Gateway access control enforcement separate from application code: If the application policy is stored in the server and the server is deployed incorrectly, the application policy can be disabled without detection. However, the MCP gateway will enforce both OAuth scopes checks and rate limits regardless of the application's behavior.

How TrueFoundry Enforces MCP Authentication and Authorization at the Platform Layer?

TrueFoundry treats MCP authentication and authorization as foundational concepts of its platform, not as tasks to be performed by individual applications.

• Enterprise IdP integration out of the box: TrueFoundry enables organizations to connect their enterprise identity provider using Okta, Azure AD, or any OAuth authorization server that supports OAuth 2.0. Authentication tokens are provisioned and identity verification takes place through each organization's existing identity infrastructure. Organizations do not need to create or manage an additional authorization server to complete their applications.
• Per-server RBAC enforced at the gateway, not the application: By enforcing access control at the MCP gateway before a request reaches MCP server application logic, TrueFoundry ensures that access policies are enforced across multiple MCP instances, regardless of how each application instance is developed or deployed.
• Scoped access that maps organizational roles to tool permissions: TrueFoundry supports MCP authorization scoping, with one group such as Finance assigned to one set of tools and another group such as Support assigned to another. A Finance agent and a Support agent can access the same MCP infrastructure while having distinct tool permissions. The mapping between roles and OAuth scopes is defined once on the platform and applies across all instances.
• Unified audit trail inside your VPC: TrueFoundry provides a single consolidated audit trail within the customer's VPC for events associated with token validation and tool invocations. Security teams have access to a complete, time-correlated audit trail. All token validation and tool invocation events include a uniform request ID, which makes it straightforward to identify events related to a specific user across large language models and external tools.
• Platform default, not per-team configuration: MCP authentication and MCP authorization features are enabled by default for all organizations. These policies are always inherited by MCP applications when deploying AI agents, so teams do not need to create their own policies or implement proper authentication in each new MCP server.

TrueFoundry provides MCP authentication and authorization as foundational platform capabilities, rather than as an individual configuration burden to the organizations using its tools.

Frequently Asked Questions

What is MCP authentication and MCP authorization?

MCP authentication and MCP authorization are two separate security concepts. MCP authentication confirms the MCP client's identity before access is granted, using OAuth tokens or API keys. MCP authorization determines what the authenticated client can do via OAuth scopes and RBAC. Both are required in any production MCP server deployment to prevent security risks from unauthorized access.

What is the difference between authentication and authorization in MCP?

MCP authentication occurs once upon connection and uses the authorization code flow or client credentials flow to verify identity. MCP authorization is evaluated on every tool invocation during the connection, applying OAuth scopes and RBAC rules to every request the AI agent makes through the MCP server

Can you have MCP authorization without authentication?

No meaningful MCP authorization is possible without MCP authentication, because there is no authenticated identity against which to evaluate permissions. Without proper authentication for establishing identity, the authorization server has no basis for issuing access tokens or applying authorization logic to incoming requests from AI agents or autonomous agents.

Which comes first, MCP authentication or MCP authorization?

MCP authentication always comes first. The authorization flow establishes the MCP client's identity with the authorization server. MCP authorization then occurs for every subsequent request after client authentication is complete and access tokens with defined OAuth scopes have been issued.

Does TrueFoundry support bring-your-own IdP?

Yes. TrueFoundry integrates with any OAuth 2.0-compliant identity provider or OAuth authorization server, allowing organizations to reuse their existing identity infrastructure. This includes support for external identity providers such as Okta and Azure AD, enabling centralized MCP authentication across all MCP servers without creating a separate authorization server configuration.