本地 MCP 服务器靠环境变量传凭证就够了；一旦服务器挂到公网上，就必须回答三个问题：谁在调用、他有哪些权限、凭证什么时候失效。这三点就是 MCP 授权要解决的，而它的答案是标准化的 OAuth 2.1，不是自己发明一套 token 。
角色分工：资源服务器与授权服务器分离
MCP 的授权设计遵循 OAuth 2.1 的分工：
| 角色 | 由谁承担 | 职责 |
|---|---|---|
| 资源服务器 | 你的 MCP 服务器 | 校验访问令牌，决定是否响应请求 |
| 客户端 | AI 应用（编辑器、桌面端） | 代表用户申请令牌，携带令牌调用工具 |
| 授权服务器 | 独立服务或第三方身份提供商 | 与用户交互、签发令牌 |
关键点是MCP 服务器本身不签发令牌，它只校验。把登录、多因素、审计这些脏活交给成熟的身份提供商，是避免自己踩安全坑的最佳路径。
四步握手流程
- 初始握手被拒：客户端首次请求，服务器返回 401，并在响应头里给出受保护资源元数据的地址，告诉客户端去哪里找授权配置。
- 拉取资源元数据：客户端按地址取回文档，得到授权服务器地址与支持的权限范围列表。
- 发现授权服务器：客户端向授权服务器的元数据端点（OIDC 发现或 OAuth 授权服务器元数据）请求端点信息，拿到授权地址、令牌地址等。
- 注册并跑授权码流程：客户端完成注册（预注册、客户端 ID 元数据文档或动态注册三选一），随后走带 PKCE 的授权码流程拿到令牌，重试原请求。
没有令牌时必须在 HTTP 层返回 401，而不是在工具结果里返回一个错误信息。规范要求受保护的资源在 HTTP 边界就拦截，这样客户端才会触发标准的授权流程。
权限范围：按最小够用原则申请
服务器应该在 401 响应的头部给出本次操作所需的权限范围，客户端应当以它为准，而不是自作主张申请全部。这样做的好处是：一个只读工具不会顺手拿到写权限，用户也能看懂自己到底授权了什么。
推荐的客户端行为顺序是：优先用 401 响应里给出的范围；没给的话，用资源元数据里声明的基础范围；仍然不够时，再通过增量授权补充，而不是一次性索取所有权限。
整服务器授权还是按工具授权
- 整服务器授权：所有请求都必须带令牌，实现简单，适合全部工具都敏感的场景。
- 按工具授权：公开工具免令牌，只有敏感工具触发授权。实现上要在请求入口检查本次调用是否命中受保护工具，命中且无令牌才返回 401 。
混合场景建议选后者：它让同一个服务器既能提供公开查询，也能提供需要身份的写操作，用户体验不会因为一个工具而被整体挡住。
实现清单
远程 MCP 服务器上线前必查
- 受保护资源元数据端点可访问，内容正确指向授权服务器。
- 授权服务器端点支持标准的元数据发现，客户端能自动完成配置。
- 令牌以 JWT 校验时，务必核对签发方与受众，确认令牌是发给本服务器的。
- 令牌受众绑定：受众不符的令牌一律拒绝，避免跨服务重放。
- 无令牌访问受保护工具返回 HTTP 401 而非工具级错误。
- 敏感操作额外增加人工确认环节。
和其他环节的关系
授权建立在 HTTP 类传输之上，如果还在选传输方式，先看stdio 与 HTTP 传输的取舍。本地运行的服务通常不需要这套流程，用环境变量凭证即可，这也是二者最实际的分界线。
授权解决的是”允许调用”，不等于”调用内容安全”，提示词注入与数据外泄风险依然存在，完整的风险清单见MCP 安全风险。准备把服务发布出去时，配置的托管与分发方式参考MCP 服务器发布分发。
延伸阅读：MCP 安全风险清单本地 stdio 服务器也必须接 OAuth 吗？
不必。本地进程运行在用户自己的机器上，用环境变量或第三方库的凭证就够了，OAuth 是为远程 HTTP 传输设计的。
一定要用动态注册吗？
不是必须。规范提供了客户端 ID 元数据文档、预注册、动态注册三种方式，动态注册已处于兼容保留状态，新实现优先用前两种。
令牌过期了怎么办？
客户端应先用刷新令牌换取新令牌，失败再走完整的交互式授权。是否支持刷新取决于注册时声明的授权类型以及授权服务器是否支持离线访问。
权限不够时如何提示用户？
服务器返回 403 并在响应头里带上所需的增量范围，客户端据此发起一次增量授权，把新范围与已有范围合并后重试。
评论 (0)