研究报告 · 约 24,565 字 · 预计推送 3 部分

身份与权限架构：OAuth 2.1、OIDC、PKCE、API key、服务账号的边界 未开始

目录

题记与说明

综合报告（最终稿）· 2026-10-31

本文由两份章节稿综合而成，已合并两稿并消除其间的重复与分歧（2.4 节与 3.4 节的重复推荐按"一处保留结论、一处交叉引用"处理）：
- 纵轴（发展史）：parts/2026-10-31-身份与权限架构-OAuth-OIDC-PKCE-vertical.md
- 横轴（2026-10-31 时间截面对比）：parts/2026-10-31-身份与权限架构-OAuth2.1-OIDC-PKCE-APIkey-服务账号-horizontal.md

关键事实均附来源链接；OAuth 2.1 草案状态等时效性数据在本次综合时经 IETF Datatracker 实查复核，两稿的一处日期分歧已在 1.6 节裁定。两稿中无法进一步核实的存疑项集中列于第 4 节。

本最终稿按独立审读意见逐条修订（2026-10-31）：修正 1.7 总表与 2.1 题眼的自相矛盾、统一免费档数字口径、降格并补证"三层混淆"论断、补 implicit / state / DPoP-vs-mTLS 机制说明、删除对原稿结构的悬空指涉、明示 3.4 节适用范围、补 MCP 2025-11-25 与 2026-07-28 两版授权规范的直接来源链接、存疑项独立成节并消除 2.4/3.4 重复推荐。

TL;DR

身份凭证分三层：认证（OIDC，你是谁）、授权（OAuth 2.1，用户允许你做什么）、机器身份（API key/服务账号），混淆三层是最常见的认证事故根源之一。纵轴：二十年演进由客户端形态驱动（浏览器→手机→受限设备→AI 代理），协议从密码反模式收敛到授权码+PKCE。横轴：OAuth 2.1 截至 2026-10-31 仍是草案，却已被 MCP 定为强制基线——草案即事实标准。边界持续收缩：implicit/ROPC 被判死，API key 退守公共数据标识，服务账号转向联邦短时凭证。个人应用：登录用 OIDC，代用户访问用授权码+PKCE，机器用服务账号，公共数据用 API key，只有自己用就什么都别建。

一、纵轴：发展脉络——五条支流汇成一条河

"身份与权限架构"这个课题实际由五条支流构成：

  1. 授权（Authorization）：OAuth 1.0 → OAuth 2.0 → OAuth 2.1；
  2. 认证（Authentication）：OpenID 2.0 → OpenID Connect（OIDC），ID Token / JWKS / Discovery；
  3. 令牌安全加固：Bearer 令牌攻防 → PKCE（RFC 7636）→ DPoP（RFC 9449）→ RFC 9700 安全最佳实践；
  4. 应用级凭证（API key / PAT）：各平台自发的静态密钥 → 细粒度化、短期化（GitHub fine-grained PAT、GitHub App）；
  5. 机器身份（服务账号 / workload identity）：Google 服务账号（2012）→ JWT 断言交换 → 云厂商的短期角色凭证。

五条支流的合流点就是 2020 年启动的 OAuth 2.1：它不是一个新协议，而是把 OAuth 2.0 加上十几年的安全实践与被广泛采用的扩展"折叠"回一个规范。理解这段历史的关键问题只有一个：什么凭证、在什么主体、什么场景下使用，边界在哪里。

1.1 前史：密码反模式（2006–2007）

2006 年 11 月前后，Twitter 的 Blaine Cook 在为 Twitter 实现 OpenID 时意识到，当时第三方应用接入 API 的通行做法是让用户把账号密码直接交给第三方——这就是著名的"密码反模式"（password anti-pattern）。Cook 后来自述："OAuth came out of my worry that if the Twitter API became popular, we'd be spreading passwords all around the web."（来源：oauth.net/about、Wikipedia: OAuth）

