在浏览器 Network、Apifox 或后端日志中经常可以看到Authorization: Bearer xxx。其中 Authorization、Bearer、Token 和 JWT 经常同时出现因此很容易被当成同一类概念。实际上它们分别处于 HTTP 请求、认证方案和凭据格式等不同层次。一、四个概念的层级关系Token 是最宽泛的概念可以理解为客户端持有的一段访问凭据。服务端收到 Token 后可以据此识别调用者身份并继续判断其访问权限。Token 本身没有规定具体格式它可以是一段随机字符串也可以采用 JWT。JWT 是 Token 的一种常见实现形式。它规定了一套结构化的数据格式使 Token 可以携带用户标识、有效期等 Claim并通过签名保证内容完整性。Authorization 则属于 HTTP 协议层是一个请求头字段。客户端需要把认证凭据发送给服务器时通常会通过 Authorization Header 携带。Bearer 是一种认证 Scheme【认证方案】表示当前 Authorization Header 中携带的是 Bearer Token。因此常见请求Authorization: Bearer eyJhbGciOiJIUzI1NiJ9... // 请求头名称: Authorization // 认证方案: Bearer // 凭据内容: eyJhbGciOiJIUzI1NiJ9...JWT 格式的 Token可以依次理解为Authorization是请求头名称Bearer表示凭据的使用方式最后的字符串是 Token如果该 Token 采用 JWT 格式它同时还是一个 JWT。二、Token 与 JWT 的职责区别Token 的概念非常宽泛。服务端登录成功后返回一串随机字符只要后续能够通过它定位用户身份这段字符串就可以称为 Token。因此看到“Token 鉴权”时还不能判断系统一定使用 JWT。JWT 的全称是JSON Web Token。常见的签名 JWT 由三个使用.分隔的部分组成xxxxx.yyyyy.zzzzz Header.Payload.Signature // Header: 描述签名算法等信息 // Payload: 保存 Claim如 sub、iat、exp // Signature: 验证 Header 与 Payload 是否被修改Header 描述签名算法等信息Payload 保存 Claim例如用户标识sub、签发时间iat、过期时间expSignature 用于验证 Header 与 Payload 是否遭到修改。这里需要特别注意JWT 中常见的 Base64url 编码只负责数据表示不提供数据保密能力。Payload 可以被直接解码查看因此密码、API Key 等敏感信息不应放入普通 JWT Payload。JWT 的主要优势之一是服务端可以通过签名直接验证 Token 的可信性无需每一次请求都通过数据库查询一条 Session 记录。不过这种无状态特性也意味着 JWT 不会自动解决实时撤销问题这属于后续会话管理需要考虑的内容。三、Authorization 与 Bearer 的协议职责Authorization 位于 HTTP 请求层用来携带客户端的认证信息。它本身并不限定使用 JWT也不限定必须采用 Token。例如Authorization: Bearer token // Authorization: HTTP 请求头承载认证凭据 // Bearer: 认证方案表示持有该凭据即可使用 // token: 具体的访问凭据这里的 Bearer 表示一种凭据传递方式。RFC 6750 对 OAuth 2.0 Bearer Token 的使用方式进行了定义。Bearer 可以理解为“持有该凭据即可使用”因此客户端需要保证 Token 在传输和存储过程中不会泄漏。JWT 与 Bearer 解决的是不同问题JWT定义 Token 内部怎样组织信息Bearer定义客户端怎样把 Token 作为认证凭据发送给服务端。一个 JWT 经常被用作 Bearer Token因此工程实践中两者经常同时出现。四、一次完整的认证请求链路把四个概念放回实际请求过程后关系会更加清晰。用户首先提交用户名、密码或其他登录凭据。认证服务完成校验后生成 Access Token并将 Token 返回给客户端。如果系统使用 JWT这一步会生成包含必要 Claim 并完成签名的 JWT。客户端随后访问需要认证的接口并在请求头中加入Authorization: Bearer access-token // 携带登录后获取的 Access Token 访问受保护接口请求到达 Gateway 或业务服务后认证组件读取 Authorization Header提取 Bearer Token。如果该 Token 是 JWT服务端通常会继续验证签名、过期时间、签发者和受众等信息。验证成功后从 Claim 中获得 userId、角色或其他可信身份信息再进入后续业务逻辑。因此整个过程可以简化为登录凭据 ↓ 认证服务 ↓ 生成 Token / JWT ↓ 客户端保存 ↓ Authorization: Bearer token ↓ 服务端校验 Token ↓ 获得用户身份 ↓ 进入业务接口 // 认证链路登录 → 签发 → 携带 → 校验 → 授权认证解决的是“当前请求来自谁”具体接口能否访问还需要继续执行授权判断。五、Apifox 中 Token 变量的实际含义接口调试工具通常会把登录返回的 Token 保存为环境变量例如token再在请求 Header 中配置Authorization: Bearer {{token}} // {{token}} 会被 Apifox 替换为环境变量中的实际值发送请求时Apifox 会把{{token}}替换为当前环境变量中的实际值。部分项目也会直接把Bearer eyJ... // 将 Bearer 前缀和 Token 整体保存为变量整体保存到变量中此时 Header 可以写成Authorization: {{token}} // 变量中已包含 Bearer 前缀Header 直接引用变量变量名称属于项目自己的配置约定。真正需要检查的是最终发送出去的 HTTP Header 是否符合服务端认证规则而不需要纠结变量为什么叫token、accessToken或其他名称。六、JWT 鉴权中的安全边界JWT 校验成功只能说明当前 Token 在既定规则下有效。服务端仍然需要进一步完成授权。例如用户携带一个有效 JWT 请求/orders/1001后端仍需判断订单 1001 是否属于当前用户。Token 认证不能代替资源权限校验。签名方式也会影响部署方式。HS256 等 HMAC 算法使用共享密钥完成签名和验证结构简单RS256、ES256 等方案使用私钥签发、公钥验证更适合多个业务服务只负责验证 Token 的微服务环境。Access Token 通常设置较短有效期Refresh Token 可以用于换取新的 Access Token。这样可以降低长期凭据泄漏造成的影响。生产环境还需要通过 HTTPS 保护 Bearer Token 的传输并结合浏览器端存储策略处理 XSS、CSRF 等安全问题。在 AI Agent 场景中同样应沿用原有认证边界。后端可以从已经验证的 Token 中提取 userId、tenantId、role 等可信信息再作为程序上下文传递给 Agent。用户在自然语言中声明“我是管理员”不能改变真实权限Tool 执行数据库查询或业务操作时仍需进行确定性的授权校验。完整 JWT 通常也没有必要发送给大模型。七、总结JWT、Token、Bearer 和 Authorization 可以按照三个层次理解。Token 是访问凭据的通用概念JWT 是 Token 的一种结构化实现Authorization 是 HTTP 中承载认证凭据的请求头Bearer 是 Authorization 中常用的一种认证方案。最终最值得记住的是这一条请求结构Authorization: Bearer JWT其中 Authorization 解决“凭据放在哪里”Bearer 解决“按照什么认证方案携带凭据”JWT 解决“Token 内部怎样组织和验证信息”。把四个概念放入同一条认证链路理解以后浏览器 Network、Apifox、Gateway 鉴权以及后端身份解析中的相关代码都会更加清晰。参考资料RFC 7519JSON Web TokenJWTRFC 7519: JSON Web Token (JWT) | RFC EditorRFC 6750OAuth 2.0 Bearer Token UsageRFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage | RFC Editor