SPA中基于JWT的多步骤认证授权的Token处理方案咨询

针对你提出的多步骤认证流程（密码校验→OTP校验→企业选择）及Token相关疑问，给出如下实操性方案：

一、步骤1/2完成后是否需要临时Token？ #

需要，临时Token是维护多步骤认证流程合法性的核心，主要作用是防止用户绕过前置步骤直接访问后续页面，同时记录当前的认证阶段状态。

二、密码验证通过后的Token设计 #

完全应该生成带password_verified类型Claim的短时效临时Token：

• Token内容仅需包含用户ID、认证阶段标识（如stage: password_passed），无需携带任何权限信息；
• 时效设置为5-10分钟足够，避免长期有效带来的安全风险；
• OTP页面接口仅接受携带该有效Token的请求，无Token或Token无效则直接拒绝访问，从根源上杜绝绕过密码登录的情况。

三、OTP验证通过后的Token设计 #

同样需要生成新的短时效临时Token，替换之前的密码校验Token：

• Token中加入otp_verified类型的Claim，标识用户已完成双因素认证；
• 时效仍设为5-10分钟，仅用于访问企业选择页面；
• 后端校验该Token的有效性，只有通过OTP校验的用户才能进入企业选择环节。

四、企业选定后的最终Token发放 #

是的，选定企业后应发放两类Token：

• 短时效access token：仅包含当前企业的专属Claim（如企业ID、该企业下的用户权限），时效建议15-30分钟，遵循轻量化原则；
• 长时效refresh token：用于在access token过期时，无需重新认证即可获取新的access token，时效可设为7-30天（根据业务安全需求调整）。

五、企业切换时的Token处理 #

切换企业时，无需重新走完整认证流程：

• 用当前有效的refresh token（或OTP校验后的临时Token）向后端请求对应新企业的access token和新的refresh token；
• 后端生成新的refresh token时，应自动失效用户之前的refresh token（可通过维护用户最新refresh token记录、或黑名单机制实现），避免同一用户持有多个有效refresh token，降低安全风险。

六、关于多refresh token的疑问 #

同一会话下不建议存在多个有效refresh token，新的refresh token生成后必须作废旧的：

• 若用户在不同设备登录，每个设备可持有独立的refresh token，但同一设备的同一会话中，始终仅保留最新的一个；
• 这种方式既能简化后端的Token生命周期管理，也能减少被盗用后带来的安全隐患。

七、关于单一Token适配多企业的问题 #

你的判断完全正确：单一Token塞入所有企业的Claim会导致Token体积过大，传输成本高且泄露风险高。分企业生成专属access token才是更合理的方案——每个Token仅包含当前企业的必要权限，既符合轻量化要求，也能降低权限泄露的范围。

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