当前位置：首页 > news >正文

JS—Token与JWT

news 来源：原创 2025/5/18 21:34:56

个人博客：haichenyi.com。感谢关注

一. 目录

一–目录
二–token登录流程
三–JWT
四–session与JWT对比

二. token登录流程

用户登录： 客户端发送用户名，密码到服务器
服务端验证： 服务端校验用户名，密码的有效性。验证通过之后生成签名Token(如JWT)，包含用户信息，过期时间等
返回Token： 把Token返回给客户端，通常通过响应体
客户端存储Token： 客户端拿到token之后，把token存起来localStorage或者sessionStorage
后续请求携带Token： 后续请求在请求头中添加token，cookie中或者其他位置，传递给服务端
服务端验证Token： 服务端根据自定义的规则校验token的有消息，返回对应的数据
过期处理： 客户端刷新token，或者其他逻辑处理过期

token的存储位置

对比项	localStorage	sessionStorage
生命周期	长期有效(除非手动删除)	当前标签页有效
安全性	低(持久化存储，可能被长期利用)	稍高(会话级失效，减少XSS的长期风险)
跨标签页共享	同一域名下都有效	当前标签有效
适用场景	需要长期登录的场景(社交媒体应用等等)	需要高安全性场景(银行应用等等)

建议：

若需用户关闭浏览器后重新登录，选择sessionStorage。
若需持久化登录状态，选择localStorage，但需配合短过期时间和HTTPS。
关键安全措施： 防御XSS（输入过滤、避免eval）、设置Token过期时间、使用Refresh Token轮换。

保存在哪里没有绝对的标准，都是需要根据实际场景来。
后续请求怎么给服务端，也是没有绝对的标准，一般token都是放在网络请求的Cookie里面或者Header里面
注意： 无论选择哪种方式，XSS漏洞均可导致Token泄露，因此防范XSS是核心。对于极高安全场景，可考虑将Token存入内存，并在页面刷新时重新认证。

三. JWT

JWT全称：**JSON Web Token，**是一种轻量级、自包含的开放标准。有特殊规则的token。用于在双方之间安全传输信息。以 JSON 格式存储数据，并通过数字签名（如 HMAC 或 RSA）或加密保证信息的完整性和可信性，常用于身份认证（如登录 Token）和跨系统数据交换。

3.1 JWT 的组成

JWT 由三部分组成，用 . 分隔：
Header.Payload.Signature

Header(头部)
作用： 描述 Token 的类型和签名算法。
示例：

{
  "alg": "HS256",  // 签名算法（如 HS256、RSA）
  "typ": "JWT"     // Token 类型
}

Payload（载荷）
作用： 携带实际传输的数据（称为 Claims）。
数据类型：
- 预定义声明（建议但不强制）：如 exp（过期时间）、sub（主题）、iss（签发者）。
- 自定义声明：业务相关数据（如用户 ID、角色）。
  示例：

{
  "sub": "user123",
  "name": "Alice",
  "exp": 1620000000  // 过期时间戳
}

Signature（签名）
作用： 防止数据篡改，验证发送方的可信性。
生成方式： 对 Header 和 Payload 的 Base64 编码结果进行签名，使用 Header 中指定的算法。
示例（HMAC-SHA256）：

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secretKey  // 密钥（仅服务端持有）
)

3.2 JWT 的工作原理

生成 Token： 服务端验证用户身份后，生成 JWT（包含用户信息），返回给客户端。
传递 Token： 客户端将 JWT 存储在 Cookie、LocalStorage 或内存中，后续请求通过header带给服务端
验证 Token： 服务端收到请求后：1.校验签名（防止伪造）。2.检查有效期（exp 声明）。3.提取 Payload 中的用户信息，完成身份认证。

3.3 JWT 的优缺点

优点：
- 无状态：服务端无需存储会话信息（如 Session ID），适合分布式系统。
- 跨域支持：可轻松跨域名、跨服务传递。
- 数据透明：Payload 可包含业务数据，减少数据库查询。
缺点：
- 无法废止：一旦签发，在过期前始终有效（需额外机制实现“注销”）。
- 安全性依赖密钥：密钥泄露会导致所有 Token 失效。
- Payload 默认不加密：敏感数据需自行加密（建议配合 HTTPS 使用）。

3.4 JWT 使用场景

用户认证：替代传统 Session-Cookie 模式，实现无状态登录。
授权：携带用户角色信息，控制 API 或资源访问权限。
跨服务数据交换：微服务间安全传递用户上下文（如 OpenID Connect）。

3.5 安全建议

避免在 Payload 中存储敏感数据（如密码）。
使用 HTTPS：防止 Token 被窃听。
设置短过期时间（如 15 分钟），配合 Refresh Token 续签。
签名算法选择：优先使用 HMAC 或 RSA，而非弱算法（如 none）。

四. session与JWT对比

对比项	Session-Cookie（有状态）	JWT（无状态）
服务端存储	必须存储 Session 数据	无存储，验证签名即可
扩展性	需共享 Session 存储，扩展复杂	天然支持分布式系统
跨域支持	依赖 Cookie 同源策略	通过 Header 轻松跨域
性能开销	每次请求查询 Session 存储	仅验证签名，无存储查询
安全性	需防御 CSRF	需防御 XSS 和 Token 泄露
适用场景	同源传统 Web 应用	跨域 API、微服务、SPA/移动端