examples: adjust conformance server for auth tests#763
examples: adjust conformance server for auth tests#763maciej-kisiel wants to merge 1 commit intomodelcontextprotocol:mainfrom
Conversation
|
CC @jba could you help review, since you considered the first draft? |
| // It mirrors the functionality of the TypeScript conformance server at | ||
| // https://github.com/modelcontextprotocol/conformance/blob/main/examples/servers/typescript/everything-server.ts | ||
|
|
||
| //go:build mcp_go_client_oauth |
There was a problem hiding this comment.
Does any of these need the client-side code? I think only the server-side code is used.
There was a problem hiding this comment.
https://github.com/modelcontextprotocol/go-sdk/blob/main/oauthex/auth_meta.go has the tag and getting Authorization server metadata is expected by the conformance tests.
I would have a more general question: what's the logic whether something should live in auth vs in oauthex? My naive assumption would be that auth supports the authorization helpers implementing the spec (https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization) and oauthex could contain extensions, as proposed in the https://github.com/modelcontextprotocol/ext-auth repo. But currently, many of the basic primitives do live in oauthex. Could you provide me with more context?
There was a problem hiding this comment.
oauthex should contain only extensions to the OAuth 2.0 protocol, as described in various RFCs for that protocol. So for us that means Resource Server Metadata, Auth Server Metadata, and Dynamic Client Registration. The test is: could we just move this package under golang.org/x/oauth2 without bringing along anything MCP-specific? Because that is exactly what I'd like to happen someday.
Are we currently violating that?
I don't know why auth_meta.go has the tag. Please confirm that it contains no logic outside of the RFC. Then remove the tag.
3 participants
This is a draft. It's a re-upload of #759.
Early thoughts with regard to the interface:
So far we started the server, here we need to instruct the conformance tests to start it, which is a change in approach and requires additional handling.
The tests started working sooner than I thought they would, I need to analyze if that's expected.
Internal design notes:
Not clear if extending the existing server is a good approach vs. creating a simpler auth-specific one.
Especially that the Go build flag that currently guards some of the libraries "poisoned" the conformance server now.
The results of conformance tests do not land in the directory passed via a flag. To be investigated.