Web认证宇宙漫游指南

主流认证方案

JWT (JSON Web Token)

实现步骤

1. 用户登录后，服务端生成包含用户信息的JWT
2. 客户端存储JWT（通常存于 localStorage 或 cookie, 流行存储cookie)
3. 每次请求携带 Authorization: Bearer token
4. 服务端验证JWT签名有效性

Postman 请求

优点

1. 无状态：服务端无需存储会话
2. 跨域友好：天然支持分布式系统
3. 扩展性强：Token可携带额外元数据

缺点

1. Token无法主动失效
2. 存在XSS攻击风险（如果使用localStorage)
3. 载荷大小受限（建议不超过4KB）

OAuth2.0 + OpenID Connect

实现步骤

1. 集成第三方认证服务（Google/GitHub等)
2. 使用授权码模式（最安全)
3. 前端通过重定向完成认证流程
4. 后端验证Access Token有效性

优点

1. 标准化协议，安全性高
2. 支持第三方登录
3. 支持细粒度权限控制

缺点

1. 实现复杂度高
2. 需要维护Token刷新逻辑
3. 依赖第三方服务稳定性

Session-Based 认证

实现步骤

1. 服务端使用Redis等集中存储会话
2. 客户端通过Cookie自动携带Session ID
3. 需配置CORS和SameSite策略
4. 服务端验证会话有效性

优点

1. 可主动管理会话状态
2. 天然防御CSRF（配合SameSite属性）
3. 兼容传统系统改造

缺点

1. 需要维护会话存储
2. 跨域配置复杂
3. 移动端适配性较差

方案对比分析

特性	JWT	OAuth2.0	Session-Based
状态管理	无状态	无状态/有状态	有状态
扩展性	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
安全性	⭐⭐⭐（需配置）	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
移动端友好	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐
实现复杂度	低	高	中
典型场景	内部API、微服务	第三方集成、SSO	传统Web应用改造

混合方案实践（JWT + Refresh Token）

架构设计

// Token生成示例（Node.js）
const generateTokens = (user) => {
  const accessToken = jwt.sign(
    { userId: user.id }, 
    process.env.ACCESS_SECRET,
    { expiresIn: '15m' }
  );
  
  const refreshToken = jwt.sign(
    { userId: user.id }, 
    process.env.REFRESH_SECRET,
    { expiresIn: '7d' }
  );
  
  return { accessToken, refreshToken };
};

认证流程:

1. 用户登录获取Access Token（15分钟过期）和Refresh Token（7天过期）
2. Access Token存于内存，Refresh Token存于HttpOnly Cookie
3. 前端在Token过期时调用/refresh端点获取新Access Token
4. 服务端维护Refresh Token黑名单实现主动登出

安全增强措施：

1. 设置双重Cookie验证
2. 记录设备指纹
3. 实施速率限制
4. 使用短期Token+自动续期

最佳实践建议

传输安全：

• 强制使用HTTPS
• 设置Secure和SameSite属性
• CORS白名单配置

存储安全：

// 安全设置示例
res.cookie('refreshToken', token, {
  httpOnly: true,
  secure: process.env.NODE_ENV === 'production',
  sameSite: 'strict',
  maxAge: 7 * 24 * 60 * 60 * 1000
});

防御策略：

• CSRF：验证Origin/Referer头
• XSS：内容安全策略（CSP）
• 暴力破解：登录尝试限流

总结建议

• 初创项目：采用JWT+Refresh Token方案，快速实现且扩展成本低
• 企业级应用：使用OAuth2.0+OpenID Connect，便于集成现有身份系统
• 高安全需求：Session-Based+硬件安全模块（HSM），实现严格会话控制

如果对你有帮助, 请点个赞鼓励下, 欢迎留言 🤝