08d · 把登录外包出去：授权码流程、PKCE 与 OIDC

⏱ 44 分钟 ｜ ⭐ 第 8 章劝你走的那条路，这一章真的走完

🎯 一句话

第 8 章给了一句很干脆的建议 ——「绝大多数人应该走 OAuth 或托管认证服务」，然后用一个表格单元格把它打发了：「一段回调逻辑 + 账号绑定关系」。这一章就是那一格的展开。 外包掉的是「怎么确认这个人是他自己」；留在你手上的是接住回调、把外面的身份换成你自己的会话。⭐ 至于第 8 步换回来的那张票本身长什么样、怎么被绕过、怎么吊销，是下一章 08e · JWT 的事。

🧩 一、外包之后，你还剩什么活

第 8 章已经说清了为什么别自己存密码（密码校验是最简单的一格，后面还有改密、忘密、验证码、限流、撞库、多设备登出、合规十几格）。这里只回答它没回答的那半句：交出去之后，你手上还剩什么。

⭐ 第 8 章那句「认证只做一次、授权每次都做」在这里有个直接推论：你能外包的只有进门那一次。 门内每一次「他能不能看这个」，外面的服务不知道，也管不了。

⚠️ 最常见的理解偏差：以为拿到第三方的 token 就完事了，直接发给前端当会话凭证用。 不行 —— 它的有效期由别人定、它的受众不是你的接口（⚠️ 这不是理论问题：08e 里有一段能跑的代码，同一家签发方签给别的服务的票，少查一句 aud 就直接进了你的接口）、它一过期你就得让用户重走一遍第三方登录。⭐ 正确做法是拿它换出身份，然后签发你自己的会话。

🎫 二、授权码流程：一步一步走完

四个角色：用户和他的浏览器、你的应用（OAuth 里叫「客户端」）、授权服务器（IdP）、资源服务器。做「用 X 账号登录」时后两个通常是同一家。

⭐ 第 2 步和第 7 步都是「你的后端」，不是笔误 —— 浏览器只负责跳转两次，敏感动作都在后端做。

🔍 为什么是「先拿 code 再换 token」

这是整个流程最值得理解的设计，而理由本板块已经讲过两遍：第 8 章第三节和第 10 章都写着 ——⚠️ URL 会被服务端访问日志、反向代理日志、浏览器历史、Referer 各抄一份。

第 5 步是一次 302 跳转，参数只能挂在 URL 上，所以它注定会泄露。设计上的应对不是「别泄露」，而是让泄露出去的那个东西不值钱：

而第 8 步的 token 是在 POST 的响应体里回来的 —— 不进 URL、不进历史、不进 Referer。

🗓️ 所以「隐式流程」（授权服务器直接把 access_token 甩在 URL 片段里）现在不推荐再用。 它当年是给「没有后端的纯前端应用」开的捷径，代价正是把 token 塞回了那条注定泄露的路上。今天的答案是下一节的授权码 + PKCE。

🚦 state：只讲它在 OAuth 里的这一个用法

第 2 步生成随机 state 存进服务端会话，第 6 步比对。没有它会怎样：攻击者在自己那边走到第 5 步，把带着他的 code 的回调 URL 骗你点开，你的浏览器带着你的会话去完成第 7~9 步 —— 结果是你的账号被绑定到了攻击者的第三方身份上，他之后随时能用那个身份登进你的账号。

⭐ 判据两条：必须随机（可预测等于没有）、必须存服务端会话里比对（塞在 URL 里自己和自己比毫无意义）。

⚠️ CSRF 是什么、浏览器为什么会替别人的页面发出带凭证的请求 —— 那是 08c · CSRF 与 XSS 的内容。 这里只需要知道：state 是这条防线在 OAuth 流程里的那一个具体落点。

⚠️ 还有 redirect_uri 必须精确匹配，注册成前缀或带通配，等于把 code 交给任何能控制那个前缀下某个路径的人。💀 更隐蔽的一种：redirect_uri 本身没问题，但你自己域名下有一个开放重定向（比如 /go?to=... 那种跳转页），攻击者走你的合法地址再二次跳到自己站上，code 就跟着跳转链出去了。⭐ 所以这条防线是两截的：授权服务器那边精确匹配，你这边不留开放重定向。

🔐 三、PKCE：公开客户端存不住秘密

第 7 步说「拿客户端凭证去换」，但有一类客户端根本没法保管凭证：纯前端应用（代码在浏览器里，打开 DevTools 就能看见）、手机 app（二进制装在用户手机上，反编译就能翻出来）。这和第 13 章那条「⚠️ 密钥绝不放前端，加密也不行，因为解密的代码也在前端」是同一条判据。

这类客户端叫公开客户端。它们的处境是：code 一旦被截获（移动端最典型的路径是恶意 app 抢注了同一个自定义 URL scheme），攻击者就能直接换出 token。PKCE 的做法是让客户端每次登录临时造一个只有自己知道的秘密，把 code 和自己绑死。

# PKCE：verifier 留在本机，出门的只有它的哈希
import base64, hashlib, secrets


def s256(t):
    return base64.urlsafe_b64encode(hashlib.sha256(t.encode()).digest()).rstrip(b"=").decode()


verifier = base64.urlsafe_b64encode(secrets.token_bytes(32)).rstrip(b"=").decode()
challenge = s256(verifier)                     # ⭐ 只有它跟着跳转 URL 出门
print("code_verifier （只留本机）:", verifier)
print("code_challenge（进 URL）  :", challenge)


def token_endpoint(saved_challenge, submitted_verifier):     # 授权服务器那一侧
    return "✅ 换出 token" if secrets.compare_digest(
        s256(submitted_verifier), saved_challenge) else "❌ 拒绝：verifier 对不上"


