使用Django+DRF的JWT认证：跨新标签页是否需重新登录？

嘿，这个问题问到点子上了！我刚好有过Django+DRF+JWT的实战经验，给你掰扯清楚：

首先，新标签页要不要重新登录，核心取决于你把JWT存在哪里——毕竟浏览器的不同存储机制，跨标签页的共享性完全不一样：

• 存在localStorage：这是同域名下跨标签页共享的存储。用户在sample.com登录后，JWT存在localStorage里，打开新标签页时，前端JS可以直接读取到这个令牌，只要令牌没过期，就能在Authorization请求头里带上完成认证，完全不需要重新登录。这也是大部分前端项目维持JWT登录状态的常规做法。
• 存在sessionStorage：这个是每个标签页独立的会话存储，新标签页读不到之前标签页存在sessionStorage里的JWT，这种情况就必须重新登录。一般除非有特殊的会话隔离需求，否则不会用这个来存登录令牌。
• 只存在前端JS内存变量里：每个标签页是独立的JS执行上下文，新标签页拿不到之前标签页内存里的JWT，自然也得重新登录，这种方案基本不会用于生产环境的登录状态维持。

然后说JWT本身的能力：JWT是无状态令牌，服务器不会保存用户的会话信息，全靠令牌本身的签名和过期时间来验证身份。只要你能在新标签页里拿到未过期且签名有效的JWT，并且按照约定在Authorization请求头里传递（比如Bearer <token>格式），DRF的JWT认证组件就会识别用户身份，维持登录状态。

最后给你提两个实践里的关键点：

• 记得处理令牌过期：给JWT设置合理的过期时间（比如15分钟到1小时），同时搭配刷新令牌机制。这样即使访问令牌过期，前端可以自动用刷新令牌去换新的访问令牌，用户完全感知不到，不用重新登录。
• 注意安全风险：用localStorage存JWT要防范XSS攻击，因为恶意的XSS脚本可以读取localStorage内容。所以前端要做好XSS防护，比如严格转义用户输入、配置内容安全策略（CSP）等。如果对安全要求极高，也可以折中：把刷新令牌存在HttpOnly的Cookie里（避免JS读取），访问令牌存在内存里，但这就和你说的“不使用Cookie”的需求有冲突，得根据你的实际场景权衡。

总结一下：只要你把JWT存在localStorage（同域名跨标签页共享），且令牌未过期，新标签页打开sample.com就不需要重新登录，JWT能完美维持登录状态；如果存在其他不共享的存储介质里，就需要重新登录。

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