2007 年，Cook（Twitter）、Larry Halff（Ma.gnolia）、Chris Messina 等人组成社区起草规范；2007 年 12 月 OAuth Core 1.0 社区规范定稿——第一批"自下而上"的开放标准之一，作者们后来被称为 "OAuth founding fathers"（来源：oauth.net/about）。这一阶段没有 IETF、没有大公司标准化流程，驱动力是 API 生态爆发（Twitter、Ma.gnolia、Google Data APIs）导致的用户密码四处扩散，以及一个关键认识：OpenID 解决的是"登录"，不是"授权"，两者是不同的问题。

1.2 OAuth 1.0：请求签名时代（2008–2012）

同期平台侧：2010 年 9 月 Google 宣布 Apps APIs 全面支持 OAuth 并启动旧凭证迁移——旧的 ClientLogin（直接把用户名密码发给 Google 换令牌）正是"密码反模式"的平台化样本，2012 年宣布弃用，2015 年 4 月 20 日彻底关停（来源：Google Developers Blog, 2010-09、mike42.me: Deprecated Google APIs）。

1.0 的教训：签名方案安全但实现极其痛苦——每个请求都要规范化参数再签名，库实现普遍有 bug，平台排障困难。行业开始想要一个更简单的协议。

1.3 OAuth 2.0：授权框架 + Bearer 时代（2010–2015）

这一阶段形成了延续至今的默认分工——OAuth 管"应用代表用户做什么"（授权），OIDC 管"这个用户是谁"（认证），而 API key / 服务账号代表"应用自己"，与前两者是不同类型的凭证。但 2.0 的 implicit 与 password 两种许可，埋下了此后十年收紧的伏笔。

1.4 客户端形态补全：移动、原生、受限设备（2015–2019）

驱动因素：授权码中间人攻击（App 切换被劫持）等真实攻击出现；各操作系统对内嵌 WebView 与第三方 Cookie 的限制收紧；IoT/CLI 场景"设备上无法输入密码"的现实；令牌泄露事件频发催生"最小权限 + 短期"的令牌形态。

1.5 安全收紧与 OAuth 2.1 合流（2020–2025）

驱动因素：implicit 流把 access token 直接放进重定向 URL 的 fragment 交给浏览器端 JS，而规范层面它就拿不到 refresh token（RFC 6749 §4.2.2 明确 implicit 响应中"授权服务器 MUST NOT 签发 refresh token"）；它赖以"静默拿令牌/续令牌"的机制——授权服务器的会话 Cookie 在第三方上下文（隐藏 iframe 静默认证）中生效——被 Safari ITP 率先、其余浏览器陆续跟进的第三方 Cookie 封锁整体拆除，无 refresh token 可续命的 implicit 就此无路可走；大规模令牌泄露事件推动"最短路径"（authorization code + PKCE）成为唯一推荐；行业意识到"框架 + 最佳实践"两件套对开发者过于晦涩，干脆把最佳实践折回主规范（来源：RFC 6749 §4.2.2）。

1.6 AI 代理时代：OAuth 2.1 成为基础设施默认（2025–2026）

两稿日期分歧的裁定：纵轴稿写 draft-16"更新于 2026-09-02"，横轴稿写"2026-09-03"。本次实查 Datatracker 页面确认两者都对：2026-09-02 是 Datatracker 元数据的"最近更新"时间戳，2026-09-03 是草案文档自身标注的日期——指同一个 draft-16 修订，不构成事实矛盾。本报告统一表述为"文档日期 2026-09-03（Datatracker 元数据 2026-09-02）"。

驱动力与 2006 年遥相呼应：AI 代理需要"代表用户"或"以服务身份"调用大量第三方系统，MCP 生态直接选择站在 OAuth 2.1 肩膀上而不是发明新协议——授权的问题域没变，变的只是客户端形态（浏览器→手机→CLI→代理）。

1.7 阶段总表与贯穿全程的三条边界逻辑

