refresh token API设为匿名是否安全？React+ASP.NET JWT鉴权方案咨询

一、匿名Refresh Token接口的安全性评估 #

直接将Refresh Token接口设置为无任何校验的匿名接口是不安全的，主要风险点如下：

• 无校验前提下，攻击者只要窃取到用户的Refresh Token，就可以直接调用该接口持续获取合法Access Token，完全接管用户账号
• 没有防护的匿名接口容易遭遇暴力破解攻击，若Refresh Token熵值不足、长度较短，攻击者可通过批量猜解遍历窃取大量用户账号
• 若接口校验逻辑是全表匹配Refresh Token，还可能被攻击者利用响应时间差遍历所有有效Refresh Token，造成批量数据泄露

二、最优实现方案 #

Refresh Token接口确实不需要校验未过期的Access Token，但不能完全放开无校验，可按照以下规则实现：

1. 接口校验逻辑优化 #

要求接口请求同时携带已过期的Access Token和Refresh Token，校验流程如下：

• 首先验证Access Token的签名合法性，只要签名合法，哪怕exp过期也可以正常解析出Payload内的用户ID等身份标识（注意仅跳过过期校验，签名篡改的请求直接拦截）
• 用解析得到的用户ID去数据库查询对应存储的Refresh Token，避免全表扫描的同时也杜绝Refresh Token遍历漏洞
• 将前端传入的Refresh Token和数据库存储的值做哈希比对，比对通过才允许签发新的双Token

2. Refresh Token本身的安全约束 #

• 生成规则：必须使用高熵随机字符串，长度不低于32位，杜绝包含用户ID、时间戳等可预测特征
• 存储规则：数据库不存储Refresh Token明文，和密码一样用bcrypt等不可逆哈希算法加盐存储，避免数据库泄露后Refresh Token被批量盗用
• 生命周期规则：每个Refresh Token必须设置7~30天的过期时间，过期自动失效；每次刷新双Token后直接作废旧的Refresh Token，生成新的Refresh Token返回给前端，禁止单Token多次使用
• 风险熔断规则：如果同一用户的Refresh Token连续校验失败超过5次，直接作废该用户所有有效Refresh Token，强制用户重新登录

3. 接口层防护 #

• 增加限流策略：同一IP/同一用户ID1分钟内最多允许调用3次Refresh Token接口，避免暴力猜解攻击
• 高危操作二次校验：涉及支付、修改账号信息、删除数据等敏感操作，不能直接走Refresh Token续期逻辑，必须要求用户主动输入密码进行二次认证

4. 前端配套安全措施 #

• Web端双Token优先存储在设置了HttpOnly、Secure、SameSite=Strict属性的Cookie中，禁止存储在LocalStorage/SessionStorage中，降低XSS攻击窃取Token的风险
• 并发请求同时返回401时，加锁保证仅发起一次Refresh Token请求，避免旧Refresh Token被多次提交导致校验失败

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