.NET: Add sample for per-run refreshable MCP authentication headers#6624
.NET: Add sample for per-run refreshable MCP authentication headers#6624rogerbarreto wants to merge 3 commits into
Conversation
Adds a Foundry RAPI sample that attaches per-run, refreshable authentication headers to MCP requests using existing primitives: a DelegatingHandler on the MCP transport's HttpClient plus an AsyncLocal run scope. The same agent runs under two contexts, each minting a fresh token, proving the header is per run rather than bound at agent or connection creation time. The handler attaches the bearer only over HTTPS to the MCP server's own origin, logs the non-secret label only, disables cookies, and checks certificate revocation. The README covers security considerations and production notes. Fixes microsoft#1631
There was a problem hiding this comment.
Pull request overview
Adds a new .NET sample under the MCP samples set demonstrating how to apply per-run / refreshable authentication headers to MCP HTTP requests without introducing new framework APIs, aligning with the guidance for issue #1631 (sample-based pattern rather than new surface area).
Changes:
- Added new sample
Agent_MCP_PerRun_AuthHeaders(README + runnable Program + csproj) demonstrating AsyncLocal-scoped, per-run bearer stamping via a customDelegatingHandler. - Registered the new sample project in
agent-framework-dotnet.slnx. - Linked the new sample from the MCP samples README.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| dotnet/samples/02-agents/ModelContextProtocol/README.md | Adds the new sample to the MCP samples index table. |
| dotnet/samples/02-agents/ModelContextProtocol/Agent_MCP_PerRun_AuthHeaders/README.md | Documents the per-run header pattern, flow, and security considerations. |
| dotnet/samples/02-agents/ModelContextProtocol/Agent_MCP_PerRun_AuthHeaders/Program.cs | Implements the per-run header stamping pattern via AsyncLocal + DelegatingHandler. |
| dotnet/samples/02-agents/ModelContextProtocol/Agent_MCP_PerRun_AuthHeaders/Agent_MCP_PerRun_AuthHeaders.csproj | New sample project referencing required packages and framework projects. |
| dotnet/agent-framework-dotnet.slnx | Adds the new sample project to the solution. |
…env vars Disable AllowAutoRedirect on the shared handler so a redirect cannot carry the bearer past the origin check. Save and restore the prior run scope instead of clearing to null so the helper is safe under nesting. Note the Foundry env vars in the samples folder README row and update the sample README security notes.
Review: Per-Run Refreshable MCP Auth HeadersThis is a valuable pattern @rogerbarreto! Dynamic auth token refresh for MCP connections solves a real production pain point — tokens expire, and hardcoded headers break silently. Observations
Related WorkIn the Python hosting stack (PR #6642), I worked on session isolation and per-request state management. The pattern of refreshing per-run state (tokens, headers, session keys) is very similar — happy to help align the Python and .NET patterns if that's useful. Great addition to the MCP story! |
Motivation & Context
Issue #1631 want per-run / refreshable MCP auth headers in .NET. Real need: IAM/OBO tokens expire ~1h, plus per-tenant headers. Question: does framework need new API for this? Answer: no. Existing primitives already cover it. This PR add a sample that prove the pattern, no framework change.
Description & Review Guide
What are the major changes?
New sample
Agent_MCP_PerRun_AuthHeaders(Foundry via Responses API + public Microsoft Learn MCP). Per-run header mechanism:DelegatingHandleron MCP transportHttpClientstampAuthorization: Bearer <token>per outbound request.AsyncLocalrun scope (McpRunScope) carry the current-run token, set right beforeagent.RunAsyncand cleared infinally.tenant-a,tenant-b), each mint fresh token. Header is per run, not bound at agent or connection build time.agent-framework-dotnet.slnx, add row to ModelContextProtocol folder README.What is the impact of these changes?
Sample + docs only. No framework API surface, no
header_provideranalog. No new package (ModelContextProtocolalready referenced). Not breaking.What do you want reviewers to focus on?
Handler security hardening: bearer attached only over HTTPS to the MCP server own origin (no leak on redirect / plaintext / other port), token never logged (label only), cookies off, cert revocation checked. And confirm the "ship a sample, not a new API" call for .NET: Feature Request: Support for Per-Run MCP Authentication Headers #1631 is right.
Related Issue
Fixes #1631
Contribution Checklist
breaking changelabel (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.