阶段时间版本节点主要参与者核心驱动
前史2006–2007OAuth Core 1.0（社区）Twitter、Ma.gnolia、Messina密码反模式
OAuth 1.x2008–20121.0a（2009-06）、RFC 5849（2010-04）IETF WG、Eran Hammer、Google请求签名；但实现痛苦
OAuth 2.02010–2015RFC 6749/6750（2012-10）、Google 服务账号（2012）、OIDC（2014-02）、JWT（2015-05）、PKCE（2015-09）IETF、OpenID Foundation、Google移动化、TLS 化；认证层（OIDC 2014）同期另行补齐，OAuth 本身仍只做授权
客户端补全2015–2019RFC 8252（2017-10）、GitHub Apps（2017）、RFC 8628（2019-10）IETF、Apple/Google、GitHub原生/设备/CLI 场景；最小权限萌芽
收紧合流2020–2025OAuth 2.1 草案（2020）、fine-grained PAT（2022-10）、DPoP（2023-09）、RFC 9700（2025-01）IETF、GitHub、身份云厂商攻防实践、浏览器生态变化
代理时代2025–2026MCP 采用 OAuth 2.1（2025）、draft-16（2026-09）IETF、Anthropic/MCP 生态AI 代理成为新客户端形态

贯穿全程的三条边界逻辑（本课题"边界"的历史答案）：

  1. 用户在场 vs 用户不在场：有用户交互 → OAuth 授权码流 + PKCE（浏览器/loopback/设备流）；无用户交互 → 服务账号/角色/签名 JWT；
  2. 应用身份 vs 用户身份：API key、服务账号代表"应用自己"（只适合标识与机器对机器，不适合授权用户数据）；OAuth 令牌与 PAT 携带用户委托；
  3. 长期凭证 vs 短期凭证：从 2007 年到 2026 年，方向始终是"更细粒度、更短期、可撤销"——GitHub 从 PAT 到 GitHub Apps 再到 fine-grained PAT，云厂商从长期密钥到 workload identity。

二、横轴：横向对比——2026-10-31 时间截面

2.1 先画坐标：三个问题、三层边界

身份与权限的方案，本质上是回答三个不同的问题，混淆这三者是最常见的一类"认证事故"根源：

边界第一条（题眼）：OAuth 本身不认证。 OAuth 2.0 是授权框架，"用微信/GitHub 登录"能成立，是因为上面叠了 OIDC（ID Token）。API key 更不认证用户——按 Google 官方口径，它"标识的是项目而非用户"，只适合公共数据访问与配额/计费归集（来源：Google Cloud: Why and when to use API keys）。

"最常见的一类"有据可查：RFC 9700 记载的 mix-up 攻击（§4.4） 与授权码注入（§4.5），正是令牌/回调层混淆导致"受害者在不知情中登录成攻击者账号"的真实攻击类别——1.0a 修复的会话固定是它的前身；MCP 在 2025–2026 年把 "token passthrough / audience 混淆"列为禁令（见 2.3 节），则是同一类混淆在 AI 代理形态下的重演（来源：RFC 9700 §4.4/§4.5）。

2.2 凭证与协议速查表（边界总览）

方案本质证明的是谁典型场景凭证有效期主要误用（边界外）
OAuth 2.1 授权码 + PKCE委托授权框架用户对应用的授权第三方应用代表用户访问其资源access token 短期（分钟~小时级），refresh token 配轮换当登录系统用（须叠 OIDC）
OIDCOAuth 之上的认证层用户身份（ID Token 是 JWT）"用 Google/微信登录"ID Token 分钟级把 access token 当身份用
PKCE授权码防拦截机制——（不是身份方案）一切授权码流程——用 plain 模式（已被 2.1 删除）
API key项目/应用标识符项目，不是人公共数据、配额与计费归集长期，手动轮换当作用户身份或细粒度授权用
服务账号机器身份 + 策略绑定程序/工作负载服务间调用、自动化任务最佳实践趋短（或无静态密钥）密钥泄漏、权限过大
Passkey/WebAuthn用户认证因子人登录第二因子或替代密码绑定设备/同步链恢复流程没设计好
SAML企业 SSO 联合（XML）企业员工Workforce SSO、传统企业断言分钟级新互联网产品首选（过重）
mTLS / DPoP发送方约束（证明持有者）持有私钥的客户端高安全 M2M、令牌防盗用证书/token 周期通用 Web 场景硬上（运维成本高）

2.3 协议层横向对比

