ext-auth

I’m working on OAAF (Open Agent Authority Framework), an open interoperability framework for delegated authority across AI agents and tools. We’ve implemented an MCP enforcement profile where delegated authority is verified before the normal MCP authorization/PDP path. The authority can be narrower than the underlying credential, so an agent with valid credentials can still be denied a tool call that wasn’t delegated to it. For example: Agent credential: broad repository access Delegated authority: repo.read repo.write MCP tools/call: repo.merge OAAF authority precondition: DENY Downstream PDP/tool: never invoked The goal is specifically not to replace MCP authorization or introduce another competing credential format. OAAF profiles existing standards for delegated/attenuated authority and composes with the normal MCP authorization path. We have a working TypeScript/Python implementation, MCP/COAZ binding, portable conformance corpus, and implementation-independent conformance runner: OAAF: https://github.com/espradley/oaaf Before proposing an extension or SEP, I’d appreciate maintainer feedback on the architectural question: Does delegated/attenuated agent authority belong as an optional MCP authorization extension in this repository, or would maintainers prefer it remain an external interoperability profile layered ahead of MCP authorization? If this is in scope here, I’d be happy to prepare a narrowly scoped proposal/PR following the project’s governance process.

Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: 1. Expected behavior A clear and concise description of what you expected to happen. Logs If applicable, add logs to help explain your problem. Additional context** Add any other context about the problem here.

