一句话定义：MCP 的 OAuth 授权流程，是远程 MCP（Model Context Protocol）服务器在不接触用户密码的前提下，确认三件事的一套标准流程：这个客户端是谁、用户是否同意、发出去的令牌该给谁用。
为什么需要这套流程
本地跑的 MCP 服务器（通过 stdio 启动的那种）是用户自己拉起来的，天然可信。但远程 MCP 服务器面对的是互联网上所有人，它不能只听客户端说一句“我是某个知名 AI 客户端”就开门，因为这种声明谁都能伪造。
打个比方：远程 MCP 服务器是一栋写字楼，授权服务器是楼里的前台。客户端是个陌生访客。前台不会把大门钥匙（用户密码）交给访客，只发一张写了“可去几层、有效期到几点”的访客证（access token），保安每次只认证。
实际路径：四步
1. 敲门被拒，拿到指引。客户端不带令牌直接请求远程 MCP 服务器，服务器返回 401，并在响应头里说明“我的授权服务器在哪”。这段信息通常来自受保护资源元数据（Protected Resource Metadata）。
2. 读规则、登记身份。客户端去读授权服务器的元数据（Authorization Server Metadata），了解端点与能力；如果服务器支持动态客户端注册（Dynamic Client Registration），客户端可以当场自助领一个 client_id，不必让用户去后台手动创建应用。
3. 用户点头，浏览器回调。客户端把用户导向授权页面，请求里带上 PKCE 的 code_challenge，以及标明目标资源的 resource 参数。用户登录、点“允许”之后，授权服务器把授权码（code）通过回调地址送回客户端。回调地址常见的是本机 localhost 的某个端口，或客户端注册的自定义 URI scheme。注意跑腿的是系统浏览器，它拿不到 code_verifier。
4. 换令牌。客户端用 code 加 code_verifier 去换 access token，此后每次调用 MCP 服务器都带这个 Bearer 令牌。服务器校验签名、有效期，以及令牌的受众（audience）是不是自己。
第 3、4 步里 PKCE（Proof Key for Code Exchange）是关键：回调地址是公开的，恶意应用有可能截获授权码；但没有最初的 code_verifier，截获的码换不出令牌。resource 参数则防止“A 服务器的令牌被拿去调 B 服务器”。
和相邻概念的区别
| API Key | OAuth 授权码 + PKCE | |
|---|---|---|
| 谁签发 | 服务方手工发或用户自建 | 授权服务器按流程自动签发 |
| 用户密码是否经手客户端 | 不涉及，但密钥长期有效 | 完全不经过客户端 |
| 权限粒度 | 通常一把钥匙全通 | 可用 scope 细分，按资源限定 |
| 撤销 | 逐个通知持有方更换 | 在授权服务器集中撤销 |
对从业者的意义
写远程 MCP 服务器的人，别自己发明一套令牌，把授权外包给成熟授权服务器，并且务必校验令牌受众；写客户端的人，要用系统浏览器而非内嵌 WebView 承载授权页，并处理好回调端口；普通用户第一次连远程 MCP 时会看到一个“某某应用请求访问”的同意页，那就是这套流程在跑，遇到不认识的请求方，停一下再点。规范细节仍在演进，具体字段与要求以官方规范页面为准。