Access Token Privilege Restriction: does "MUST NOT pass through" cover an API of the same authorization server/project (Supabase Edge MCP pattern)? #3413

Activity

1. jryski commented on Oct 4, 2026

   

   jryski

   on Oct 4, 2026

   Author

   More actions

   Follow-up from the reporter's side: while this question is open, we wrote down the position we intend to take, with the full reasoning, as a draft in our repository. That way it can be critiqued concretely:

   • Profile (normative requirements, a risk-by-risk mapping to the Token Passthrough risks in the security best practices, and a conformance test suite): https://github.com/jryski/Supabase_user_MCP/blob/5781d0225fd7e4fb3793304eebf417dc8469ce3d/docs/SAME_AUTHORITY_DELEGATION_PROFILE.md
   • Decision record with the options considered and the strongest objection we know of: https://github.com/jryski/Supabase_user_MCP/blob/5781d0225fd7e4fb3793304eebf417dc8469ce3d/docs/decisions/0006-same-authority-capability-delegation.md
   • Draft PR: docs: propose Same-Authority Capability Delegation profile (ADR-0006) jryski/Supabase_user_MCP#102

   In short, the authorization server issues a token whose audience is the MCP resource, and its role grants database privileges for only the functions behind the MCP tools. RLS, bounds and live session and client checks are enforced in Postgres. So the token can do nothing more by bypassing the MCP server than by going through it.

   We do not claim this satisfies the literal "separate token" wording. We record it as a disclosed deviation and keep a separate-credential mode for strict conformance. A maintainer ruling either way would settle which mode we treat as primary.

   AI disclosure: drafted by an AI assistant (Anthropic Claude, in the Hermes agent framework); posted with the repository owner's authorization.
2. cc-bb-aa commented on Oct 4, 2026

   

   cc-bb-aa

   on Oct 4, 2026

   More actions

   Running an MCP gateway in production, the confused-deputy angle is where this bites in practice: a client that forwards its token to a server which then calls an upstream API has effectively minted a broader credential than the user authorized, and nobody in the chain can prove what scope the original grant had. Audience binding per hop (each server gets a token scoped to itself, with an exchange at the boundary if it needs upstream access) removes the ambiguity without changing the spec's intent. It also gives you a per-hop audit point, which you will want the first time a server does something unexpected with downstream data.
3. sattyamjjain commented on Oct 5, 2026

   

   sattyamjjain

   on Oct 5, 2026

   More actions

   Adding the scanner side, since the ruling decides what static tools should flag.

   I maintain agent-audit-kit. Its token passthrough rule (AAK-OAUTH-003) is critical, and its remediation is "never forward a user token across trust boundaries". A static check can't tell a same-AS Data API from a third-party one, so without a carve-out, the Supabase Edge pattern is a true positive. If same-authority use is allowed, tools need conditions they can actually check, and your three are the right ones:

   1. the token's aud names the MCP server's canonical URI (RFC 8707)
   2. the token is bound to the client the user consented to
   3. the downstream API is listed as part of the same protected resource in the RFC 9728 metadata

   One note: your observation that Supabase Auth ignores resource and issues aud=authenticated means (1) fails in that setup even with a carve-out. I'd keep that as a separate question so it doesn't block the main ruling.
4. jryski commented on Oct 5, 2026

   

   jryski

   on Oct 5, 2026

   Author

   More actions

   Thank you both, this is really helpful. You're describing the same problem from two useful angles: what a correct design looks like, and what a tool can actually verify. Our goal is to make whatever the maintainers decide easy to implement and easy to check, so here is everything we've learned so far, in case it helps.

   @cc-bb-aa: agreed. Per-hop audience binding, with an exchange at the boundary, is the clean model, and it's the one we'd reach for first. The reason we wrote this up is that not every authorization server can do that exchange yet. Supabase Auth, for example, has no RFC 8693 token exchange for a downstream audience today. Implementers on platforms like that end up choosing between holding a second, separately consented credential on the server, or forwarding. We'd like the spec to give them a clear and safe answer either way.

   @sattyamjjain: thank you for bringing the scanner perspective. Whatever the ruling is, framing it as conditions a tool can check seems exactly right. Here's where each of your three conditions stands in our draft, on Supabase:

   1. The token's aud names the MCP server's canonical URI. You're right that Supabase ignores resource by default. We found it can still be met: Supabase's Custom Access Token Hook can set aud. In our draft the hook sets aud to the single canonical MCP URI for approved MCP clients only, on both issuance and refresh, and those tokens never carry the general authenticated audience. So this condition can be satisfied today with some setup. We agree it's worth tracking separately as a request for native resource support.

   2. The token is bound to the client the user consented to. On every call, the backend re-checks client_id against a server-controlled list of approved clients, and checks that the token's session_id is still a live session for the same user and client. In our local tests, revoking access was enforced on the very next call.

   3. The downstream API is listed as part of the same protected resource in RFC 9728 metadata. This is the one we couldn't make checkable. RFC 9728 metadata describes a single resource, and we didn't find a standard way to say "these upstream endpoints belong to the same protected resource, under the same issuer." Our draft requires this to be documented, but documentation isn't something a scanner can read. Purely as an illustration of the shape (not a proposal of a name), something like:

      {
        "resource": "https://<project>.supabase.co/functions/v1/mcp",
        "authorization_servers": ["https://<project>.supabase.co/auth/v1"],
        "same_resource_endpoints": ["https://<project>.supabase.co/rest/v1/rpc/list_own_v1"]
      }

      would let a tool confirm that the downstream shares the issuer and was declared on purpose. If the maintainers think this direction is worth exploring, we'd be glad to help draft it properly. We're equally happy to follow a different approach if one fits better.

   We'd also suggest one more condition for anyone considering a same-authority allowance. The forwarded token shouldn't be able to do more at the downstream than the MCP tools expose. In our draft, that means:

   • the token's database role can only call the functions behind the tools;
   • the role has no direct table access;
   • a catalog lint verifies both.

   Without something like this, a correct audience still lets a client go around the server's controls. That's the risk the current rule protects against.

   To be clear about where our draft stands:

   • It's a proposal, and we've labeled it as a documented exception, not as conformance with the current text.
   • It's tested only locally, with synthetic data.
   • We'll adapt it to whatever the maintainers decide.

   The draft and its test evidence are here if useful: jryski/Supabase_user_MCP#102

   AI disclosure: drafted by an AI assistant (Anthropic Claude, in the Hermes agent framework) and posted with the repository owner's authorization.
5. vladzdev commented on Oct 8, 2026

   

   vladzdev

   on Oct 8, 2026

   More actions

   I’d make the distinction around the resource the token is authorized for rather than around whether the upstream happens to share the same authorization server or domain. The risky case is forwarding a token outside its intended audience, while a same-project data API can still be a legitimate resource boundary if that relationship is explicit and verifiable. Otherwise implementations are forced to infer intent from deployment topology, which seems like the wrong place to put the security rule.