主流认证方案
JWT (JSON Web Token)
实现步骤
- 用户登录后,服务端生成包含用户信息的JWT
- 客户端存储JWT(通常存于 localStorage 或 cookie, 流行存储cookie)
- 每次请求携带 Authorization: Bearer token
服务端验证JWT签名有效性
Postman 请求
优点
- 无状态:服务端无需存储会话
- 跨域友好:天然支持分布式系统
扩展性强:Token可携带额外元数据
缺点
- Token无法主动失效
- 存在XSS攻击风险(如果使用localStorage)
载荷大小受限(建议不超过4KB)
OAuth2.0 + OpenID Connect
实现步骤
- 集成第三方认证服务(Google/GitHub等)
- 使用授权码模式(最安全)
- 前端通过重定向完成认证流程
后端验证Access Token有效性
优点
- 标准化协议,安全性高
- 支持第三方登录
支持细粒度权限控制
缺点
- 实现复杂度高
- 需要维护Token刷新逻辑
依赖第三方服务稳定性
Session-Based 认证
实现步骤
- 服务端使用Redis等集中存储会话
- 客户端通过Cookie自动携带Session ID
- 需配置CORS和SameSite策略
服务端验证会话有效性
优点
- 可主动管理会话状态
- 天然防御CSRF(配合SameSite属性)
兼容传统系统改造
缺点
- 需要维护会话存储
- 跨域配置复杂
- 移动端适配性较差
方案对比分析
特性 | 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 };
};
认证流程:
- 用户登录获取Access Token(15分钟过期)和Refresh Token(7天过期)
- Access Token存于内存,Refresh Token存于HttpOnly Cookie
- 前端在Token过期时调用/refresh端点获取新Access Token
服务端维护Refresh Token黑名单实现主动登出
安全增强措施:
- 设置双重Cookie验证
- 记录设备指纹
- 实施速率限制
- 使用短期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),实现严格会话控制
如果对你有帮助, 请点个赞鼓励下, 欢迎留言 🤝
本文由mdnice多平台发布
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。