Authorization in MCP 2026-07-28: Clarifying trust relationships for agentic systems

1.Introduction: Why trust matters in MCP

The Model Context Protocol (MCP) is becoming an important integration layer for agentic systems because it gives MCP clients a consistent way to access tools, data, and backend services on behalf of users. That capability is powerful, but it also introduces authorization relationships that may span multiple systems, services, and organizational boundaries. A typical MCP deployment is not a simple two-party interaction between a user and an application. It may involve a user, a host, one or more MCP clients, one or more MCP servers, one or more authorization servers, and downstream resources such as APIs, databases, SaaS platforms, or internal services (Figure 1).

Figure 1. Illustrative MCP authorization environment

In these environments, authorization decisions often depend on trust relationships spanning multiple systems and organizational boundaries. As a result, it becomes increasingly important to make those relationships explicit and verifiable.

MCP 2026-07-28[1] introduces several authorization-related refinements to its integration with OAuth and OpenID Connect (OIDC).[2]. Individually, these changes address specific interoperability and security concerns. Viewed collectively, however, these refinements clarify several authorization considerations related to trust relationships within MCP deployments.

It is also important to recognize the scope of these changes. Core authorization capabilities for MCP, including OAuth 2.1 based authorization flows[3], Authorization Server Metadata[4], Protected Resource Metadata[5], and client metadata models, had already been established in earlier specifications. The refinements introduced in MCP 2026-07-28 primarily focus on areas that become operationally significant when those foundations are applied to agentic systems.

Importantly, these refinements do not introduce fundamentally new authorization concepts. Discovery, issuer identification, client characteristics, credential binding, refresh token usage, and step-up authorization have all been recognized for many years within OAuth and OIDC deployments. The significance of MCP 2026-07-28 is not that it invents new approaches to authorization, but that it clarifies how these established concepts apply to MCP deployments and makes several trust relationships more explicit.

Taken together, these six authorization-hardening refinements were introduced in MCP 2026-07-28. This paper examines all of them through a common lens: how MCP makes trust relationships and authorization lifecycles more explicit in agentic environments.

2. Understanding authorization relationships

The growth of MCP highlights authorization challenges that are already familiar within OAuth and OIDC deployments. A single MCP client may interact with multiple MCP servers, each potentially associated with a different authorization server. In such environments, participants must be able to determine which authorization authority is responsible for a resource, which authority issued an authorization response, and how clients and credentials relate to that authority. These relationships therefore need to be identified and validated explicitly.

Several authorization-related changes in MCP 2026-07-28 address these challenges. Discovery behavior has been clarified through more explicit guidance on locating Protected Resource Metadata and determining the associated authorization server. MCP clients must now validate the iss parameter when it is present in an authorization response, following RFC 9207.⁶ For Dynamic Client Registration, MCP 2026-07-28 also requires MCP clients to specify an appropriate OIDC application_type, allowing authorization servers to distinguish between web and native application models and apply validation behavior appropriate to each. The specification further reinforces that client credentials remain bound to the authorization server that issued them rather than being reused across authorization authorities.

Taken together, these changes can be viewed as making authorization relationships easier to understand and verify. They reduce the likelihood that authorization artifacts originating in one trust context will be incorrectly accepted in another. In an ecosystem where clients may interact with many servers across organizational boundaries, that distinction becomes increasingly important.

None of these concerns are unique to MCP. Traditional OAuth and OIDC deployments have long required mechanisms for discovering authorization metadata, validating authorization responses, identifying client characteristics, and maintaining binding between credentials and issuing authorities. MCP deployments, however, often bring these trust relationships together across a growing ecosystem of hosts, servers, and authorization authorities. MCP 2026-07-28 therefore makes these relationships more explicit and verifiable.

3. Supporting long-lived agentic workflows

Traditional OAuth deployments often assume relatively short-lived interactions between users and applications.

Agentic workflows introduce a different model. Tasks may span multiple systems, execute over extended periods of time, and require additional privileges as new information becomes available.

MCP 2026-07-28 acknowledges this reality through clarifications around step-up authorization and refresh token usage.The specification clarifies that clients should preserve previously requested scopes during step-up authorization and documents how they can request refresh tokens from OIDC-style authorization servers. Together, these clarifications provide a clearer framework for applying existing OAuth and OIDC mechanisms to long-running agentic workflows.

Long-running authorization scenarios are also not unique to MCP. Offline access, delegated processing, and background operations have existed in enterprise systems for many years. However, agentic workflows may make such patterns more common and more visible because agents can execute tasks across multiple systems, evaluate intermediate results, and continue operating long after the initial user interaction. In this context, existing mechanisms such as refresh tokens and incremental authorization become particularly important tools for maintaining both usability and security.

4. Enterprise implications

Many enterprise deployments will integrate MCP authorization with existing OAuth, OIDC, and identity and access management (IAM) infrastructure rather than deploying it as a standalone capability. For enterprise architects, the significance of the authorization-related changes in MCP 2026-07-28 extends beyond protocol compliance.Many organizations already operate OAuth and OIDC infrastructure, and the concepts reinforced in MCP 2026-07-28 are generally familiar within established IAM programs.

The value of these refinements lies in clarifying how established OAuth and OIDC practices apply to MCP deployments, particularly in areas such as trust establishment, client identification, credential management, and long-running authorization workflows. MCP authorization does not introduce an entirely new set of IAM challenges. The concerns reinforced by MCP 2026-07-28 have long been addressed within enterprise OAuth and OIDC deployments.

Rather than replacing existing IAM practices, MCP extends their application to workflows involving hosts, MCP servers, authorization servers, and downstream resources. Viewed from an enterprise IAM perspective, MCP authorization should therefore be understood less as a new authorization architecture and more as an application of established OAuth and OIDC principles to agentic systems. Organizations evaluating MCP authorization should focus not only on protocol support, but also on how existing trust relationships, client management processes, credential governance, and authorization lifecycles extend to MCP-based environments.

5. Conclusion

MCP 2026-07-28 introduces a number of authorization-related refinements to its integration with OAuth and OIDC. Individually, these updates may appear modest because most are based on concepts and practices that are already well established within the broader IAM ecosystem.

Taken together, however, the changes highlight a set of authorization considerations that are particularly relevant when applying existing OAuth and OIDC architectures to agentic systems. Questions such as identifying the correct authorization authority, validating authorization responses, understanding client characteristics, and managing authorization over extended workflows become increasingly important as MCP deployments grow in scale and complexity.

As agentic systems continue to evolve, organizations may find that existing OAuth and OIDC principles remain highly applicable.

The primary building blocks of MCP authorization were already established in earlier specifications, and the refinements introduced in MCP 2026-07-28 largely focus on areas that become operationally significant in production deployments.

Rather than requiring a fundamentally new IAM model, MCP continues to demonstrate the importance of applying established IAM practices consistently across hosts, MCP servers, authorization servers, and downstream resources.

Resources

1. https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
2. See the MCP 2026-07-28 Release Candidate announcement, particularly the Authorization Hardening section: MCP 2026-07-28 RC Authorization Hardening
3. https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
4. https://datatracker.ietf.org/doc/rfc8414/
5. https://datatracker.ietf.org/doc/rfc9728/