Let tokens without an upstream session reach backends that need no per-user credential

Start by reading pkg/auth/upstreamswap/middleware.go, especially createMiddlewareFunc, and trace how the token validator sets identity claims. The suggested first slice is the swap carve-out, tsid check, and unit tests; then review the separate acceptance criteria for authorization server, kind e2e, vMCP, and docs. Done means the relevant backend receives no user credential for marked sessionless tokens while interactive and expired-session behavior remains as specified.

Part of "Embedded auth server should accept SPIFFE SVIDs as client credentials" (#6199).

This is not SPIFFE-specific. private_key_jwt delegates, the JWT-bearer grant and ID-JAG redemption have the same problem. SPIFFE client_credentials is the case that needs one authorization-server change (see below).

This is a first sketch. The code facts below were checked on the SPIFFE stack branch. The vMCP behaviour, the MCPRemoteProxy headerForward end-to-end path, and the absence of a header-echo e2e backend are inferred, not run.

Problem

The embedded authorization server issues tokens with no tsid to SPIFFE workloads (client_credentials and RFC 8693 exchange), private_key_jwt delegates, and the JWT-bearer and ID-JAG grants.

On an MCPServer or MCPRemoteProxy whose embedded auth server has an upstream IdP, the upstream swap middleware answers these tokens with 401 "re-authentication required" (pkg/auth/upstreamswap/middleware.go, createMiddlewareFunc). It does this even when the backend needs no per-user credential at all. The agent cannot re-authenticate, so the message does not help it.

Seen on a kind cluster: a SPIFFE client_credentials token got that 401 at /mcp, while a real user's login token on the same server got 200.

Today's workarounds:

• disableUpstreamTokenInjection strips credentials for every caller, interactive users included.
• A second, token-only server in front of the same backend works, but doubles the deployment.

Proposed direction

• The swap treats Identity.SessionlessGrant as "attach no credential". The token validator sets it only for a token from the embedded issuer that carries an act chain or the claim https://toolhive.dev/no_upstream_session. The swap strips Authorization, Cookie and Proxy-Authorization itself, then forwards. There is no new setting: configuring the client is the opt-in. The authorization server only mints these tokens for a client the operator configured (a SPIFFE association, a delegate client or a trusted issuer), and the token's audience limits it to the resources that client lists. Every other caller keeps today's behaviour, including the 401 for a user whose upstream session has expired.
• The SPIFFE client_credentials handler mints the marker. RFC 8693 outputs already carry act. JWT-bearer and ID-JAG tokens already carry the marker. The marker is not added to RFC 8693 outputs: act is the proof, and the marker would let a malformed act chain through.
• isSessionlessGrant additionally refuses a token that carries a tsid.
• When the proxy also has outgoing token exchange, AWS STS or OBO middleware, sessionless tokens keep today's 401. Those middlewares read the Authorization header and would act on a request that is meant to carry no credential. The combination is not rejected at config time, because that would break existing deployments.
• The pass-through is keyed on the authorization server having affirmatively marked the token, never on the absence of upstream tokens.

Acceptance criteria

• On a server with an upstream, a SPIFFE client_credentials token, a delegated token, a JWT-bearer token and an ID-JAG token reach the backend. A kind e2e shows the backend received no Authorization or Cookie header and no ToolHive JWT.
• Interactive users on the same server still get their upstream token. Expired upstream sessions still get the 401 challenge.
• A proxy with outgoing token exchange, AWS STS or OBO keeps the 401 for these tokens.
• MCPRemoteProxy with headerForward: the agent's request carries only the static header (kind e2e).
• vMCP: a header_injection backend serves the agent, and an upstream_inject backend is excluded (kind e2e).
• The pending delegation spec in the SPIFFE delegation e2e suite is un-pended.
• Docs and release note cover the Cedar change: SPIFFE client_credentials tokens are evaluated on their own claims when primaryUpstreamProvider applies, instead of being denied.

Out of scope

• Giving these tokens any user's stored upstream credential. That is the delegated-access work: "Delegated client access to a user's connections" (#6406) and its sub-issues.
• Giving headless callers an upstream ID token so they can reach xaa backends, which is a credential-bearing case: "vMCP multi-upstream auth: scope refresh failures per provider, let headless callers reach xaa backends" (#7009).
• Sender-constrained tokens.
• The fallback differences between outgoing strategies: "Outgoing strategies differ on no-subject-provider fallback" (#6177).

Open questions

• Is implicit enough, or is a per-client switch wanted later (for example a field on the association or delegate client) for an operator who configures such a client but does not want it to reach a given backend?
• Should the 401 text for sessionless callers change, since "re-authenticate" is something an agent cannot do?
• Should there be an audit field for "no upstream credential attached" (a follow-up)?

Per server type (what is believed today)

• Container MCPServer: no outgoing static-header path is needed. The container holds its own secrets, and header forwarding only installs for remote servers.
• MCPRemoteProxy: with a token-only auth server plus headerForward, the runner should strip and then add the static header. No test runs this combination.
• vMCP: it does not use the runner swap, and its header_injection and unauthenticated strategies ignore identity, so it probably works already.

Behaviour changes to name in the pull requests

• Tokens that existing delegate clients, JWT-bearer and ID-JAG already receive are now forwarded to the backend with no credential on a server with an upstream, instead of getting a 401. This is the cost of making it implicit, and it applies to deployments that exist today, not only to SPIFFE. A backend with an anonymous mode or an ambient credential would start answering them, and a server with no authorization policy does not limit them at the proxy (the second part is not verified).
• The Cedar outcome for SPIFFE client_credentials tokens changes from denied to evaluated, so a broad permit policy would now admit them.
• The exchange-grant source check will also start refusing client_credentials tokens as subjects (inferred; check it).
• The 401 text, if it changes.

Suggested split, one logical change each

1. The proxy side: the swap carve-out, the tsid hardening and unit tests. This alone unblocks delegated, JWT-bearer and ID-JAG tokens.
2. Docs and kind e2e for MCPServer and MCPRemoteProxy.
3. The authorization server marks client_credentials tokens, with the Cedar release note. This is what unblocks SPIFFE client_credentials. Do not combine it with step 1, because it changes Cedar outcomes on its own.
4. vMCP e2e, and lowering a caller-triggered WARN to DEBUG.

Related

• "Allow the embedded auth server to run with zero upstream providers" (#6449)
• "Double auth transformation when MCPServer is behind VirtualMCPServer" (#4863)
• "MCPRemoteProxy + embeddedAuthServer: upstreamswap does not inject the stored per-user upstream token" (#6681)