proposal: auth package with OAuth types

[jba]

First, let's add an auth package, a peer of mcp. It will hold everything auth-related, to keep it from cluttering mcp.

The two initial types are:

ClientOptions: a struct with values that the client can set on creation. Initial fields:

• ClientID, ClientSecret: these can hold the required OAuth fields in case the auth server doesn't support dynamic client registration.
• RedirectURI: another part of the OAuth flow. I don't see how this could be provided in any other way (and thus perhaps it is not an "option"; but I will research this further).

auth.ClientOptions would be the type of a field in mcp.StreamableClientTransportOptions.

ServerInfo: this is close to what I called AuthInfo in #237. It holds the result of validating the access token, and perhaps the raw token itself if that's of any use to anyone. It will have some fixed fields, but will also need a map[string]any because the token format is open-ended, and even in the common case of JWT, the claims are open-ended.

[jba]

#176 is an implementation of the client-side flow, without the above.

[jba]

/cc @gannaramu @RoyceLeonD

[gannaramu]

we should get some more eyes from the discord group.

[jba]

@gannaramu can you @mention the right people? I don't know them well.

[jba]

Revised client-side design:

All auth happens in an http.Client. This can be provided to StreamableClientTransport.HTTPClient.

We will provide auth.HTTPTransport, which can be wrapped in an http.Client. It can be configured with a function with the signature

func(context.Context, *oauthex.ProtectedResourceMetadata) (oauth2.TokenSource, error)

That function should:

1. Use the ProtectedResourceMetadata to obtain the address of an auth server.
2. Perform the OAuth flow with the auth server to obtain an access token. Much of this can be done with the golang.org/x/oauth2 package.

The auth.HTTPTransport will call that function when it sees a 401, after fetching the Protected Resource Metadata from the MCP server.

This split allows users to customize all interaction with servers other than the MCP server itself.

We plan on providing a default function for people who don't want to write their own (which will be most people). Details forthcoming.

[rebaz94]

@jba Are there plans to implement an authentication package similar to the TypeScript SDK's Auth?

[jba]

Yes, some of it. There is already a package. golang.org/x/oauth2, that handles basic OAuth. We also have implementations of some of the additional RFCs in internal/oauthex. We will make them visible at some point. We are also planning to add other helpers for client side auth.

[rebaz94]

Yes, some of it. There is already a package. golang.org/x/oauth2, that handles basic OAuth. We also have implementations of some of the additional RFCs in internal/oauthex. We will make them visible at some point. We are also planning to add other helpers for client side auth.

Great. I already use the oauth2 package, but it's missing dynamic client registration. If the main logic for that was added to it, I think it doesn't need to define handlers. Developers can do that easily themselves.

[jba]

but it's missing dynamic client registration.

DCR is at https://github.com/modelcontextprotocol/go-sdk/blob/main/internal/oauthex/auth_meta.go#L299. We have plans to expose it under an experiment tag.

[jba]

See #558.

[maciej-kisiel]

I'm trying to address client-side OAuth in #785. Since you have been active here, maybe you would be interested to take a look and review. Otherwise, sorry for the noise!

@rebaz94