MERN栈OAuth实现合理性及access、refresh token存储问题咨询

1. 现有OAuth流程的合规性判断 #

你当前采用的是OAuth 2.0最安全的授权码模式，全流程放在后端实现是完全合规的，避免了授权码、客户端密钥等敏感信息泄露到前端的风险。但你目前的代码还缺2个必要的安全校验逻辑，补上之后就完全符合规范：

• 必须添加state参数防CSRF攻击：重定向到第三方OAuth地址前，生成随机不可预测的state值，存在当前用户的会话（比如httpOnly临时cookie/服务端session）中，第三方回调时必须校验返回的state和你存储的完全一致，否则直接拒绝请求。
• 要确保你请求Token时传入的redirect_uri和你在第三方平台注册的回调地址完全匹配，域名、路径、协议都不能有差异，否则会被第三方接口拒绝。

2. Token存储方案与用户关联问题解决 #

存储方案合理性说明 #

你当前把两类Token存入httpOnly Cookie的做法是合理的，搭配Secure、SameSite=Strict属性可以有效防范XSS、CSRF攻击。不过refresh token有效期更长，更推荐同时加密存入数据库，方便后续做Token吊销、过期清理、多端同步等操作。

用户关联问题解决方案 #

你说的无法传递用户ID的问题，有3种成熟的解决路径，根据你的业务场景选就行：

• 若用户点击OAuth认证按钮时已经登录了你的系统：你本身的登录态已经以httpOnly Cookie的形式存在浏览器中，调用getAuthCode接口时会自动携带，后端直接从当前登录态中解析用户ID即可，完全不需要前端手动传参。
• 若用户点击OAuth按钮时还未登录你的系统，是走OAuth登录的场景：可以在发起重定向生成state时，把用户ID或者临时会话标识加密后放到state参数中，回调时解密state就能拿到关联标识，再和你系统的用户账号绑定即可。
• 若你不想改动state逻辑：也可以在调用getAuthCode接口时，后端给用户种一个带有效期的临时httpOnly Cookie存用户ID，回调的时候读这个Cookie就能关联上用户，存完Token之后删掉这个临时Cookie就行。

补充存储最佳实践 #

• access token只存在httpOnly Cookie中，不要存到前端本地存储，有效期建议设置为1~2小时。
• 数据库存储refresh token时必须加密，不要明文存储，同时记录所属用户ID、过期时间，用户解绑第三方权限时直接删除对应的refresh token即可。

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