OAuth 2.0 / OpenID Connect

OAuth 2.0 · OpenID Connect · OIDC · 授权与身份认证协议

密码与身份安全词条4 章节

📅 创建于 2026/8/9🔄 最后更新 2026/8/26 · 1 天前👁️ 0 次浏览✏️ 5 次编辑来源

摘要

OAuth 2.0（RFC 6749, 2012）是互联网最广泛部署的授权框架，允许第三方应用在资源所有者（用户）的许可下、无需获取用户密码即可访问受保护资源。它与 OpenID Connect（OIDC, 2014）配合构成现代身份基础设施的核心——OAuth 2.0 处理授权（「你能让这个应用访问你的 Google Drive 吗？」），OIDC 在其上增加身份认证层（「你是谁？」），通过 ID Token（JWT 格式）将用户身份安全地从身份提供方（IdP）传递给依赖方（RP）。 OAuth 2.0 定义了四种授权模式（Grant Types）：授权码模式（Authorization Code，服务器端应用，最安全）——客户端将用户重定向到授权服务器，用户同意后获得一次性授权码，客户端再凭授权码和自己的客户端密钥向令牌端点换取 Access Token+Refresh Token；隐式模式（Implicit，已废弃）——Access Token 直接通过 URL 片段返回，不经过令牌端点认证，安全性弱；密码模式（Resource Owner Password Credentials，已不推荐）——用户直接将密码交给客户端，破坏了 OAuth 的核心价值（不暴露密码）；客户端凭证模式（Client Credentials，机器对机器）——客户端用自己的凭证直接获取 Access Token。 OAuth 2.1（正在整合中）将移除隐式模式和密码模式，强制 PKCE（Proof Key for Code Exchange, RFC 7636）用于所有授权码流程（即使客户端密钥存在），并收紧 Refresh Token 安全要求。PKCE 最初是 2015 年为移动/公共客户端设计的安全加固，2021 年起 OAuth 安全最佳实践（BCP）要求所有客户端使用 PKCE——原因在于授权码拦截攻击：恶意应用注册相同的 redirect_uri scheme 可截获授权码。PKCE 通过 `code_challenge`（SHA-256(code_verifier)）和 `code_verifier`（客户端生成的高熵随机字符串）确保即使授权码被截获，没有 code_verifier 也无法换取令牌。

OAuth 2.0 四种授权模式及安全边界

OAuth 2.0 的核心设计是「权限委派」——用户（资源所有者）通过授权服务器将受限的访问权限委派给客户端，客户端永远不接触用户的长期密码凭证。

授权码模式（Authorization Code Grant with PKCE）——当前唯一推荐用于用户参与的授权流程：

客户端将用户浏览器重定向到授权服务器的 authorization_endpoint：?response_type=code&client_id=xxx&redirect_uri=yyy&scope=openid%20profile&code_challenge=zzz&code_challenge_method=S256
用户在授权服务器上认证并同意授权范围（如「该应用将访问您的公开个人资料」）。
授权服务器将用户浏览器重定向回客户端的 redirect_uri，并在查询参数中附带一次性授权码（code）——授权码有效期通常仅 30 秒至数分钟。
客户端（服务器端）凭授权码 + 客户端密钥（client_secret） + code_verifier 向令牌端点换取 Access Token（有效期通常数分钟至数小时）+ Refresh Token（有效期数天至数月）。
客户端使用 Access Token（Bearer Token）调用资源服务器 API。

PKCE 的必要性：即使第 4 步的 TLS 加密保护了「授权码→令牌」交换，步骤 3 的 redirect_uri 回调是一个 URL 参数，可能被设备上的其他应用截获（移动端通过注册相同 custom scheme 拦截，Web 端通过 Referer header 泄露）。PKCE 在第 1 步发送 SHA-256(code_verifier)，第 4 步必须附上原始 code_verifier，授权服务器验证两者匹配——截获授权码但不持有 code_verifier 的攻击者无法换取令牌。OAuth 安全最佳实践（OAuth 2.0 Security Best Current Practice, RFC 9700, 2025）强制所有客户端（包括有客户端密钥的机密客户端）使用 PKCE。

OAuth 2.0 / OpenID Connect · 安全词条 | 点滴安全

OpenID Connect：在 OAuth 2.0 之上构建身份层

OpenID Connect（OIDC）是 OAuth 2.0 之上的身份认证协议，由 OpenID Foundation 于 2014 年发布。它不像 SAML 2.0 那样完全独立，而是最小化地对 OAuth 2.0 进行扩展——这在工程上是明智的设计选择，使所有已有的 OAuth 2.0 库和基础设施可无缝升级。

ID Token 是 OIDC 的核心创新——一个 JWT 格式的 JSON 对象，由身份提供方（IdP）签发，包含用户身份声明（Claims）：

