You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice for the ClientSessionGroup to be OAuth compatible by allowing us to specify the OAuth httpx.Auth provider when passing in the ServerParameters rather than passing the bearer tokens manually via the headers field. This will allow us to do the OAuth token exchange flow straight from the ClientSessionGroup.
Hi @maxisbey !!
I've implemented this by adding an auth: httpx.Auth | None field to both SseServerParameters & StreamableHttpParameters,which gets passed through to the underlying sse_client() and create_mcp_http_client() calls. Will open a PR shortly.
Hi! I’m interested in implementing this. I traced the ClientSessionGroup connection path and propose adding optional httpx2.Auth support directly on SseServerParameters and StreamableHttpParameters, propagating it into sse_client and create_mcp_http_client. Existing header behavior remains 100% backward compatible, and authentication applies cleanly only to the relevant HTTP transports.
I have implemented this with 100% test coverage, serialization safety (ConfigDict(arbitrary_types_allowed=True, exclude=True)), per-server auth isolation, and updated documentation in session-groups.md.
The transports already accept an httpx.Auth (sse_client has auth=, and the streamable-HTTP path goes through create_mcp_http_client, which also has auth=) — the missing piece is that SseServerParameters / StreamableHttpParameters can't carry one.
My proposed approach is to add an optional auth field to both parameter models and thread it through _establish_session. This should allow ClientSessionGroup to use the same authentication flow already supported by the underlying transports.
Does that approach look right?
Disclosure: I used AI assistance to investigate and draft this proposal; I've reviewed it and understand the proposed changes.
Activity
the-ayyi commentedon Dec 19, 2025
@maxisbey Let me know if anyone is working on this. Otherwise, I will take this.
IT-HONGREAT commentedon Feb 14, 2026
Hi @maxisbey !!
I've implemented this by adding an auth: httpx.Auth | None field to both SseServerParameters & StreamableHttpParameters,which gets passed through to the underlying sse_client() and create_mcp_http_client() calls. Will open a PR shortly.
feat: add auth parameter to ClientSessionGroup server parameters
feat: add auth parameter to ClientSessionGroup server parameters
feat: add auth parameter to ClientSessionGroup server parameters
musi22 commentedon Sep 17, 2026
Hi! I’m interested in implementing this. I traced the
ClientSessionGroupconnection path and propose adding optionalhttpx2.Authsupport directly onSseServerParametersandStreamableHttpParameters, propagating it intosse_clientandcreate_mcp_http_client. Existing header behavior remains 100% backward compatible, and authentication applies cleanly only to the relevant HTTP transports.I have implemented this with 100% test coverage, serialization safety (
ConfigDict(arbitrary_types_allowed=True, exclude=True)), per-server auth isolation, and updated documentation insession-groups.md.Would you like me to open the PR for review?
Mohammedib24 commentedon Sep 19, 2026
I'd like to take this.
The transports already accept an
httpx.Auth(sse_clienthasauth=, and the streamable-HTTP path goes throughcreate_mcp_http_client, which also hasauth=) — the missing piece is thatSseServerParameters/StreamableHttpParameterscan't carry one.My proposed approach is to add an optional
authfield to both parameter models and thread it through_establish_session. This should allowClientSessionGroupto use the same authentication flow already supported by the underlying transports.Does that approach look right?
Disclosure: I used AI assistance to investigate and draft this proposal; I've reviewed it and understand the proposed changes.