维度OAuth 2.0 (RFC 6749, 2012)OAuth 2.1（草案）OIDC Core 1.0 (2014)SAML 2.0 (2005)Passkeys/WebAuthnAPI key
解决的问题授权（delegation）2.0 的安全收敛版基于 OAuth 的认证企业 SSO 联合用户认证（替代密码）应用标识
标准状态RFC草案（-16，文档日期 2026-09-03；目标 2026-12 进 IESG）稳定稳定（遗留）W3C/FIDO 稳定无标准，各平台自定义
PKCE建议公共客户端全体强制，仅 S256继承 OAuth——————
implicit / ROPC存在但已不建议删除继承——————
生态现状全网基座MCP 强制采用中登录事实标准企业 SSO 存量消费端 ~50 亿枚云厂商 API 默认
主要风险老配置的坑（implicit 等）尚无（未定稿）token 类型混淆XML 签名实现复杂恢复流程静态泄漏

来源：draft-ietf-oauth-v2-1（Datatracker，本次综合实查）、RFC 9700、OIDC Core、RFC 7636 (PKCE)。

逐项要点：

2.4 实现层横向对比：真正的选型战场

协议是公共品，差异化竞争发生在"谁替你把协议做对"。三条路线：托管 IdP（省心、按月费）、自托管 IdP（可控、运维成本）、代码库级认证（嵌进应用、无 MAU 计费）。

托管 IdP（SaaS 认证）

服务免费档（2026 口径）付费起点协议/能力适合
Auth0 (Okta)25,000 MAU（从 7.5K 扩容）Essentials 约 $150/月OIDC/SAML/企业级最全需要企业特性且预算够
Amazon Cognito10,000 MAU（Lite 档）Lite/Essentials/Plus 分档OIDC/SAML，AWS 深度绑定已在 AWS 且能接受复杂定价
Clerk50,000 MRU（月留存用户）按留存用户阶梯OIDC，组件化 UI前端团队要"开箱即用的登录 UI"
Supabase Auth~50,000 MAUPro $25/月OIDC，与数据库一体已用 Supabase 的全栈个人项目
Firebase Auth基础登录免费高级功能需 Identity Platform 付费档OIDC 为主移动端/原型
价格为 2025–2026 年对比文章口径（来源：Zuplo 认证定价对比、DesignRevision 对比（2026-02）、DesignKey SaaS auth 对比），各家免费档近年频繁调整，决策前以官方 pricing 页为准。同一批文章的规模化测算：Auth0 在 10 万 MAU 量级约为 Supabase 的 10–35 倍，Cognito 的分档加价经常"越用越贵"（二手测算，见第 4 节）。

自托管 IdP

项目语言/栈定位成熟度适合
KeycloakJava企业 workforce SSO 的"重型坦克"（OIDC/SAML 全，内存 GB 级）最高企业/协议全要求
AuthentikPython最易上手的内部 SSO（OIDC/SAML/proxy）高（homelab 首选）个人 homelab、内部应用
LogtoTypeScript轻量 CIAM，开发者友好中高中小产品的 C 端登录
ZitadelGo多租户 + 内建审计中高多租户 SaaS
OryGoAPI-first 模块化套件（需组装）中定制化 API 产品

来源：r/selfhosted 社区对比帖、Zitadel vs Keycloak（厂商博客，注意立场）。自托管 IdP 对个人应用是否"过度设计"、何时才值得上，本报告统一收在 3.4 节的场景决策表里给结论；若目的就是学习或 homelab 本身，它自然另当别论。

代码库级认证

库形态特点2026 年状态
Better AuthTypeScript 库，框架无关数据库 session、插件生态（2FA/passkey/组织）、自托管零 MAU 费2024 年出现，上升极快，新项目社区默认推荐
Auth.js (NextAuth v5)TypeScript 库老牌、OAuth provider 生态最大稳定维护，v4→v5 迁移有摩擦
Lucia——曾是最小化代表已转型为教学资源（"a pattern, not a package"）