代码

{
  "iss": "https://accounts.google.com",      // 签发者
  "sub": "1234567890",                       // 用户唯一标识
  "aud": "your-client-id",                   // 目标客户端（必须与 client_id 一致）
  "exp": 1640995200,                         // 过期时间
  "iat": 1640991600,                         // 签发时间
  "auth_time": 1640991600,                   // 用户认证时间
  "nonce": "n-0S6_WzA2Mj",                  // 防重放（客户端生成随机值）
  "amr": ["pwd", "mfa"],                    // 使用的认证方法
  "email": "user@example.com",              // 可选声明（需 scope=email）
  "email_verified": true
}

客户端验证 ID Token 有 6 个必检项：1) issuer (iss) 是否匹配期望 IdP、2) audience (aud) 是否包含自己的 client_id、3) 签名是否有效（使用 IdP 的 JWKS 公钥验证）、4) 是否过期（exp < now）、5) nonce 是否与请求时的一致（防重放）、6) 如有 auth_time 且要求新鲜认证（max_age 参数），检查认证时间不超过阈值。

JWT 签名与 JWKS：OIDC 使用 JWT（JSON Web Token, RFC 7519）作为令牌格式，支持 JWS（JSON Web Signature）签名。IdP 通过其 jwks_uri（/.well-known/openid-configuration 中包含的 URL）公开 JSON Web Key Set——一组公钥（RSA/EC/OKP 等），依赖方定期拉取以验证 ID Token 签名。密钥轮转时，IdP 同时在 JWKS 中保留多把密钥——旧密钥用于验证已签发的 Token，新密钥用于新签发。

OIDC 的典型登录流程（Authorization Code Flow）：用户点击「用 Google 登录」→ 客户端重定向到 Google OIDC endpoint（response_type=code&scope=openid+profile+email）→ 用户在 Google 认证并同意 → 回调返回授权码 → 客户端在令牌端点换取 Access Token + ID Token + Refresh Token → 客户端验证 ID Token 签名和声明，提取 sub 作为用户标识，可选调用 UserInfo Endpoint 获取更多用户属性。

常见配置错误与攻击面

OAuth 2.0 / OIDC 的安全依赖于正确实现，以下是生产环境中最常见也最危险的配置错误：

redirect_uri 开放重定向：授权服务器在回调用户浏览器前必须严格验证 redirect_uri 与注册列表完全匹配（不允许子路径绕过、正则宽松匹配、仅前缀匹配）。攻击利用：恶意客户端注册 https://evil.com/callback 但不使用；而是诱骗用户使用合法客户端的 client_id 但 redirect_uri 改为 https://evil.com/callback，授权服务器若验证不严则回调到攻击者控制的域名并泄露授权码。Facebook 2018 年的 OAuth 漏洞（50M 账户受影响）根因就是 redirect_uri 验证不严。

CSRF 攻击与 state 参数：OAuth 回调 URL 中缺少 state 参数或 state 未被验证，使攻击者可在自己的客户端授权一个受害者的授权码后，将回调重定向到受害者浏览器——受害者浏览器在不知情下完成登录并绑定攻击者的账号到受害者的会话。RFC 6749 明确要求客户端生成不可预测的 state 并与回调中返回的 state 比对——未比对是实现的常见遗漏。

Mix-Up Attack：当客户端从多个 IdP 接收令牌时，恶意 IdP 可签发目标为其他客户端的 ID Token（audience 冲突）。2016 年 Daniel Fett 等人在 IEEE S&P 论文中形式化了这一攻击类并影响了 OIDC 规范修订。

客户端密钥（client_secret）泄露：隐性模式（已废弃）和原生应用（Native App）中，client_secret 静态写在客户端二进制/前端 JavaScript 中——逆向工程即可提取。OAuth 设备授权流程（Device Authorization Grant，RFC 8628）的客户端密钥同样面临此风险。替代方案：mTLS 绑定（RFC 8705）使用客户端证书取代共享秘密；DPoP（Demonstration of Proof-of-Possession, RFC 9449）使用客户端生成的公钥绑定 Access Token。

JWT 算法混淆攻击：如果 JWT 库接受 alg: "none"（不签名）或允许攻击者利用服务器的 RS256 公钥伪造 HS256 签名的 JWT，攻击者可绕过签名验证。所有 JWT 验证必须：1) 拒绝 alg=none、2) 仅接受白名单算法、3) RS256 验证仅用服务器已知的 IdP 公钥（公钥模式验证）、4) 不使用客户端可控的密钥材料验证 HMAC JWT。

OAuth 2.0 / OpenID Connect

OAuth 2.0 四种授权模式及安全边界

OpenID Connect：在 OAuth 2.0 之上构建身份层

常见配置错误与攻击面

声明与维护记录

参考资料