什么是 bearer token？

几乎每个现代应用登录或 API 请求背后，都有一个默默无闻的主力军：bearer token。你也许不会在意它，但每次你连接服务、登录或从云端获取数据时，它都在背后工作。

本指南将介绍 bearer token 的作用、为什么它们重要，以及如何安全地处理它们。

什么是 bearer token？#

bearer token 是一段数据，通常是一串字符，用于证明持有者被允许访问某个资源。关键在于，只要持有 这个 token 的人就可以使用它，无需额外证明。

想想登机牌。一旦你拿到它，就可以通过安检并登机。如果登机牌有效，没人会再要求你出示身份证。同理，bearer token 让你的应用“登上 API”，无需每次都重新验证你的身份。

例如，当你在手机上登录 Spotify 后，每次播放歌曲时，都不需要重复输入密码。应用会保存一个 bearer token，向 Spotify 服务器表明：“此请求来自一个已授权用户。”

bearer token 在实际中的工作方式#

bearer token 的流程大致分为以下几个步骤：

1. 用户登录

   假设你用用户名和密码登录银行应用。

2. 身份提供者签发 token

   一旦通过验证，认证服务器会返回一个 bearer token。它可能类似于：

3. 客户端使用 token

   每次你点击“查询余额”或“转账”，应用都会在 HTTP 请求中携带 token：

4. API 验证 token

   服务器会检查该 token 是否有效、是否过期，以及是否包含正确的权限（比如 read:balance 或 write:transfer）。

5. 通过授权，授予访问权限

   如果所有检查都通过，服务器会返回请求的数据。

这种模式被广泛应用于像 GitHub API 这样的服务中，开发者用 bearer token 认证，而不是反复输入账号密码。

bearer token 为什么流行#

bearer token 之所以流行，是因为它们解决了 web 安全中的一些常见问题。与服务端会话（session）不同，它们无需为每个已登录用户存储数据。相反，token 本身就包含了让服务器能验证请求的足够信息。

比如，在微服务架构中，很多服务彼此间需要通信，维护集中会话存储会变得繁琐且低效。而 bearer token 让每个服务都能独立地验证请求，使系统轻量且可扩展。

具体例子：Slack 的 API 就大量用到 bearer token。你开发 Slack 机器人时，会拿到一个 token，这让你的机器人可以调用 Slack 的接口，而无需为每个用户单独维护会话。

bearer token 包含什么内容？#

许多 bearer token 是通过 JWT（JSON Web Token） 实现的。这类 token 是带有编码信息的字符串，包含用户及其权限的信息。

让我们解码一个示例 JWT：

它的意思是：

• sub：用户的唯一 ID。
• name：用户名。
• iat：签发时间戳。
• exp：过期时间（token 失效时间）。
• scope：权限，这里表示应用既可读取也可发送消息。

在实际应用中，如果 Jane 的 token 只有 read:messages 权限，应用只能获取她的消息，无法代表她发送新消息。

bearer token 与 access token：区别何在？#

bearer token 和 access token 很容易混淆，因为这两个词经常一起出现。它们其实相关，但不是完全一样。

Access token：“许可条”#

access token 是用于证明用户被授权访问某资源的凭证。它包含的信息有：

• 用户是谁（他们的 ID）
• 可以做什么（范围/权限）
• token 何时过期

你可以把它想象成校长签字的许可条，告诉老师（API）你有权参加郊游（访问资源）。

举个例子，当你登录云存储服务时，系统会签发一个 scope 为 read:files 的 access token。这个 token 告诉存储 API：“这个用户可以读取文件，但不能删除文件。”

Bearer token：“交付格式”#

bearer token 是 access token 的一种。bearer 描述的是 token 如何被使用：谁拿着它就能“持有”并访问资源，无需额外身份验证。

换句话说：

• 所有 bearer token 都是 access token。
• 但不是所有 access token 都必须是 bearer token。

其他 token 类型还有 持有密钥 token（holder-of-key tokens），客户除了 token 还要证明拥有密钥。bearer token 跳过了这一步，所以更简单，但被盗后风险也更大。

实际举例#