说明：此表为原始检索的社区聚合观点（部分直接链接未留存，属二手聚合，见第 4 节），以 better-auth.com 与 authjs.dev 官方文档为准。三者的共同点：认证逻辑嵌在你的应用和数据库里，没有 MAU 计费、没有第三方停服风险。"个人应用最终该选哪条路线、哪个产品"，本报告统一在 3.4 节给出结论与推荐栈，此处不重复。

2.5 机器身份层横向对比

凭证形态有效期撤销最佳实践边界
API key静态随机串长期可撤销只标识项目/公共数据；不进前端、不进 URL、不进 git
服务账号 + JSON 密钥静态私钥文件长期IAM 撤销尽量不下载；必须用时最小角色 + 定期轮换
工作负载身份联邦短时令牌换发短（分钟~小时）天然过期云上默认：GCP/AWS/Azure OIDC 联邦替代静态密钥
CI OIDC（GitHub Actions → 云）短时 JWT作业级天然过期云部署首选，secret 里不再存云密钥
GITHUB_TOKEN作业级自动 tokenjob 结束即失效自动Actions 默认，最小权限
GitHub App 安装 token短时~1 小时吊销安装跨仓库/组织自动化，优先于 PAT
Fine-grained PAT静态长令牌人工设过期可撤销最后手段：个人脚本、CI/CD 外的临时用途
mTLS / DPoP发送方约束证书/令牌周期证书吊销高安全 M2M；个人应用一般不必上

来源：GitHub Docs: Authentication in a workflow、GitHub Apps vs OAuth Apps、Google Cloud Blog: 服务账号认证、Google Cloud: 认证方式选择、Auth0: API keys → OAuth 迁移论述。

要点：Google 官方建议机器对机器优先用 IAM 绑定的服务账号、signed JWT，尽量避免下载长期 JSON 密钥，在云上用"附加服务账号"或 Workload Identity Federation 获取短时凭证；GitHub 侧同理——Actions 默认用最小权限的 GITHUB_TOKEN，部署上云用 OIDC 联邦换短时云凭证，GitHub App 短时安装 token 优先于 PAT，fine-grained PAT 只是最后手段。机器身份的趋势是"短时化、无钥化、身份内置"——能联邦就不发静态密钥，能 job 级生命周期就不跨作业复用。

补充机制说明（DPoP 与 mTLS 的差异与取舍）：二者同属"发送方约束"——把令牌绑定到客户端持有的私钥，令牌被偷也无法在其他客户端使用——但作用层级与成本不同。DPoP（RFC 9449）在应用层：客户端对每个请求用自有非对称密钥签出一个短时效 JWT 证明，纯代码即可实现、不需要任何证书基础设施，适合互联网 API 与纯软件客户端，代价是每个请求多一次签名计算、且防护止步于应用层；mTLS（RFC 8705）在传输层：TLS 握手阶段即双向验证证书，保护覆盖整条连接、生态成熟，但需要证书签发、轮换、吊销的完整 PKI 运维。取舍：具备企业 PKI 与网关能力的高安全 M2M 选 mTLS；跨组织的互联网 API 场景选 DPoP；个人应用两者一般都不必上（来源：RFC 9449、RFC 8705）。

2.6 2026 时间截面的三个新变量

  1. MCP 把 OAuth 2.1 变成 AI 时代的强制基线。 MCP 授权规范要求：授权服务器 MUST 实现 OAuth 2.1；客户端 MUST 实现 PKCE（S256）；MUST 使用 resource 参数（RFC 8707）做 audience 绑定；MCP 服务器 MUST 实现 Protected Resource Metadata（RFC 9728）并禁止 token passthrough；动态客户端注册为 SHOULD（来源：MCP 授权规范 2025-06-18、RFC 8707、RFC 9728）。"给 AI Agent 做的 MCP 服务器要不要支持 OAuth"，2026 年的标准答案已经是"HTTP 传输就必须"。
  2. 托管认证的免费档大跃进 → 个人应用认证成本 ≈ 0。 Auth0 免费档从 7,500 → 25,000 MAU，Clerk 扩到 50,000 月留存用户，Supabase ~50K MAU（来源：DesignRevision 2026-02、Zuplo）。叠加代码库级方案（Better Auth/Auth.js）零 MAU 费，"自己手写密码存储"在个人项目里已经没有经济上的借口。
  3. Passkeys 越过临界点。 消费端 50 亿枚在用、90% 认知率（FIDO Alliance 2026），企业端 +412%（Descope）。个人应用加 passkey 的边际成本接近零，值得默认开启——同时必须设计好恢复路径（passkey 体系公认的最弱一环）。

