2025-04

The first regular tech blog in April

基于MCP协议中SSE请求的一些思考

帖子地址：点击跳转

事情的起因是这样的

我在这篇帖子中给L站编写了一个简单的MCP Server

https://linux.do/t/topic/527169

https://github.com/Pleasurecruise/linux-do-mcp

我一开始的设想是能够部署一个远端的SSE地址这样大家在使用时就只需要填一个链接了

然而事与愿违

现如今我们在使用一些MCP server的时候，难免会遇到一些需要用户高权限的情景。这种情况又分为两种：

目前似乎还没有一种成熟的方式来解决这个问题最近看到高德地图对于他们自家的地图MCP server给出的解决方法类似如下

https://mcp.amap.com/sse?key=xxx

是通过将apikey作为请求参数进行传输的

那么问题来了

这样的方式真的安全或者具有普适性吗

高德地图因为有大厂的光环以及是自家提供的服务这样传输apikey几乎不存在安全问题

但是如果当个人开发者想要编写MCP server 用的是自己提供的远程地址向你请求如此高权限的apikey时你敢提供给他吗

另外将env作为http请求参数进行传输的方式本就不太合理

我看目前主流的解决方式是通过Oauth2认证的方式

高德地图似乎是因为没有Oauth2认证？还是因为目前mcp技术尚不成熟所以就没这样做？

于是话又说回来了，既然这样的方式传输env不合理那就只能采取OAuth认证的方式

然后我就去研究了一下LINUX DO CONNECT的OAuth授权，

从用户信息端点：https://connect.linux.do/api/user来看最终的响应确实会返回一个api_key字段，但是只有查看用户基本信息的权限

向我的在项目中写的，需要用户鉴权比如（查看发布，书签等等都无法实现了

综上所述，所以我给linux-do-mcp部署sse地址的设想只能搁置了