什么是 Bearer Token？
Bearer Token（持票人令牌）是 HTTP 协议中的一种认证机制。其核心概念非常直观：“持票人”（Bearer）即指任何持有该令牌的人。在数字世界中，这意味任何持有该令牌的人都可以使用该令牌来访问资源，就像持有现金一样。因此，保护令牌的机密性至关重要，一旦泄露，持有者即可冒充合法用户。
⚡ 无状态特性
服务器无需在会话存储中保存用户状态，降低了服务器内存开销，提升了系统的可扩展性。
⚡ 跨域支持
相比 Cookie/Sessions，Bearer Token 在跨域请求（CORS）中处理更为灵活，适合前后端分离架构。
⚡ 标准化
通常基于 JWT (JSON Web Token) 标准，结构紧凑，便于在网络中传输。
Bearer Token 工作原理详解
理解 bearer token 原理 的关键在于掌握其生命周期。从用户登录到资源访问，整个过程可以分为以下几个关键步骤：
用户在客户端输入用户名和密码。客户端将这些凭证发送给认证服务器。服务器验证凭证合法后，会生成一个 Bearer Token（通常包含用户ID、过期时间、权限范围等信息，并使用私钥签名），并将其返回给客户端。
{
"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"token_type": "Bearer",
"expires_in": 3600
}客户端接收到 Token 后，通常将其存储在 LocalStorage 或 SessionStorage 中。在后续发起 API 请求时，客户端必须在 HTTP 请求头（Header）中包含 Authorization 字段。
GET /api/user/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...后端网关或微服务接收到请求后，提取 Header 中的 Token。服务器利用公钥或共享密钥验证签名的有效性。如果签名有效且未过期，服务器解析 Payload 获取用户权限，并返回受保护的资源；否则返回 401 Unauthorized。
认证机制对比：Bearer Token vs Session
为了更深入理解 bearer token 原理，我们将它与传统的 Session 认证进行对比。请使用以下选项卡查看详细信息：
Session 认证机制
Session 认证依赖于服务器端的会话存储。当用户登录时，服务器创建一个 Session 对象，并将 Session ID 通过 Cookie 返回给客户端。
- 状态保持：服务器需要维护用户状态。
- 存储位置：Session 存储在服务器内存或数据库中。
- 扩展性挑战：在分布式系统中，需要解决 Session 共享问题（如使用 Redis）。
- CSRF 风险：容易受到跨站请求伪造攻击，需要额外防护。
Bearer Token 机制
Bearer Token 是一种无状态认证机制。Token 本身包含了所有必要的用户信息（经过签名）。
- 无状态：服务器不需要存储会话状态，减轻服务器压力。
- 存储位置：Token 存储在客户端（LocalStorage/Cookie）。
- 高扩展性：天然适合微服务架构和分布式系统。
- 安全性：通常配合 HTTPS 使用，防止中间人攻击。
核心差异对比
| 特性 | Session | Bearer Token |
|---|---|---|
| 服务器状态 | 有状态 (Stateful) | 无状态 (Stateless) |
| 存储位置 | 服务器端 | 客户端 |
| 扩展性 | 较差 (需共享存储) | 极好 |
| 跨域支持 | 复杂 (需 CORS 配置) | 简单 (Header 传递) |
| 适用场景 | 传统单体应用 | 微服务、移动端、SPA |
Bearer Token 安全性考量
虽然 bearer token 原理 提供了便利，但其安全性完全依赖于实现方式。由于 Token 一旦泄露即可被直接使用（类似于持有现金），因此必须采取严格的安全措施。
⚠️ 常见安全风险
- 中间人攻击 (MITM)：如果在非 HTTPS 环境下传输 Token，攻击者可以截获并窃取 Token。
- 跨站脚本攻击 (XSS)：如果 Token 存储在
LocalStorage中，恶意 JavaScript 脚本可以读取并窃取 Token。 - Token 重放攻击：攻击者截获有效的 Token 后，可以重复发送请求。
?️ 最佳实践建议
强制 HTTPS
始终通过加密通道传输 Token，防止数据在传输过程中被窃听。
设置过期时间
Access Token 应设置较短的有效期（如 15 分钟），并结合 Refresh Token 机制进行刷新。
HttpOnly Cookie
对于 Web 应用，建议将 Token 存储在 HttpOnly Cookie 中，以防止 XSS 攻击窃取。
签名验证
使用强加密算法（如 RS256）对 Token 进行签名，确保 Token 内容未被篡改。
常见问题 (FAQ)
Session 认证是服务器端存储状态，需要 Cookie 配合；而 Bearer Token 是无状态的，客户端存储 Token 并在每次请求中携带，更适合分布式系统和移动端。
主要措施包括：强制使用 HTTPS 加密传输、设置较短的 Token 过期时间、使用 HttpOnly Cookie 存储 Token 以防止 XSS 攻击、以及实施 Refresh Token 机制。
不建议。JWT 等 Token 通常是 Base64 编码的，容易被解码。除非对 Payload 进行了加密（如 JWE），否则不应在 Token 中包含密码、身份证号等敏感信息。