三、交叉洞察：两轴合起来说明了什么

3.1 边界是攻防打出来的，不是设计出来的

把纵轴铺开再看横轴的每一条 "MUST"，会发现一个规律：现在边界上的每一道线，背后都是纵轴上的一次真实事故或一类新客户端的倒逼。会话固定攻击打出 1.0a；签名库实现质量参差打出"安全托付 TLS"的 2.0；Bearer 令牌"丢了就能用"打出 PKCE、DPoP 和 RFC 9700；浏览器封杀第三方 Cookie 打死了 implicit（它靠授权服务器 Cookie 在隐藏 iframe 里静默发令牌、续令牌，Cookie 一被封杀这条静默通道即告断绝，机制见 1.5 节）；移动端无法保密 client_secret 打出 public client 概念与系统浏览器要求；IoT/CLI 打出 Device Flow；AI 代理打出 MCP 对 audience 绑定（RFC 8707）与 token passthrough 禁令的强制。反过来，横轴上那些"看起来过时"的东西（SAML、API key）没有被消灭，只是被压缩进历史给它们划定的生态位——企业存量 SSO 与"轻量公共数据标识"。

这给评估者的启示是一个可复用的问题：面对任何新凭证形态或新规范条款，先问"它防的是哪次事故、服务的是哪类客户端"。答不上来的条款大概率是过度设计，答得上来的条款才值得付出遵循成本。

3.2 三条边界逻辑在 2026 截面上的投影

纵轴总结的三条边界逻辑，在横轴的 2026-10-31 截面上全部找到了对应物：

横轴数据还补上了纵轴看不到的一面：边界之内已经 commodity 化（认证免费档普遍扩容至 2.5 万–5 万 MAU：Auth0 2.5 万、Clerk/Supabase 5 万；passkey 开箱即用、OIDC 处处兼容），因此 2026 年个人开发者的剩余风险几乎全部集中在边界之外的误用上——API key 当身份用、静态密钥进 CI、ID Token 与 access token 混用、refresh token 放前端。这就是为什么本课题的最终交付物是一张"边界速查表"（3.5 节）而不是一份"产品推荐榜"。

3.3 草案即事实标准：纸面状态 ≠ 事实状态

OAuth 2.1 从 2020 年个人草案到 2026 年仍是 "I-D Exists"，但 MCP 已经把它定为强制基线，RFC 9700 已经把它的核心条款固化为 BCP——生态采纳走在了 IETF 流程前面。判断一个标准的成熟度，要看"谁在强制采用它"，而不是只看"IETF 状态栏"。这是横轴对比对纵轴叙事的修正：如果只读规范流程，会得出"2.1 还没定稿、暂不采用"的误判；如果只看生态，又会忽略它毕竟不是 RFC、个别条款（如 S256-only）仍可能在定稿中微调。

实操含义：今天实现授权码流，就按 2.1 草案的方式写（PKCE S256 + 精确 redirect_uri + 无 implicit/ROPC）——这同时满足 RFC 9700 的合规要求，2.1 转正时零迁移成本。但在对外声称合规基线时，引用的应是已发布的 RFC 6749/6750/9700，而非草案。

3.4 对个人开发者的判断与建议（两稿建议的合并版）

适用范围：本节与 3.5 节的建议面向个人开发者与小团队——包括一人团队同样会遇到的个人脚本、CI/CD、个人 MCP 服务器等场景；企业 workforce SSO、Keycloak 级自托管选型只在 2.2–2.4 节给出对比坐标，本节不展开落地建议，企业读者请从 2.4 节的托管 IdP 企业版与自托管 IdP 对比出发另行评估。

纵轴稿与横轴稿各给了一套建议，二者高度重叠；本节将两稿建议合并为一张按场景展开的决策表，并统一共同原则。

