一、问题背景OAuth 2.0 和 OpenID Connect 的授权流程依赖浏览器重定向这天然暴露了多种攻击面攻击类型描述CSRF攻击者诱导用户的浏览器携带恶意授权码完成绑定Token 重放窃取的id_token被重复提交给客户端授权码劫持恶意应用在同一设备上拦截授权码移动端尤为严重state、nonce、PKCE分别针对这三类威胁而设计职责正交、互不替代。二、逐一剖析1.state— 防 CSRF保护对象授权请求 → 回调的完整性原理客户端 授权服务器 │ │ │── /authorize?statexyz ─────►│ │ │ │◄── /callback?code...statexyz ──│ │ │ │ 验证: state 本地存储的值 │客户端生成随机state存入sessionStorage/ cookie回调时校验返回的state与本地一致若不一致 → 拒绝说明该回调不是由当前用户主动发起的关键特征绑定的是请求-响应会话不涉及 token 内容OAuth 2.0 规范RFC 6749推荐实践中必须使用一次性消费回调校验后即删除2.nonce— 防 Token 重放保护对象id_token的新鲜度原理客户端 授权服务器 │ │ │── /authorize?nonceabc ─────►│ │ │ │◄── id_token { ..., nonce: abc } ──│ │ │ │ 验证: id_token.nonce 本地存储的值 │客户端生成随机nonce存入sessionStorageIdP 将nonce写入id_token的 JWT payload 并签名客户端解码id_token后校验nonce值若不一致 → 拒绝说明 token 可能是从别处窃取的旧 token关键特征是OIDC的概念OAuth 2.0 本身无此参数嵌入在签名的 JWT内部无法被篡改隐式流中必填token 直接暴露在 URL fragment授权码流中可选有 code 交换环节已提供一定保护3.PKCE— 防授权码劫持保护对象授权码 → Token 交换的安全性原理客户端 授权服务器 │ │ │ 生成 code_verifier (随机串) │ │ 计算 code_challenge │ │ BASE64URL(SHA256(verifier)) │ │ │ │── /authorize? │ │ code_challenge... │ │ code_challenge_methodS256 ─►│ │ │ │◄── /callback?code... ───────│ │ │ │── /token │ │ code... │ │ code_verifier原始值 ──────►│ │ │ │ 服务端验证: │ │ SHA256(verifier) 存储的 │ │ challenge ✓ │ │ │ │◄── { access_token, id_token } │请求时只发送code_challenge哈希后的值换 token 时发送code_verifier原始值攻击者即使拦截了授权码没有code_verifier也无法换取 token关键特征最初为公共客户端原生 App / SPA设计RFC 7636OAuth 2.1 草案已要求所有客户端类型必须使用替代了 SPA 中不安全的隐式流是密码学证明而非简单的值比较三、核心对比维度statenoncePKCE防御目标CSRF跨站请求伪造Token 重放授权码劫持规范来源OAuth 2.0 (RFC 6749)OIDC Core 1.0OAuth 2.0 (RFC 7636)参数位置URL query 参数JWT payload 内授权请求 Token 请求校验方客户端自行校验客户端校验 JWT授权服务器校验密码学强度随机值对比随机值对比JWT 签名保护SHA-256 单向哈希证明绑定对象请求 ↔ 回调会话请求 ↔ id_token授权请求 ↔ Token 请求是否必须强烈推荐实际必须隐式流必须授权码流可选OAuth 2.1 要求必须适用流程所有流程返回 id_token 的流程授权码流四、协作关系三者不是互斥的替代方案而是纵深防御的不同层┌─────────────────────────────────────────┐ │ 授权请求发起 │ │ state → 绑定浏览器会话防 CSRF │ │ nonce → 写入请求后续校验 id_token │ │ PKCE → 发送 code_challenge │ └──────────────────┬──────────────────────┘ │ ▼ ┌─────────────────────────────────────────┐ │ 回调阶段 │ │ state → 立即校验不匹配则中止 ✓ │ └──────────────────┬──────────────────────┘ │ ▼ ┌─────────────────────────────────────────┐ │ Token 交换 │ │ PKCE → 提交 code_verifier │ │ 服务端验证 ✓ │ └──────────────────┬──────────────────────┘ │ ▼ ┌─────────────────────────────────────────┐ │ Token 验证 │ │ nonce → 校验 id_token 中的 nonce ✓ │ └─────────────────────────────────────────┘五、SPA 最佳实践2024推荐采用Authorization Code Flow PKCE三者全部启用asyncfunctionstartAuth(){// 1. state — 防 CSRFconststatecrypto.randomUUID();sessionStorage.setItem(oauth_state,state);// 2. nonce — 防 id_token 重放constnoncecrypto.randomUUID();sessionStorage.setItem(oidc_nonce,nonce);// 3. PKCE — 防授权码劫持constcodeVerifiergenerateCodeVerifier();// 43-128 字符随机串sessionStorage.setItem(pkce_verifier,codeVerifier);constcodeChallengeawaitsha256Base64url(codeVerifier);// 组装授权 URLconstauthUrlnewURL(https://idp.example.com/authorize);authUrl.searchParams.set(response_type,code);authUrl.searchParams.set(client_id,CLIENT_ID);authUrl.searchParams.set(redirect_uri,REDIRECT_URI);authUrl.searchParams.set(scope,openid profile);authUrl.searchParams.set(state,state);authUrl.searchParams.set(nonce,nonce);authUrl.searchParams.set(code_challenge,codeChallenge);authUrl.searchParams.set(code_challenge_method,S256);window.location.hrefauthUrl.toString();}asyncfunctionhandleCallback(){constparamsnewURLSearchParams(window.location.search);// ① 校验 stateif(params.get(state)!sessionStorage.getItem(oauth_state)){thrownewError(State mismatch — possible CSRF attack);}sessionStorage.removeItem(oauth_state);// ② 用 code code_verifier 换 tokenPKCE 由服务端校验consttokenResponseawaitfetch(https://idp.example.com/token,{method:POST,body:newURLSearchParams({grant_type:authorization_code,code:params.get(code),redirect_uri:REDIRECT_URI,client_id:CLIENT_ID,code_verifier:sessionStorage.getItem(pkce_verifier),}),});sessionStorage.removeItem(pkce_verifier);const{id_token}awaittokenResponse.json();// ③ 校验 nonceconstpayloadJSON.parse(atob(id_token.split(.)[1]));if(payload.nonce!sessionStorage.getItem(oidc_nonce)){thrownewError(Nonce mismatch — possible token replay);}sessionStorage.removeItem(oidc_nonce);}六、常见误区误区纠正“有了 PKCE 就不需要 state”错。PKCE 保护的是 code→token 交换不防 CSRF。攻击者可用自己的合法 code 发起 CSRF“state 和 nonce 功能一样”错。state 校验在回调时、由客户端比对 URL 参数nonce 校验在 token 验证时、比对 JWT 内部字段“授权码流不需要 nonce”半对。code 交换已提供一层保护但若前端直接消费 id_tokennonce 仍是重要的二次校验“PKCE 只用于移动端”错。OAuth 2.1 要求所有客户端含机密客户端都使用 PKCE七、一句话总结state保证这个回调是我发起的nonce保证这个 token 是为我签发的PKCE保证只有我能用这个授权码换 token。三者协同构成 OAuth/OIDC 客户端的完整安全防线。
