长春建站优化现在还用dw做网站设计么
个人博客：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/移动端 |