共同原则（两稿合并）：不自建 IdP；不碰已被 RFC 9700 / OAuth 2.1 禁用的 implicit 与 password 流；授权码流程一律 PKCE(S256) + state + 精确 redirect_uri；密钥一律环境变量或系统 keyring，绝不进代码仓库；云上能联邦就不发静态密钥；上线前先想好密钥泄漏的撤销路径；不自研 OAuth provider、密码哈希以外的加密、JWT 签名算法选择——用库，别造轮子。

三件套各防一环：PKCE 防授权码在返回途中被中间人截获冒用——换令牌时必须出示当初随机生成的 verifier，截获者拿到的只是无用码；state 防 CSRF 与回调劫持/授权码注入——客户端发起授权前生成随机值存入本地会话，回调必须原样带回并比对，攻击者伪造或替换的回调对不上这个值，也就无法把受害者会话绑到攻击者的授权上（RFC 9700 §4.7 要求用 state 携带一次性 CSRF token，或以 PKCE/nonce 等效防护；其 §4.5 记载的授权码注入同样靠这一比对拦截）；精确 redirect_uri 防授权码经宽松的重定向匹配漏给第三方应用（来源：RFC 9700）。

场景正确工具要点
只有你自己用（个人仪表盘/工具）不建登录系统Tailscale/WireGuard 内网直达；或 HTTP Basic + TLS；要像样一点就单一管理员密码 + magic link
少量真实用户（几十到几千）Better Auth（新项目默认）或 Auth.js v5；不想碰认证代码则 Clerk/Supabase Auth 免费档零 MAU 费或免费档顶到产品验证期；开 passkey 插件与邮箱恢复
应用代用户访问第三方（GitHub/Google/Notion…）授权码流程 + PKCE(S256) + state + 精确 redirect URI本地用系统浏览器 + loopback 回调（RFC 8252）；纯后端 cron 用 Device Flow（RFC 8628）；token 只存服务端，能 httpOnly cookie 就 httpOnly
个人脚本/CLI 调第三方 APIAPI key 或 fine-grained PAT 一个 + HTTPS只勾需要的仓库与权限；存放环境变量或 OS keyring；不要为脚本实现 OAuth 服务器
自己的多个后端服务互调VPS：每服务独立 API key + 服务端哈希存储 + 可单独吊销；云上：服务账号/工作负载身份联邦拿短时凭证不下载 JSON 密钥文件；确需静态凭证时用"签名 JWT 换短期访问令牌"模式
CI/CDGitHub Actions 默认 GITHUB_TOKEN 最小权限；部署云资源用 OIDC 联邦不在 Secrets 存云密钥；任何 PAT 都应 fine-grained + 设过期且仅作最后手段
给自己的应用加"登录"（统一账号）托管认证服务（Auth0/Clerk/Supabase Auth/Logto）或现成 IdP（Keycloak/Authentik），走 OIDC 授权码 + PKCE个人应用只填 client_id 与回调 URL；单个用户/家人用的内部工具连 OIDC 都可省（反代基础认证 + HTTPS）
做了 MCP 服务器（HTTP 传输）OAuth 2.1 + PKCE + RFC 8707 resource + RFC 9728禁止 token passthrough，校验 audience

两个具体推荐栈（2026 时间截面）：

3.5 边界速查表（题眼的最终压缩版）

你想做的事正确工具越界行为
用户登录我的应用OIDC（ID Token）/ magic link / passkey用 access token 认身份；自写密码哈希以外的认证
用户授权我访问他在别处的资源OAuth 授权码 + PKCE(S256)implicit；密码模式；把 refresh token 放前端
标识"哪个项目在调我的公共 API"API key（配额/计费）把 API key 当用户身份或细粒度授权
我的服务调你的服务服务账号 / client_credentials / 联邦短时令牌共享一个"万能"API key；下载长期 JSON 密钥
CI 部署云资源OIDC 联邦Secrets 里存云 AK/SK；用经典 PAT
MCP 服务器（HTTP）OAuth 2.1 + PKCE + resource + PRMtoken passthrough；不校验 audience
高价值令牌防盗用DPoP / mTLS（发送方约束）——（个人应用可暂缓）

