Auth-terminating shim forwards no caller identity to a remote MCP backend (token-exchange gated off by empty access_token prop)

[jcox-oxit]

Summary

When nanobot run acts as the auth-terminating shim in front of a remote MCP backend (mcpServers.<name>.url), it fully validates the caller (JWKS / trusted-issuer / audiences) but forwards a request to the backend with no representation of the validated caller — the backend sees no Authorization and no subject. This blocks the backend from doing per-caller authorization, audit attribution, or rate limiting.

The interesting part: the forwarding machinery is already present and configured — it's gated off by one condition.

Root cause (v0.0.68 / 0ac2a2d)

• RFC-8693 token exchange is configured for the shim: pkg/cli/serve.go sets TokenExchangeEndpoint = r.Auth.OAuthTokenURL (from --oauth-token-url / NANOBOT_RUN_OAUTH_TOKEN_URL), threaded into the outbound backend client (pkg/mcp/client.go → HTTPClientOptions).
• pkg/mcp/httpclient.go newRequest() performs the exchange and sets Authorization: Bearer <exchanged> on the backend request iff TokenFromContext(ctx) != "".
• pkg/auth/auth.go setupContext() (on the request path via auth.Wrap) is where the token would enter the context — but it calls mcp.WithToken(ctx, …) only when info.Props["access_token"] is non-empty:

ctx := types.WithNanobotContext(mcp.WithUser(req.Context(), user), nctx)
if token, _ := info.Props["access_token"].(string); token != "" {
    ctx = mcp.WithToken(ctx, token)
}

In our deployment the OAuth validator does not populate Props["access_token"], so WithToken is skipped, TokenFromContext(ctx) is empty, the exchange never fires, and the backend receives no caller identity.

Proposed fix (additive, one hunk)

When Props["access_token"] is empty, fall back to the validated inbound bearer from the Authorization header before WithToken. No behavior change when the prop is present:

token, _ := info.Props["access_token"].(string)
if token == "" {
    token = strings.TrimPrefix(req.Header.Get("Authorization"), "Bearer ")
}
if token != "" {
    ctx = mcp.WithToken(ctx, token)
}

strings is already imported in that file.

Question for maintainers

Is the outbound backend client's request built from the per-request context, or from a context captured when the backend session was first established? If per-session, a per-request WithToken wouldn't apply and the exchange would need to be invoked where the per-request context is live — happy to adjust the fix accordingly.

Offer

I have this patch applied against v0.0.68 locally and am glad to open a PR (with a test) if the direction looks right, or to adopt whatever config-first surface you'd prefer (e.g. a documented --forward-identity switch or claim-templated mcpServers.<name>.headers).

[0xbrainkid]

The fallback makes sense, but I would avoid forwarding the inbound bearer token directly to the backend unless the backend is explicitly the intended audience.

A safer shape is:

• validate inbound token at the shim
• retain the validated caller subject/issuer/audience in request context
• perform token exchange when configured, minting a backend-audience token
• if exchange is unavailable, forward a signed internal identity envelope/header only when the backend is configured to trust this shim

That preserves the key property this issue is about: the remote MCP backend can authorize, audit, and rate-limit by the real caller instead of by the shim. It also avoids turning the shim into a bearer-token relay across resource boundaries.

For the per-request vs per-session question, a regression test with two callers sharing one backend session would catch the bad case: caller A and caller B should produce distinct backend-visible subjects on sequential tool calls.