Web 身份鉴权技术方案

Snow.Z included in category Engineering

2025-04-25 1840 words 9 minutes

Contents

Web 身份鉴权是 Web 应用安全的第一道防线，也是所有需要验证用户身份、管理权限、保障数据完整性系统的必备能力。

这个领域最容易混淆的是两个概念：

主流 Web 鉴权方案

客户端在请求头携带账号与密码，服务端校验通过后返回资源。它胜在实现成本低，但缺点也很“硬”：

适用场景往往是内部工具、短生命周期原型或低风险 API。即便如此，也不要把密码明文存库；应使用带盐的强哈希（如 bcrypt/Argon2）存储摘要，并配合限速与告警。

一个最小例子（请求头长这样）：

Authorization: Basic base64(username:password)

落地时建议补齐两件事：对登录/鉴权接口做限速（防爆破），以及给每个账号设置“失败次数阈值 + 冷却时间”。

这是经典的“服务端有状态”方案：登录后服务端创建会话记录（Session），客户端通过 Cookie 携带 Session ID，后续请求据此识别用户。

优点是控制力强：可以随时失效会话、踢下线、做精细的风控与审计；缺点也很直接：

安全上，Cookie 相关风险通常集中在两类：

一个更“像生产”的 Cookie 设置示例：

Set-Cookie: sid=...; Path=/; HttpOnly; Secure; SameSite=Lax

一个最小 CSRF Token 思路（双提交或 Session 存储都行）：服务端下发 token，客户端在非幂等请求里同时带 Cookie 与 token，服务端做比对：

X-CSRF-Token: <random>

如果你采用前后端分离并且跨站请求不可避免，SameSite=None; Secure 是常见选择，但这会放大 CSRF 风险，CSRF Token 反而更不能省。

Token 方案把身份与授权信息编码到 Token 里，请求时由客户端携带，服务端通过签名/有效期/权限声明等校验来放行或拒绝。它天然更适合分布式与微服务，因为服务端可以少存或不存会话状态。

一个常见的传输方式（Bearer Token）：

Authorization: Bearer <access_token>

JWT（JSON Web Token）是最常见的 Token 载体之一，结构是 Header.Payload.Signature：

工程上记住两句话基本够用：

Payload 可被解码阅读，别放敏感信息
JWT 擅长“自包含校验”，不擅长“强撤销”；想要登出/踢下线/改密后立刻全端失效，通常需要配合服务端状态（黑名单、版本号、会话绑定或短期 Access Token + Refresh Token）

一个更贴近实践的 claims 示例（只示意字段，不要把权限列表做得过细）：

{
  "sub": "user_123",
  "roles": ["admin"],
  "ver": 7,
  "iat": 1730000000,
  "exp": 1730003600,
  "iss": "snowsblog",
  "aud": "web"
}

其中 ver（tokenVersion）是常用的“强撤销”手段：用户改密/登出/风险事件时把服务端记录的版本号 +1，校验时要求 ver 匹配即可让旧 token 全部失效。

OAuth 2.0 是用于授权的行业标准协议，本质也是基于 Token 来实现的

核心思路：第三方应用通过授权流程获取访问令牌（Access Token），用它代表用户访问受保护资源

主要使用场景是第三方登录（如 Google 登录、微信登录）、API 开放平台等

Token 一旦泄露，攻击者拿到的就是“通行证”。落地时通常要回答这几个问题：

一个常见且容易落地的组合是：

Access Token：短有效期（例如 5–15 分钟），用于频繁调用 API
Refresh Token：长有效期（例如 7–30 天），只用于换取新的 Access Token，要求“单次使用 + 旋转”（refresh 后旧 refresh 立刻作废）