一句话版本：用户委托用 OAuth+PKCE，用户登录用 OIDC+passkey，机器用服务账号/联邦，公共数据用 API key，只有自己用就什么都别建。

四、存疑项：剩余不确定性与两稿存疑项（合并保留）

五、参考来源

协议与规范

MCP 与 AI 代理

平台官方文档

选型对比与市场数据

思考题（读完后想一想，参考答案可展开）

  1. 这份报告的核心论点是“身份凭证分三层，混淆三层是最常见的认证事故根源”。三层分别指什么、各由哪些方案承担？报告又用哪些真实攻击类别佐证这种“混淆”的危害？
    参考答案

    报告把身份凭证分三层：认证（OIDC 用 ID Token 证明“你是谁”）、授权（OAuth 2.1 管用户允许应用做什么）、机器身份（API key/服务账号标识程序），混淆三层是最常见的一类认证事故根源。题眼是“OAuth 本身不认证”：“用 GitHub 登录”能成立是因为叠了 OIDC，而 API key 按 Google 口径只标识项目而非用户。佐证：RFC 9700 记载的 mix-up 与授权码注入会让受害者“登录成攻击者账号”，1.0a 修复的会话固定是其前身；MCP 把 token passthrough/audience 混淆列为禁令，是同类混淆在 AI 代理形态下的重演。

  2. 实现层选型有托管 IdP、自托管 IdP、代码库级认证三条路线，各自的取舍是什么？结合报告给出的两个推荐栈，个人开发者应如何选择？
    参考答案

    托管 IdP 省心按月费，2026 年免费档大扩容（Auth0 25,000 MAU、Clerk 50,000 MRU、Supabase 约 50K MAU），但规模化后贵（二手测算：Auth0 约为 Supabase 的 10–35 倍）；自托管（Keycloak/Authentik 等）可控但运维成本高，个人原则是不自建 IdP；代码库级（Better Auth/Auth.js）零 MAU 费、无第三方停服风险。个人选法：新项目默认 Better Auth（栈 A 零月费，代价半天学习）；不想碰认证代码则用 Clerk/Supabase Auth 免费档（栈 B，代价是平台锁定与免费档条款变动风险）。

  3. 报告在第 4 节承认了哪些存疑项与局限？“草案即事实标准”这一判断（3.3 节）带来哪些误判风险与注意事项？
    参考答案

    存疑项包括：GitHub Apps“2017 年发布”未逐条核对 changelog；Google 服务账号 2012 年原始公告 URL 失联；CVE-2009-2904 与《Road to Hell》均依赖转述；托管 IdP 价格为对比文章口径（“Auth0≈10–35×Supabase”属二手测算）；Better Auth 等对比是社区二手聚合；passkey 数据部分来自利益相关方厂商，宜作量级参考。“草案即事实标准”的提醒：只看 IETF 状态会误判“未定稿就不采用”，只看生态又会忽略 S256-only 等条款仍可能在定稿中微调；应按 2.1 方式实现，但对外声称合规基线时引用已发布的 RFC 6749/6750/9700。

  4. 按 3.4 节决策表与 3.5 节速查表，个人开发者在“只有自己用”“应用代用户访问第三方”“脚本/CLI”“CI/CD”四类场景分别该怎么做？PKCE、state、精确 redirect_uri 这“三件套”各防哪一环？
    参考答案

    只有自己用：不建登录系统，Tailscale 内网直达或 HTTP Basic+TLS；代用户访问第三方：授权码+PKCE(S256)+state+精确 redirect_uri，本地用系统浏览器加 loopback 回调，token 只存服务端；脚本/CLI：一个 API key 或 fine-grained PAT（最后手段），放环境变量或 keyring；CI/CD：GITHUB_TOKEN 最小权限，部署上云用 OIDC 联邦、不在 Secrets 存云密钥。三件套：PKCE 防授权码被中间人截获冒用；state 防 CSRF 与回调劫持/授权码注入；精确 redirect_uri 防授权码经宽松匹配漏给第三方。总原则：密钥不进仓库，用库别造轮子。

← 资料库今日播报 →