简体中文
什么是 bearer token？
了解 bearer token 是什么，它们在 OAuth 2.0 和 JWT 中如何工作，它们与 access token 的区别，以及最佳实践。
Guamian
Product & Design
Product & Design
了解 bearer token 是什么，它们在 OAuth 2.0 和 JWT 中如何工作，它们与 access token 的区别，以及最佳实践。
几乎每个现代应用登录或 API 请求背后，都有一个默默无闻的主力军：bearer token。你也许不会在意它，但每次你连接服务、登录或从云端获取数据时，它都在背后工作。
本指南将介绍 bearer token 的作用、为什么它们重要，以及如何安全地处理它们。
bearer token 是一段数据，通常是一串字符，用于证明持有者被允许访问某个资源。关键在于，只要持有 这个 token 的人就可以使用它，无需额外证明。
想想登机牌。一旦你拿到它，就可以通过安检并登机。如果登机牌有效，没人会再要求你出示身份证。同理，bearer token 让你的应用“登上 API”，无需每次都重新验证你的身份。
例如，当你在手机上登录 Spotify 后，每次播放歌曲时，都不需要重复输入密码。应用会保存一个 bearer token，向 Spotify 服务器表明：“此请求来自一个已授权用户。”
bearer token 的流程大致分为以下几个步骤：
用户登录
假设你用用户名和密码登录银行应用。
身份提供者签发 token
一旦通过验证，认证服务器会返回一个 bearer token。它可能类似于：
客户端使用 token
每次你点击“查询余额”或“转账”，应用都会在 HTTP 请求中携带 token：
API 验证 token
服务器会检查该 token 是否有效、是否过期，以及是否包含正确的权限（比如 read:balance 或 write:transfer）。
通过授权，授予访问权限
如果所有检查都通过，服务器会返回请求的数据。
这种模式被广泛应用于像 GitHub API 这样的服务中，开发者用 bearer token 认证，而不是反复输入账号密码。
bearer token 之所以流行，是因为它们解决了 web 安全中的一些常见问题。与服务端会话（session）不同，它们无需为每个已登录用户存储数据。相反，token 本身就包含了让服务器能验证请求的足够信息。
比如，在微服务架构中，很多服务彼此间需要通信，维护集中会话存储会变得繁琐且低效。而 bearer token 让每个服务都能独立地验证请求，使系统轻量且可扩展。
具体例子：Slack 的 API 就大量用到 bearer token。你开发 Slack 机器人时，会拿到一个 token，这让你的机器人可以调用 Slack 的接口，而无需为每个用户单独维护会话。
许多 bearer token 是通过 JWT（JSON Web Token） 实现的。这类 token 是带有编码信息的字符串，包含用户及其权限的信息。
让我们解码一个示例 JWT：
它的意思是：
sub：用户的唯一 ID。name：用户名。iat：签发时间戳。exp：过期时间（token 失效时间）。scope：权限，这里表示应用既可读取也可发送消息。在实际应用中，如果 Jane 的 token 只有 read:messages 权限，应用只能获取她的消息，无法代表她发送新消息。
bearer token 和 access token 很容易混淆，因为这两个词经常一起出现。它们其实相关，但不是完全一样。
access token 是用于证明用户被授权访问某资源的凭证。它包含的信息有：
你可以把它想象成校长签字的许可条，告诉老师（API）你有权参加郊游（访问资源）。
举个例子，当你登录云存储服务时，系统会签发一个 scope 为 read:files 的 access token。这个 token 告诉存储 API：“这个用户可以读取文件，但不能删除文件。”
bearer token 是 access token 的一种。bearer 描述的是 token 如何被使用：谁拿着它就能“持有”并访问资源，无需额外身份验证。
换句话说：
其他 token 类型还有 持有密钥 token（holder-of-key tokens），客户除了 token 还要证明拥有密钥。bearer token 跳过了这一步，所以更简单，但被盗后风险也更大。
<token> 头部传递。这也意味着在 OAuth 教程看到的“access token”，实际上几乎总是 bearer token，除非特别说明。
为了让情况更清楚，我们看看 bearer token 与其他常见 token 的比较：
bearer token 和 access token 并不是对立概念——它们有交集：
验证 bearer token 是保护你的 API 不被未授权访问的关键。如果你的 token 是 JWT 的话，验证过程可以本地快速完成。API 无需每次都请求签发方。
接入 API 网关或中间件时，可以作为操作手册参考：
签名
用头部声明的算法（例如 RS256）验证签名。获取签发者的 JWKS 端点，选出 kid 匹配的密钥并缓存。
签发者（iss）
token 的 iss 字段必须和你的可信签发者 URL 精确匹配（包括协议）。
受众（aud）
确认 token 是为你的 API 签发。例如比较 https://api.example.com 或某个受众标识字符串。
过期（exp）和未生效（nbf）
拒绝过期的 token。尊重 nbf 字段（token 生效前不可用）。允许小范围时间误差，通常 30-60 秒。
签发时间（iat）
用于调试或严格场景下拒绝过旧 token。
Token 类型
确认是 access token。有些提供方会包含 typ: "at+jwt" 等类型。不应接受 ID token 作为 API 访问凭证。
scope / 权限
读取 scope 或特定声明（如 permissions, roles），并在每个接口强制最小权限。
主体（sub）
稳定的用户或客户端 ID。用于资源绑定和审计。
重放与撤销（可选但建议）
对敏感接口，可以检查短期 denylist 列表（jti），或验证会话是否激活。适用于退出登录、怀疑被盗用场景。
正因为 bearer token 是“谁拿到谁能用”，它们要像钥匙一样被妥善保管。一旦被盗，别人就能在你换锁前随意使用。
常见风险包括：
现实中，有开发者不小心把 bearer token 提交到公开的 GitHub 仓库，攻击者能很快扫描并立即利用这些 token 获取未授权权限。
要安全地使用 bearer token，必须遵守最佳实践。以下通过实例逐一说明：
始终使用 HTTPS
想象你在咖啡馆公共 Wi-Fi 上通过 HTTP 发送 token。任何监听网络的人都能复制 token 并冒充你登录。
使用短生命周期的 access token
大多数平台签发的 token 有效期只有一小时。例如 Google 的 OAuth token 通常 1 小时后需刷新。
小心存储 refresh token
refresh token 可以在不让用户重新登录的情况下获取新 access token。但它必须安全存储（如服务器端加密数据库），不要放在客户端本地存储。
token 权限最小化
如果你的应用只需要读取日历，就别请求 write:calendar 权限。如果 token 被盗，危害也会更小。
必要时撤销 token
许多 SaaS 应用允许用户查看和撤销活跃的 session。例如 GitHub 可以随时撤销个人 access token。
监控使用情况
记录 token 的使用，可以发现可疑活动。如果同一个 token 短时间内在伦敦和纽约被用，这是明显警告信号。
比较 bearer token 与其他常用方式很有帮助：
Cookies & Sessions
传统网站依靠 cookie 识别、服务端存储 session。这种方式很适合网页应用，但在 API 或移动端下效率较低。例如 Facebook 桌面端主用 cookie，而移动 API 用 token。
API Key
API key 是静态字符串，用于认证应用而不是用户。例如天气应用通过 API key 获取数据，但服务器并不知道是哪个用户发起请求。bearer token 可以承载用户信息，更灵活。
双向 TLS（mTLS）
有些高安全系统会要求客户端和服务端都持有证书。虽然更安全，但部署难度较大。对大多数 SaaS 平台而言，bearer token 的易用性和安全性最为平衡。