跳到主要内容

存储到 Storage

2025年01月07日
柏拉文
越努力，越幸运

一、认识​

在 JWT（JSON Web Token） 认证模式下，主要有两种常见的 Token 存储方式：一种是服务端将 Token 存储在 Cookie 中，另一种是服务端将 Token 返回给前端，由前端将 Token 存储在 LocalStorage 或 SessionStorage 中。这两种方式各有利弊，适用于不同的场景。

当我们选择 存储到 Storage 方案后，当用户登录成功后，服务端会生成一个 JWT Token，将其返回给前端。前端应用将该 Token 存储在 LocalStorage 或 SessionStorage 中，通常会存储在浏览器的 LocalStorage 或 SessionStorage 中。每次前端请求时，需要手动将 Token 添加到请求头部（通常是 Authorization: Bearer <token>）。

存储到 Storage 前端可以更灵活地控制 Token 的存储和传输方式（例如存储在 localStorage 或 sessionStorage）。由于 Token 存储在客户端，前端可以直接在 API 请求中手动携带 Token，而不受 Cookie 的跨域限制。前端可以灵活控制请求头，便于与不同后端系统或微服务进行集成。但是有以下缺点和挑战:

  1. XSS（Cross-Site Scripting）攻击: Token 存储在浏览器的 LocalStorage 或 SessionStorage 中，JavaScript 可以直接访问它。这使得如果站点遭受 XSS 攻击，攻击者可能通过注入恶意脚本来窃取 Token。那么，我们如何防止恶意脚本通过 XSS 攻击窃取存储在 localStorage 或 sessionStorage 中的 Token 呢? 我们可以使用 Content Security Policy (CSP)：通过设置 CSP 头来限制可以执行的脚本来源，减少 XSS 攻击的风险。避免直接在 DOM 操作用户输入：尽量避免使用 innerHTML、eval 等容易导致 XSS 漏洞的 JavaScript 方法。定期清理 Token：每次用户登出时清除 localStorage 或 sessionStorage 中的 Token，防止 Token 被滥用。

  2. Token 存储在客户端，并由客户端通过 HTTP 请求传输给服务器。如果没有采取适当的安全措施，Token 可能在传输过程中被窃取。如何确保 Token 在传输过程中不被中间人攻击（MITM）? 我们可以使用 HTTPS：确保所有的 Token 都通过 HTTPS 传输，防止 Token 在网络中被窃取, 避免暴露敏感信息：不将 Token 存储在 URL 中，因为 URL 可能会被日志记录或暴露在浏览器历史记录中。

  3. 由于前端控制 Token 存储和传输，客户端需要手动处理 Token 过期逻辑，并使用 Refresh Token 来获取新的 Access Token。如何在客户端安全地存储 Refresh Token，并确保过期的 Token 不会影响用户体验? 使用 Refresh Token：如果使用 localStorage 存储 Token，可以将 Refresh Token 存储在 HttpOnly Cookie 中，只有通过后端请求时才能访问。这样可以减少 XSS 风险，同时避免重复登录。Token 过期检查：在前端检查 Token 的过期时间，若即将过期，则自动向后端申请新的 Token。