Add: support for oauth 2.1 authentification for Remote MCP Server

[Fraggle]

Description

Add support for the new Oauth flow when connecting RemoteMCPServer as workspace connection.

Note:

• this PR do not allow picking between personal / workspace connection, it will be implemented in a subsequent PR.
• I forked the official lib to add a callback to get the discovered oauth server metadata (will try to get it merged upstream)

New code

• MCP provider in oauth service & front
• New MCPOAuthProvider to handle the oauth callback from the MCP client (more about it below)
• Endpoint to check if a remote MCP server requires oauth.

Refactored

• Improved notification and error message to use the server name instead of "MCP Server" when possible, show more detailed errors.
• Split the big front oauth PROVIDER_STRATEGIES to use file per provider (similar to what we do in oauth).
• Modals to create and connect an MCP server to support the new oauth flow.

How it works

The official MCP sdk can do most of the flow and requires a class implementing OAuthClientProvider (source) with callbacks to retrieve / save the information & tokens.

However, we want the flow to be handled by our own oauth service so it works naturally with everything else.

I didn't want to re-implement the discovery of the metadata because it quite intricated with the MCP specificities and I prefer to get any fix they do there (such as this one 2 weeks ago) for "free".

So what I did is that in our implementation of OAuthClientProvider:

• if we have a existing MCP server passed in : I try to fetch the token (either by sharedSecret or via an oauth connection) in the "tokens()" callback => then the MCP client will simply use them in the headers and stop the flow.
• if we don't have one (creation of remote mcp server or reconnection), I let the sdk do all the discovery until it reach "saveClientInformation()" where I raise a specific error with all the metadata we need.

In the front code, I use the new endpoint to check if an mcp server (via it's url) requires oauth and if so, get the said metadata. Then It's similar to other providers except all metadata of the oauth server (tokens endpoint, auth endpoint..) are passed via the connection's metdata.

Tests

A lot of local test with unprotected mcp servers, api token protected mcp server (stripe), multilple oauth protected mcp servers (atlassian, linear, intercom, a nice list is here) as well as checking that gmail & salesforce were still working.

Risk

Medium, with the refactoring of the provider in front, I could have broke something (but I double-checked that the code was exactly the same).

Deploy Plan

Deploy oauth and front

[dust-agent]

Found several coding rule violations that need to be addressed.

[dust-agent]

Found several coding rule violations that need to be addressed.

[spolu]

I forked the official lib to add a callback to get the discovered oauth server metadata (will try to get it merged upstream)

That's a pretty big decision as it will require us to rebase adapt etc... which is toil for future us. How likely do you think you'll be able to merge upstream?

Where's the diff of that fork? Needs to be reviewed as well here 👍

[Fraggle]

That's a pretty big decision as it will require us to rebase adapt etc... which is toil for future us.

I agree.

How likely do you think you'll be able to merge upstream?

Quite likely.

Where's the diff of that fork? Needs to be reviewed as well here 👍

It's ultra light : dust-tt/typescript-sdk@bca26e4
(the package.json part is only needed because it's not a real npm package)

[spolu]

Made a first batch of comments on the oauth flow. I think we can avoid adding a new MCPOAuthExtraConfig which is really not desirable in oauth/client/setup.ts since the only non string fields used is grant_type_supported which we know the constraints of as soon as we get it and can error early.

[spolu]

LGTM modulo name change of the endpoint. Ideally of course we have a more principled approach to discovering metadata that does not involve throwing an error 👍 But can move forward as is.

[spolu]

Of course feedback here is that the PR is incredibly long. I reckon it's very hard to split but it was really really f**ing hard to review :)