Handle OAuth lifecycle completely within the MCP server

[alistair3149]

Describe the problem

User should not need to create OAuth client, copy the token, and set it up in the MCP server manually.
The process introduces more friction to the user flow, and increase additional security risks.

This becomes important when the MCP server is being hosted remotely, as we might not be able to ensure a secure way to pass the OAuth token.

Describe the solution

When an action (e.g. using a tool) requires elevated permission, the MCP server should create an OAuth client on behalf of the user, and handle the tokens internally.

Additional context

• OAuth 2.0 REST endpoints from Extension:OAuth
• MCP Security Best Practices (Version 2025-06-18)

[malberts]

This introduces a new problem: the user must then be authenticated via MediaWiki directly in order to do the API call to create a new OAuth client. This means our config needs to track the username and password (or prompt the user in the chat), or use a different token. At that point it is not obvious that there is any additional security risk in our current approach.

Secure secret management might not necessarily be a problem that the MCP server itself should solve (by which I mean how it is stored).

Our current approach is slightly less risky in terms of having more control over the actual OAuth client setup.

However, our current approach of using the "Owner only" client ID allows us to use it as the access token without further authorization. There is a different approach where the client has to be authorized and then receives the access token from the wiki: https://www.mediawiki.org/wiki/OAuth/For_Developers#Authorisation_2. In that case a compromised client ID cannot be used immediately, because its usage needs to be authorized in the wiki. However, this still requires storing the Client ID somewhere.

(Due to terminology it is not clear to me if this issue intends to create the client via API, or whether it refers to the authorization flow of getting a new access token.)

[JeroenDeDauw]

What I am seeing for other MCP servers is that they require an API key in their config (ENV var). We should probably not diverge from that unless we have a sufficiently strong reason, which we do not seem to have, and which I imagine we cannot have without more adoption first and people telling us the current approach is problematic.

[alistair3149]

ENV variables are not viable for authenticating the user when there are multiple users accessing one MCP server, which is the use case for first-party remote MCP server. The first-party implementation is gaining traction (e.g. Atlassian, PayPal, Webflow, etc.), and it should be something to look into.