• access token（通用）： 可能是签名的数据，有时还要求客户端要证明它有私钥。
• bearer token（特指）： 现在大多数 OAuth 2.0 实现都是用 bearer 格式下发 access token。例如 Google OAuth 返回的 access token 你会放在 Authorization: Bearer <token> 头部传递。

这也意味着在 OAuth 教程看到的“access token”，实际上几乎总是 bearer token，除非特别说明。

其他 token 类型对比#

为了让情况更清楚，我们看看 bearer token 与其他常见 token 的比较：

• Refresh token：用于在原 access token 过期后获取新 token。refresh token 通常不是 bearer token，因为它们只在服务端安全交换，不直接暴露给 API。
• ID token：用于身份验证，不是授权。它包含用户身份信息（比如邮箱、姓名、用户 ID）。依据系统不同，ID token 也可以是 bearer token，但它的用途和 access token 不同。
• API key：一种更简单的凭证格式，用来标识调用的应用。许多情况下，API key 的用法类似 bearer token，谁拿到 key 谁就能调用 API。

bearer token 和 access token 并不是对立概念——它们有交集：

• 大多数 access token 都是 bearer token。
• bearer token 表达的是token 的使用方式（出示就能访问）。
• 实际中，“access token”和“bearer token”常常被交替使用，但技术上侧重点不同。

如何验证 JWT access token（Bearer token）#

验证 bearer token 是保护你的 API 不被未授权访问的关键。如果你的 token 是 JWT 的话，验证过程可以本地快速完成。API 无需每次都请求签发方。

核心思路#

1. 解析 token。
2. 使用签发方公钥验证签名。
3. 检查标准声明，比如签发方（issuer）、受众（audience）、过期和未生效时间。
4. 执行程序自己的规则，比如 scope、角色和 token 类型。
5. 对于高风险操作，可查阅撤销列表或会话状态。

JWT 验证清单#

接入 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 是“谁拿到谁能用”，它们要像钥匙一样被妥善保管。一旦被盗，别人就能在你换锁前随意使用。

常见风险包括：

• token 被窃取 —— 黑客如果拿到浏览器 localStorage 里的 token，就能冒充你。例如 2018 年，一些浏览器插件曾被发现窃取 localStorage 里的 token 然后转卖。
• 重放攻击 —— 攻击者如果截获到 token，可以反复使用直到过期。没有用 HTTPS 的情况下，这非常容易被利用。
• token 生命周期太长 —— 如果 token 有效期为数周或数月，攻击者利用的窗口也更大。

现实中，有开发者不小心把 bearer token 提交到公开的 GitHub 仓库，攻击者能很快扫描并立即利用这些 token 获取未授权权限。

bearer token 的最佳实践#

要安全地使用 bearer token，必须遵守最佳实践。以下通过实例逐一说明：

1. 始终使用 HTTPS

   想象你在咖啡馆公共 Wi-Fi 上通过 HTTP 发送 token。任何监听网络的人都能复制 token 并冒充你登录。

2. 使用短生命周期的 access token

   大多数平台签发的 token 有效期只有一小时。例如 Google 的 OAuth token 通常 1 小时后需刷新。

3. 小心存储 refresh token

   refresh token 可以在不让用户重新登录的情况下获取新 access token。但它必须安全存储（如服务器端加密数据库），不要放在客户端本地存储。

4. token 权限最小化

   如果你的应用只需要读取日历，就别请求 write:calendar 权限。如果 token 被盗，危害也会更小。

5. 必要时撤销 token

   许多 SaaS 应用允许用户查看和撤销活跃的 session。例如 GitHub 可以随时撤销个人 access token。

6. 监控使用情况

   记录 token 的使用，可以发现可疑活动。如果同一个 token 短时间内在伦敦和纽约被用，这是明显警告信号。

bearer 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 的易用性和安全性最为平衡。

核心结论#

• bearer token 简单但很强大：谁持有 token 谁就能访问资源。
• 它们在 OAuth 2.0 和 OIDC 流程中被大量使用，尤其适合 API 和移动应用。
• 安全性取决于管理方式：有效期短、scope 限定、用 HTTPS、支持撤销都很关键。
• 虽非所有场景下都最佳选择，但在大多数 SaaS 和 API 场景下，它们在安全和便利性之间取得了很好的平衡。