Hello team :wave: Doyensec has recently been involved in a number of MCP-related security testing engagements. Through this work, we have reviewed a wide range of MCP authentication and authorization implementations, as well as related extensions. As a contribution to the community, we have prepared the following commentary on the current draft. This PR expands the security considerations in the MCP JAG specification. In addition, we include below our broader observations on the standard, along with our views on several unresolved issues. While the JAG approach is established in traditional machine-to-machine scenarios, its use in the MCP context raises significant concerns. It introduces multiple complex dependencies and a broad attack surface given the numerous specifications involved, increasing the risk of failures. The model’s reliance on full user impersonation by non-deterministic agents - autonomously choosing tasks without explicit user consent - does not align well with MCP’s security needs. Moreover, the approach lacks clear mechanisms for access invalidation and exposes enterprises to potential scopes abuse. Therefore, we believe JAG is not the best fit for MCP and recommend considering more controlled authorization mechanisms that better balance security and agent autonomy. Outstanding Issues The following section includes a few open questions on the technical limitations and complexity introduced by the JAG proposal for enterprise authorization. 1.1 Access Invalidation Problem Below are listed the three level of tokens issues throughout a correct execution of the flow: ID Token from IdP ID Token For the Grant (JAG ID) from IdP MCP Access Token from the MCP Authorization Server The proposed Spec does not explicitly describe mechanisms for invalidating access to an MCP client or revoking issued tokens / ID-JAG. A valid proposal should require the IdPs offering an access invalidation flow that could: 1. Invalidate the initial ID Token at IdP level 2. Prevent the revoked ID Token from being used for new ID-JAG requests 3. Call a mandatory webhook on all the MCP Authorization Servers to inform them about the invalid JAG IDs associated with the identity being revoked From that point, the MCP Authorization server should reject revoked ID-JAGs even if the server is allowing ID-JAG replay. In our opinion, while the access invalidation is also unspecified in the parent RFCs, the high risk associated with non-deterministic agentic accesses to tools and resources should require an access invalidation flow for the Enterprise context. Otherwise, the enterprise processes being authorized with the above mentioned Spec would not have a clear emergency recovery pattern whenever agents start misbehaving (e.g. injections and other widely known attacks). Consequently, every actor could end-up proposing its own recovery pattern, bringing ambiguity and implementation differences. 1.2 LLM Scope Abuse Without User Consent In JAG, the IdP issues an ID Token with no scopes embedded. It just states the identity of the user to allow impersonation from the MCP client. So when the MCP client requests a JAG for high-risk scopes like , no consent pop-up is triggered. The enterprise policy decides on behalf of the user being impersonated. While this is totally normal in a classic Machine-to-Machine (M2M) environemnt where the enterprise users are expected to be directly mandating specific tasks on their behalf to automation softwares, that standard does not apply to the MCP field. In fact, the typical MCP user does not define the tasks, resources, tool actions involved directly, but it’s rather a model to determine the tasks definition. Specifically, the tasks and actions list being transformed into MCP interactions are not directly chosen deterministically from the end-user. If the proposed JAG Spec is applied to that context, since the user never sees a consent screen for high-risk actions, a compromised client or LLM-related process could abuse the user's identity to request dangerous scopes like that the user never intended to include in their tasks plan. In general, the consent requirement bypass offered by JAG would allow LLMs to autonomously request any scope permitted by enterprise policies, even if it's irrelevant to the user's current task, removing the human-in-the-loop for high-risk actions. A potential fix could be to introduce "Step-Up Verification" for "dangerous" scopes, where the MCP Authorization server triggers a variation of Step-up Authentication (RFC 9470) or a Dynamic Consent challenge. Instead of silently issuing the token, the MCP Authorization Server forces a real-time user confirmation (e.g., a mobile push or MFA prompt) specifically for that high-impact scope. 1.3 How the IdP Creates, Distribute and Validate Clients Within the JAG proposal, it is not declared how the IdP should issue/distribute client credentials (secret vs private-key JWT vs mTLS, how they’re delivered, rotation, etc.). Moreover, it is not declared how important it is for the IdP to ensure that the (The Issuer URL of the MCP server's authorization server) is linked to the (The RFC9728 Resource Identifier of the MCP server) . While such practice is unspecified in the parent specifications, enterprise architectures are usually based on multiple IdPs managing access to a wide range of resources, often overlapping: e.g. both IdP A and IdP B can authorize access to app C. Within the presented Enterprise MCP scenario, multiple IdPs could be authorizing multiple MCP Authorization Servers (often overlapping), while each of them manages scopes for a range of MCP Servers. In such context, clearly defining namespaces and required checks on IdPs and MCP Authorization Servers would help preventing implementation issues like: Scope Namespace Collision: If Server A and Server B both use common scope names like , , etc., the attacker could leverage a low-privilege ID-JAG from Server B to gain access to Server A if is not checked to be the Authorization Server and the as one of the MCP Servers managed by the specific MCP Authorization Server Resource Identifier Injection: If the MCP Server Authorization Server doesn't validate that the claim in the ID-JAG matches its own registered resource identifier, it cannot distinguish between ID-JAGs intended for different servers. Once obtained an MCP session, the injected value could be lost and irrelevant, allowing cross-access The IdP must ensure that JAGs for resources not managed by the caller client are not forged. 1.4 ID-JAG Replay Concern If* a single ID-JAG can mint multiple MCP Server access tokens, and those access tokens can invoke high-impact tools, then the ID-JAG becomes an amplifier* for damage. That is why the decision of enforcing single-use checks on the should belong to the Spec level. 1.5 ID Token And SAML Assertion Concern While in classic OAuth or SAML, the scope consent happens at authorization time, in JAG the user never explicitly consents to specific scopes. Instead, they allow full impersonation and the enterprise policy decides on their behalf, as explained in 2.2. Since a user logs in to an MCP Client through their enterprise Identity Provider, resulting in an Identity Assertion being issued to the MCP Client with full-impersonation capabilities, the part of the flow involved in the creation of the ID token becomes particularly relevant from a security perspective. The Spec cites the possibility to use either OAuth2 or SAML for that part. As widely known, custom OAuth2 and SAML implementations are often improperly implemented, leading to dangerous consequences. Within JAG, they assume an even wider impact as they are used for full-impersonation instead of singe scope access. Because of that, implementing such an enterprise authorization strategy would require extensive education to the adopters about the variety of potential security threats. Thanks, Francesco (Doyensec LLC)