Enhance the UI to display OAuth 2.0 headers when a 401 Unauthorized response is received

[embesozzi]

Is your feature request related to a problem? Please describe. The MCP Server is protected by OAuth 2.0 [1] and typically acts as an OAuth 2.0 resource server. According to the OAuth 2.0 standard, when the resource server returns an error, it should include a WWW-Authenticate header [2].

[1] https://modelcontextprotocol.io/specification/2025-03-26 [2] https://www.rfc-editor.org/rfc/rfc6750.html

Describe the solution you'd like It would be good to show the HTTP headers received in the response in the UI as well - for instance, displaying the WWW-Authenticate header to indicate when step-up authentication is required or when additional scopes are being requested. Nowadays, only shows Access Denied.

[joberdick]

Hi @ThisIsMissEm @aaronpk, your solution might solve my issue here? https://github.com/orgs/modelcontextprotocol/discussions/394

[dr3s]

It sounds like a nice idea but it still depends upon auth server adoption right? I opened https://github.com/modelcontextprotocol/modelcontextprotocol/issues/573 because of Entra support lacking

[ThisIsMissEm]

Not exactly, this method provides the same or similar security to Dynamic Client Registration — the spec however, probably should allow for only pre-registered clients via a side-channel (e.g., going to a website and creating a client_id and client_secret pair for that client)

[aaronpk]

I actually had a long discussion with a few folks about this last month, and we came to the conclusion that while this is a better design, ultimately DCR was a better fit for now since DCR is implemented in more OAuth servers today.

The other thing that came out of that discussion was an alternative to DCR that pushes the client registration to the AS at runtime, so it's equivalent from a security/capability PoV as DCR, but a better design. Justin wrote up a first draft of that here: https://datatracker.ietf.org/doc/draft-richer-oauth-pushed-client-registration/

But again, we stuck with DCR for the current version of the spec since it is widely available in products today.

[localden]

Conceptually, I think this is really a good, simple approach to client registration. However, because of broad DCR investments across the identity ecosystem, that seemed like the best path forward (as @aaronpk called out). DCR also offers some potential good avenues for governance mechanisms (e.g., via the software ID "assertions") that I am not yet sure how they would be captured in the CID RFC.

[aaronpk]

I've now heard of a few implementations creating a list of allowed redirect URIs that can be used in Dynamic Client Registration. That seems like a creative hack that accomplishes a similar thing as this draft would enable. The idea is folks want to restrict which MCP clients can be used with their MCP server, so need some way to know the identity of the client. Without Client ID Metadata Documents, the only real client identity is the redirect URI, and even then only if it's a non-localhost URL. Anyway just thought I'd add that datapoint as an example of how people are trying to add client identity into MCP today. The Client ID Metadata Documents would be a much more complete solution to the problem.

[localden]

@ThisIsMissEm @aaronpk should this be merged into #991?

[ThisIsMissEm]

I'll let @aaronpk or someone decide if they want to keep this or close this — I'm not personally invested, and have unsubscribed from this issue.