两步外部认证流程中临时登录信息的推荐存储方案

针对你这种依赖外部服务的两步登录场景，先分析下现有方案的问题，再给出几个更优的安全方案：

现有方案的不足 #

• 隐藏字段存step1_token：
  • 存在XSS攻击风险，恶意脚本可直接从DOM中窃取token；
  • 用户刷新页面后token丢失，需重新走第一步，体验差。
• 会话存储step1_token：
  • 分布式架构下需额外处理会话共享（如Redis），增加复杂度；
  • 多标签页登录时，后发起的流程会覆盖会话中的token，导致先发起的登录失败。

推荐方案 #

1. 加密HttpOnly Cookie存储（优先推荐） #

这是安全性最高的方案，完全规避前端泄露风险：

• 后端收到外部服务返回的step1_token后，用**对称加密算法（如AES）**对token+过期时间（建议和外部服务的token过期时间对齐，比如15分钟）进行加密；
• 设置一个HttpOnly、Secure、SameSite=Strict的Cookie（键名比如temp_auth），将加密后的内容存入；
• 用户提交第二组凭证时，浏览器自动携带该Cookie，后端解密验证过期时间后，取出step1_token调用外部服务；
• 验证通过后，立即清除该临时Cookie。

优势：

• HttpOnly属性阻止前端JS读取Cookie，彻底避免XSS窃取；
• Secure确保仅在HTTPS下传输，SameSite=Strict防范CSRF；
• 用户刷新页面后Cookie仍存在，登录流程不中断；
• 无需依赖会话，适合无状态分布式架构。

2. 会话绑定唯一流程ID #

如果你的系统是传统单体架构，依赖会话管理，可以优化现有会话方案：

• 前端加载登录页时，生成一个随机的流程ID（flow_id），存入页面隐藏字段；
• 用户提交第一组凭证时，携带flow_id；
• 后端将step1_token与flow_id绑定后存入会话（如session["temp_auth_#{flow_id}"] = step1_token）；
• 返回登录页时，将flow_id继续留在隐藏字段中；
• 用户提交第二组凭证时，携带flow_id，后端通过该ID从会话中取出对应的step1_token；
• 验证通过后，清理会话中该flow_id对应的存储。

优势：

• 解决多标签页登录的token覆盖问题；
• 相比直接存token，会话存储本身比前端隐藏字段更安全。

3. 签名绑定客户端信息的临时Token #

如果无法使用Cookie或会话，可对step1_token进行安全包装：

• 后端生成一个包装Token，包含以下内容：step1_token、客户端IP哈希、User-Agent哈希、过期时间；
• 用HMAC签名对整个内容进行签名，确保Token不被篡改；
• 将这个签名后的包装Token返回给前端，存入隐藏字段；
• 用户提交第二组凭证时携带该Token，后端先验证签名、过期时间，再核对客户端IP和User-Agent的哈希是否匹配；
• 验证通过后提取step1_token调用外部服务。

优势：

• 即使Token被XSS窃取，由于绑定了客户端信息，攻击者无法在其他设备/浏览器上复用；
• 无需依赖Cookie或会话，适合纯前端无状态场景。

通用注意事项 #

• 所有与外部服务的交互必须使用HTTPS，防止凭证和Token明文传输；
• 登录页必须添加CSRF令牌，防范跨站请求伪造；
• 复用Account/Login接口时，可通过请求参数（如step=1/2）或是否携带第二组凭证来区分处理逻辑；
• 严格遵守外部服务step1_token的过期时间，后端可设置更短的过期时间（比如比外部服务少5分钟），避免无效请求。

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