前端使用Google OpenID Connect OAuth2的state参数是否安全？

背景 #

我正在学习基于Google的OpenID Connect OAuth2标准认证机制，官方文档指出反伪造state令牌用于验证请求发起者为合法用户而非恶意攻击者。当前我们的实现是：将生成的state令牌包含在「使用Google登录」按钮的跳转URL中，示例URL如下：

https://accounts.google.com/o/oauth2/v2/auth?
response_type=code&
client_id=CLIENT_ID&
scope=openid%20email%20profile&
redirect_uri=appdomain.com&
state=0Xgjymvk8tlPne45LPCnzfP3ofU5dm&
nonce=0217322-3497425-1190558&
prompt=select_account

用户授权后，Google会重定向至REDIRECT_URI，并在URL中携带state参数和code参数，示例如下：

https://appdomain.com/?state=0Xgjymvk8tlPne45LPCnzfP3ofU5dm&code=4%2F0AbUR2VP....

疑问 #

1. 这些state参数均出现在前端，这种方式是否安全？
2. 直接在前端JS代码中验证state参数一致性是否可行？我认为并不妥当。
3. 是否需要将「使用Google登录」按钮指向后端服务，由后端生成state令牌后重定向至Google授权页面；待前端收到Google返回的state参数后，再发送至后端进行一致性验证，之后再完成用户认证？想请教该方案是否合理？

前端处理State的安全性问题 #

直接在前端生成并验证state完全不安全，核心问题有两点：

• 前端JS代码可被攻击者篡改，伪造或替换state值，轻松绕过验证逻辑
• 前端存储的state（比如localStorage、sessionStorage）极易成为XSS攻击的目标，攻击者窃取state后，可构造伪造的回调请求劫持用户授权后的code参数

你的判断是对的，前端JS验证state一致性的做法不可取。

后端生成+验证State的方案合理性 #

你提出的后端主导state流程的方案是符合OpenID Connect安全规范的标准实践，完全合理，具体流程和优势如下：

1. 后端生成state：用户点击登录按钮时，先请求后端接口，后端生成高随机性的唯一state，将其与用户当前会话（比如绑定到服务器端session，或加密存储在HttpOnly、Secure的cookie中）关联存储，并设置短过期时间（比如10分钟），随后直接重定向到带该state的Google授权页面
2. 回调后的后端验证：Google授权完成后重定向到前端，前端需立即将URL中的state和code一起发送到后端接口，后端取出之前存储的state进行比对：
   • 若一致，说明请求是合法发起的，接着用code向Google请求ID令牌和访问令牌，完成用户认证流程
   • 若不一致或state已过期，直接拒绝请求，阻断伪造攻击
3. 额外安全强化：后端存储state时设置短过期时间，可避免留存的state被攻击者滥用

这种方案将state的生成和验证放在可信的后端环境中，从根源上避免了前端篡改、窃取state的风险，完全满足反伪造攻击的安全要求。

内容的提问来源于stack exchange，提问作者jwtrees