如何在客户端与服务端双向保障JWT认证安全

一、refresh token存Cookie、不持久化access token方案的安全性评估 #

这个方案的基础防护逻辑是靠谱的，比把access、refresh token存在localStorage/sessionStorage的方案抗XSS能力强出一大截，但不存在绝对“足够安全”的方案，必须补全以下配置才能覆盖主流攻击场景，达到生产级防护要求：

• 存储refresh token的Cookie必须开启HttpOnly属性，禁止前端JavaScript读取Cookie内容，从根源堵死XSS脚本窃取refresh token的路径
• 生产环境下该Cookie必须开启Secure属性，仅允许HTTPS协议传输Cookie，避免明文HTTP链路下token被窃听
• Cookie要配置SameSite属性，内部系统可直接设为Strict完全阻断跨站携带，前后端分离跨域场景可设为Lax，从根源降低CSRF攻击风险；跨域配置必须严格限定允许的源地址，绝对不能开启通配符*允许所有源跨域访问
• access token有效期必须设置得极短，建议控制在5~15分钟区间，仅存在前端运行时内存（比如框架全局状态、闭包变量）中，页面刷新后就重新用refresh token换取新的access token，哪怕access token被XSS窃取，可用的攻击窗口也极短
• 换取access token的接口要补充CSRF防护，比如采用双重提交Cookie方案，要求请求携带自定义的CSRF请求头，避免攻击者诱导用户在已登录状态下跨站发起换token请求
• 存refresh token的Cookie不要设置永久有效期，建议7~14天过期，到期强制用户重新输入账号密码登录

二、服务端JWT安全加固落地方案 #

首先回答你提到的“每个用户生成独立动态密钥签发JWT”的思路：这个思路完全可行，但要注意实现逻辑不要走偏。不要每次签发token都生成新密钥，不然用户手里还没过期的合法token会直接失效，影响正常使用。正确的做法是给每个用户绑定一个固定的、可主动重置的签名密钥，存在服务端数据库或者Redis缓存里，当用户修改密码、主动退出登录、后台检测到账号异常登录时，直接重置这个密钥，就能瞬间让该用户名下所有已签发的access、refresh token全部失效，刚好补上原生JWT没法主动吊销的短板。

除此之外，还有以下可直接落地的加固措施：

• 优先选择社区长期维护的成熟JWT库实现认证逻辑，DRF生态下优先选djangorestframework-simplejwt即可，不要自己手写JWT签发、校验逻辑，避免出现算法篡改、签名校验绕过这类低级漏洞
• 严格限制允许的JWT签名算法，内部系统可选用对称加密算法HS256，多服务分布式场景可选用非对称加密算法RS256，绝对禁止开放none算法支持，校验签名时不要直接读取JWT header里声明的算法做校验，要在服务端写死允许的算法列表
• 做全字段校验：除了校验签名有效性，必须强制校验exp（过期时间）、iat（签发时间）、iss（签发方标识）、aud（接收方标识）字段，字段值不符合服务端预期的token直接拒绝
• 启用refresh token轮换机制：每次用refresh token换取新access token时，同步签发新的refresh token返回给客户端，同时把旧的refresh token加入黑名单，哪怕旧refresh token被攻击者窃取，也无法重复使用
• 维护token黑名单：把主动登出、密码修改、账号封禁场景下还没过期的token（尤其是refresh token）加入黑名单，存在Redis这类高性能缓存中，黑名单条目过期时间和对应token的过期时间保持一致即可，不会长期占用存储资源；每次校验token有效性时先查黑名单，命中直接拒绝
• 加异常行为风控：如果同一个refresh token短时间内来自差异极大的IP段、不匹配的设备指纹，直接判定为token泄露，立刻重置该用户的签名密钥、吊销所有有效token，强制用户重新登录
• JWT payload不要存敏感信息：JWT的payload只是Base64编码，没有加密效果，任何人拿到token都可以直接解码出payload内容，绝对不能在里面存密码、身份证号、手机号这类敏感数据
• 坚持权限最小化原则：JWT校验通过只代表用户身份合法，不代表用户有所有资源的操作权限，必须配合DRF的权限类做细粒度的资源权限校验，避免出现水平越权、垂直越权漏洞

内容的提问来源于stack exchange，提问作者Amin Malek Mohammadi