OAuth 2.0 的授权码流程是怎样的？

详细解析#

四个角色#

授权码流程#

1. 用户 → 客户端：点击"第三方登录"
2. 客户端 → 浏览器：302 重定向到授权服务器
   https://auth.example.com/authorize?response_type=code&client_id=app123
     &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&scope=profile&state=k8x2Qf
3. 用户 → 授权服务器：登录，在授权页上确认要授予的权限
4. 授权服务器 → 浏览器：302 重定向回 redirect_uri
   https://app.example.com/callback?code=Xa91bQe7&state=k8x2Qf
5. 浏览器 → 客户端后端：带着 code 和 state 访问回调地址，后端校验 state
6. 客户端后端 → 授权服务器：POST /token（服务器之间直接通信）
   grant_type=authorization_code&code=Xa91bQe7
   &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&client_id=app123&client_secret=***
7. 授权服务器 → 客户端后端：{ "access_token": "...", "token_type": "Bearer", "expires_in": 3600 }
   （可能还有 refresh_token）
8. 客户端后端 → 资源服务器：带上 Authorization: Bearer access_token，获取用户资源

关键参数：

• redirect_uri：回调地址，授权服务器会校验它和注册时登记的地址是否一致，防止 code 被发到攻击者的地址
• scope：申请的权限范围，用户在授权页上能看到
• state：客户端生成的随机值，存进会话，回调时比对，防止 CSRF
• client_secret：客户端的密钥，只能保存在后端。它也可以用 HTTP Basic 认证的方式放在请求头里（RFC 6749 更推荐这种），具体看授权服务器支持哪种

PKCE：保护公共客户端#

单页应用和移动应用的代码在用户手里，没法安全地保存 client_secret，属于"公共客户端"。授权码一旦被截获（比如移动端被恶意 App 注册了同样的回调地址），攻击者就能拿它换令牌。PKCE（Proof Key for Code Exchange）的做法是：

1. 客户端生成一个随机字符串 code_verifier，自己保存
2. 授权请求带上 code_challenge（code_verifier 做 SHA-256 后再做 Base64URL 编码）和 code_challenge_method=S256
3. 换令牌时带上原始的 code_verifier，授权服务器算一遍，和之前收到的 code_challenge 比对

截获 code 的人没有 code_verifier，换不到令牌。PKCE 最初是为公共客户端设计的，后来发现它对机密客户端同样有用（能防御授权码注入），所以 OAuth 2.1 草案要求客户端默认都使用 PKCE，只有正确实现了 OIDC nonce 机制的机密客户端可以例外，但仍然推荐使用。

const base64url = (bytes) =>
  btoa(String.fromCharCode(...bytes)).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

// code_verifier：32 字节随机数，编码后是 43 个字符
const codeVerifier = base64url(crypto.getRandomValues(new Uint8Array(32)))
const digest = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(codeVerifier))
const codeChallenge = base64url(new Uint8Array(digest))

其他授权方式#

OAuth 和 OIDC#

OAuth 本身只负责授权，回答的是"允许这个应用访问我的哪些资源"。access_token 是给资源服务器用的，客户端不应该靠解析它来判断用户是谁。

OpenID Connect（OIDC）在 OAuth 2.0 之上增加了身份认证：scope 里带上 openid，令牌接口除了返回 access_token，还会返回一个 ID Token。它是一个 JWT（见 JWT），包含用户标识 sub、签发者 iss、接收方 aud、过期时间 exp 等，客户端验证签名、校验 iss、aud、exp 后就知道"谁登录了"。

"第三方登录"通常基于 OIDC；也有的平台只提供 OAuth，网站拿到 access_token 后再调用平台的用户信息接口来识别用户。拿到用户标识后，网站一般会建立自己的登录态（Session 或自己签发的 JWT）。

面试官可能追问#

易错点#

• OAuth 2.0 是授权协议，不是认证协议；"用 XX 登录"靠的是 OIDC 的 ID Token，或者额外调用用户信息接口
• client_secret 只能放在后端，不能写进前端代码或 App 安装包；公共客户端要用 PKCE
• redirect_uri 要精确匹配，宽松的前缀或通配符匹配可能让 code 被重定向到攻击者控制的地址