print("真客户端      :", token_endpoint(challenge, verifier))
print("截获 code 的人:", token_endpoint(challenge, "attacker-guess"))

实跑输出（前两行每次都不同，verifier 是随机的）：

code_verifier （只留本机）: rH1IHAnG2xiCpyNByjksoM0__La9OwFAEgyNWVW0RIM
code_challenge（进 URL）  : 8ZxKZpCuKJDd8fI_CBX2x2LlSiwfoBVbLZNCIW_xvJU
真客户端      : ✅ 换出 token
截获 code 的人: ❌ 拒绝：verifier 对不上

⭐ 为什么这样就够：出门的只有 challenge（哈希值），第 7 步要交的是 verifier（原文）——从 SHA-256 的输出反推输入，正是它设计上不成立的方向。于是「拿到 code」不再等于「能换 token」。

⚠️ 两个细节：方法要用 S256 不要用 plain（plain 是把 verifier 原样当 challenge 发出去，等于什么都没做，它只是给算不动哈希的老设备留的兼容口）；🗓️ 现在的建议是所有客户端都用 PKCE，包括有客户端凭证的后端客户端 —— 成本只是多算一次哈希，换来的是凭证泄露时还能兜一层。

🪪 四、OIDC 和 OAuth2 到底什么关系

这是被混为一谈最多的一对词，一句话可以说透：

⭐⭐ OAuth2 解决授权 ——「这个应用能不能替用户去拿那个资源」；OIDC 是搭在它上面的一层，解决认证 ——「用户是谁」。id_token 就是这个增量。

OAuth2 规范压根没规定用户身份该怎么表达，所以早年各家自己发明。OIDC 把它标准化了：约定 openid 这个 scope、约定返回一个叫 id_token 的 JWT、约定里面有 sub / iss / aud / exp / nonce 这些字段。

⚠️ 两个高频错误：① 拿 access_token 当身份证明 —— 它是一张门票，票上没写名字，只证明「持票人被授权访问某资源」。② ⚠️⚠️ 用 email 当本地账号主键 —— email 会变、在某些 IdP 那里可能根本没验证过，而两个不同的 IdP 完全可能给出同一个 email，那是一条账号劫持路径。⭐ 用 (iss, sub) 做联合唯一键，email 只当展示字段。

⭐ 表里那一格「id_token 一定是 JWT」，就是下一章的起点。 登录这条路到第 9 步就走完了，剩下的问题全在那张票身上：它长什么样、怎么被绕过、签出去之后想收回来有多难 —— 08e · JWT。

🔄 换个栈怎么对应

⭐ 这张表要看出的是：三家的库名全会过期，不过期的是那几条判据 —— state 和 code_verifier 必须存在服务端、redirect_uri 必须精确匹配、(iss, sub) 才是主键、第 9 步一定要签发你自己的会话。换语言只换了「这个库叫什么名字」。

🔗 这一章连到哪里

✅ 检查点

1. 认证外包给第三方之后，你手上还留着哪四类活？哪一类绝对外包不掉？
2. 授权码流程九步里，哪两步是在你的后端做的？浏览器在整个流程里只做了什么？
3. 为什么要「先拿 code 再换 token」？code 的哪四条性质让泄露出去的 code 不值钱？
4. 「隐式流程」当年解决的是什么问题？为什么现在不推荐？它的替代品是什么？
5. state 不做会怎样？它有哪两条判据？
6. 除了 redirect_uri 精确匹配，为什么还要管自己域名下的开放重定向？
7. PKCE 解决谁的问题？为什么「出门的只有 challenge」就够了？plain 为什么等于没做？
8. 一句话说清 OAuth2 和 OIDC 的关系。access_token 和 id_token 分别该给谁看，哪一个你不该拆开？
9. 为什么不能用 email 当本地账号主键，该用什么？
10. 为什么不能把第三方发给你的 token 直接当会话凭证发给前端？（三个理由）

🛑 可以停在这里

⚡ 走神救援

第 8 章劝你「走 OAuth 或托管服务」却只给了一个表格单元格，这一章是那一格的展开。外包掉登录页、密码存储、改密忘密、验证码；留给你四样：回调端点、账号绑定关系、你自己的会话、⭐⭐ 全部授权逻辑（能外包的只有进门那一次）。授权码九步，⭐ 第 2 步和第 7 步都在你的后端：state 和 PKCE 的 code_verifier 存进服务端会话 → 302 跳走 → 用户同意（密码只输在那一页）→ 带着 code 回来 → 先比对 state → 后端到后端 POST 换 token → ⭐⭐ 第 9 步用 id_token 里的 sub 签发你自己的会话；⚠️ 最容易漏的就是第 9 步，把第三方 token 直接当会话用（有效期由别人定、受众不是你的接口）。⭐⭐ 为什么先拿 code 再换 token：302 的参数只能挂 URL 上，而 URL 会被服务端日志、代理日志、浏览器历史、Referer 各抄一份，注定泄露 —— 所以让泄露的东西不值钱：code 一次性、短命（🗓️ 分钟量级）、绑定客户端和 redirect_uri、换 token 还要另一样东西，真 token 在 POST 响应体里回来。state 防「攻击者的 code 被绑到你账号上」：随机 + 存服务端会话比对；⚠️ redirect_uri 精确匹配，且自己域名下不能留开放重定向 —— 这条防线是两截的。PKCE 给存不住凭证的公开客户端用：verifier 不出本机，出门的只有 challenge = SHA-256(verifier)，⚠️ 用 S256 不用 plain。⭐⭐ OAuth2 是授权、OIDC 是在它上面加认证，id_token 就是这个增量；access_token 是张没写名字的门票，⚠️ 别用 email 当主键，用 (iss, sub)。

下一节 👉 08e-JWT.md