MCP

背景与目标 我们团队维护一个内部数据服务，管实验数据的查询、文件和报告，最近在做的事情是把它暴露成 MCP Server，让 agent 直接查数据、下载文件、导出报告。 工具写完只是一个开始。这个服务里的数据涉及部门和委托公司，不是随便谁都能看的，所以认证和权限必须先解决。企业内部有现成的单点登录服务（下文简称 SSO），最终目标是：用户在 agent 平台里点一次登录，走 SSO 完成认证，之后 MCP 工具调用自动带上身份，数据权限对齐既有系统的语义。 这件事在 9 月于测试环境全链路跑通了。这篇文章记录协议原理、实现拆解和踩过的坑，协议部分和语言无关，换技术栈也能照着做。 主流架构：MCP 授权是什么设计 先说结论：MCP 的授权规范复用了 OAuth 2.0，把 MCP Server 定位成受保护资源（Resource Server），而不是授权服务器。你的 server 从头到尾不碰密码、不发 token、不管理会话，只做一件事：校验请求头里的 Bearer JWT。 我们这次的完整架构长这样： ┌─────────┐ 登录+授权(PKCE) ┌─────────┐ ①授权码流(OAuth客户端) ┌─────────────┐ │ Browser │ ───────────────> │ SSO │ <───────────────────── │ agent 平台 │ │ (用户) │ <─ 302 code 回调 │ (OIDC) │ ②JWT access token │ (连接服务) │ └─────────┘ (平台固定回调) └────┬────┘ ③token托管/自动续期 └──────┬──────┘ │ │ ⑤下发连接 │ ④ JWKS 公钥(server拉取缓存) ▼ ▼ ┌────────────────────────────────────────────────┐ │ MCP Server（任意技术栈） │ │ ⑥ 收 Bearer JWT → 本地验签 → 工具级数据权限 │ └────────────────────────────────────────────────┘ 流程分解一下： ...