1 基本概念

1.1 定义与作用

访问令牌是一种用于证明访问权限的凭证，常由认证或授权系统在用户、应用或设备完成验证后签发。它的主要作用，是让调用方在后续访问受保护资源时，无需反复提交用户名、密码等敏感信息，而是通过携带令牌来完成身份确认与权限判定。

在实际系统中，访问令牌往往对应某一段有限时间内的授权结果。资源服务器收到令牌后，会依据预设规则判断请求是否允许通过，从而实现更安全、便捷的访问控制。

1.2 访问令牌的核心特征

1.2.1 临时性

访问令牌通常具有有效期限制，常见为数分钟到数小时不等。到期后，令牌即失效，调用方需要重新获取新的令牌，或借助刷新机制继续使用系统服务。

这种短期有效的设计有助于降低凭证泄露后的风险。即使令牌被截获，攻击者也只能在有限时间内利用它发起请求。

1.2.2 可验证性

令牌必须能够被接收方验证真伪与合法性。验证方式可能是检查服务端存储记录，也可能是校验数字签名、有效期和权限字段。

可验证性使令牌不仅是“携带即通行”的凭证，也是一种可被系统自动判定的授权载体，便于在分布式环境中统一处理访问请求。

1.2.3 最小权限原则

访问令牌通常只包含完成当前任务所必需的权限。系统会尽量避免赋予过宽的访问范围，以减少误用和滥用的可能。

例如，一个用于读取用户资料的令牌，不应同时默认具备删除数据或管理账户的能力。这样的权限控制有助于提高整体安全性。

1.3 访问令牌与身份凭证的区别

访问令牌与用户名、密码、证书等身份凭证并不完全相同。身份凭证通常用于“证明你是谁”，而访问令牌更多用于“证明你可以做什么”。

在很多流程中，身份凭证先用于完成登录或授权，再由系统签发访问令牌。此后，资源访问主要依赖令牌，而不是直接暴露初始凭证。这种分离可以降低敏感信息在网络传输和长期保存中的风险。

2 工作原理

2.1 令牌的签发

2.1.1 认证后生成

访问令牌一般在身份验证成功后生成。系统会确认用户、客户端应用或设备的身份，然后创建一个包含访问权限信息的令牌。

签发过程可能发生在登录阶段，也可能出现在第三方授权、设备绑定或服务对服务认证之后。不同系统的具体流程会有所差异，但核心逻辑一致，即先确认主体，再发放凭证。

2.1.2 授权范围绑定

令牌签发时通常会绑定特定的授权范围，例如可访问的接口、可执行的操作或可读取的数据类别。这样，令牌虽然代表一定权限，但权限并不无限扩展。

授权范围的绑定有助于系统在后续校验时快速判断请求是否越权，也便于不同应用按需申请不同级别的访问能力。

2.2 令牌的传递

2.2.1 HTTP 请求头

在 Web API 场景中，访问令牌最常通过 HTTP 请求头传递。调用方会在请求中附带令牌，服务器从头部读取后进行验证。

这种方式结构清晰，适合接口调用和跨服务通信。常见做法是将令牌放入统一的认证字段中，便于后端中间件处理。

在浏览器环境中，令牌也可能存放在 Cookie、会话存储或本地存储中。不同存储方式各有优缺点：Cookie 便于自动携带，但需要注意跨站相关风险；本地存储使用灵活，但需防范脚本窃取。

选择哪种方式，通常取决于应用形态、安全要求以及前后端架构。

2.3 令牌的校验

2.3.1 签名验证

若访问令牌采用带签名结构，服务器会先验证签名是否正确，以确认令牌未被篡改。签名验证通常依赖密钥或公钥体系。

一旦签名无效，系统可直接拒绝请求，无需继续处理其余内容。这一步是防止伪造令牌的重要环节。

2.3.2 过期时间检查

服务器还会检查令牌是否仍在有效期内。若当前时间已超过令牌的过期时间，该令牌通常会被视为无效。

过期检查不仅用于安全控制，也有助于系统管理授权周期，避免长期存在的凭证积累过多风险。

2.3.3 权限范围检查

通过签名和时间校验后，服务器还要确认请求操作是否属于令牌所允许的范围。即便令牌本身有效，若请求内容超出授权范围，也应被拒绝。

这一环节体现了权限控制的细化程度，是区分“可认证”与“可访问”的关键步骤。

3 常见类型

3.1 不透明令牌

3.1.1 服务端存储与查询

不透明令牌通常只是一串随机字符串，本身不直接携带可读信息。服务器会把它与后台记录关联，接收到请求后再去查询对应的用户、权限和状态。

这种方式的优点是实现直观，便于集中撤销与跟踪；缺点是每次验证都可能需要访问存储系统，增加了服务端依赖。

3.1.2 适用场景

不透明令牌适合需要强控制、便于立即失效或集中管理的场景，例如传统 Web 会话、企业内部系统或对撤销要求较高的业务环境。

由于令牌内容不直接暴露，外部难以从字符串本身读取权限信息，这也使其在某些高安全场合更受青睐。

3.2 JWT 令牌

3.2.1 头部、载荷与签名

JWT 令牌通常由头部、载荷和签名三部分构成。头部用于描述算法等元信息，载荷承载声明内容，签名则用于防止篡改。

这种结构使其既能表达身份信息，也能附带权限、过期时间等字段，方便在不同系统间传递。

3.2.2 自包含信息

JWT 的特点之一是自包含，即令牌本身往往包含验证所需的主要信息。服务端在许多情况下无需额外查库即可完成初步判断。

不过，自包含并不等于可无限信任。系统仍需关注签名、时效、受众与权限边界，否则容易出现过度依赖令牌内容的问题。

3.3 Bearer Token

3.3.1 持有即使用

Bearer Token 的含义是“谁持有，谁可用”。只要请求中携带了有效令牌，资源服务器通常就会将其视为合法访问凭证。

这种机制实现简单，兼容性好，因此在接口调用中非常常见。

3.3.2 安全风险特点

由于 Bearer Token 本质上不要求额外的持有者证明，一旦被窃取，攻击者即可冒用。因此它对传输安全、存储安全和泄露防护的要求较高。

在实际部署中，常需要结合 HTTPS、短有效期和刷新机制降低风险。

3.4 OAuth 相关令牌

3.4.1 访问令牌

在 OAuth 体系中，访问令牌用于代表授权结果，使客户端能够访问资源服务器上的受保护数据。其权限通常由用户授权与客户端请求共同决定。

3.4.2 刷新令牌

刷新令牌主要用于在访问令牌失效后申请新的访问令牌。它通常有效期更长，使用场景也更受限制，常与后端授权服务器交互。

这种设计使用户不必频繁重新登录，同时又能保持访问令牌的短期有效特性。

3.4.3 授权码

授权码是 OAuth 流程中的中间凭证，常用于先在前端或浏览器中完成授权，再由后端交换访问令牌。它本身通常有效期很短，且只能使用一次。

授权码的引入有助于减少敏感令牌在前端直接暴露的机会。

4 应用场景

4.1 API 接口鉴权

访问令牌最典型的用途是 API 鉴权。客户端调用接口时携带令牌，后端据此判断是否允许访问指定资源。

这一方式适合移动应用、桌面客户端、第三方集成和开放平台，能有效替代简单的用户名密码直传模式。

4.2 单点登录

在单点登录环境中，用户登录一次后，可在多个系统之间复用授权结果。访问令牌在其中承担了跨系统验证身份和权限的作用。

这类应用通常依赖统一认证中心，减少重复登录带来的操作成本，也便于集中管理用户状态。

4.3 第三方应用授权

许多平台允许用户授权第三方应用访问自己的部分数据。此时，访问令牌用于标识该第三方已获得特定权限，而不需要知道用户的原始密码。

这使授权可以精确到某些功能或数据范围，例如读取资料、发布内容或管理特定资源。

4.4 移动端与前端应用

移动应用和单页应用常使用访问令牌维持登录状态。由于这类客户端通常与后端通过接口交互，令牌能够在多次请求之间稳定传递认证结果。

在此类场景中，还常配合刷新机制，以降低用户频繁登录的体验负担。

4.5 微服务间通信

在微服务架构中，服务与服务之间也可能使用访问令牌完成身份确认与权限控制。这样可以让每个服务都能验证调用方身份，并按需限制可访问的功能。

这种方式有利于在复杂系统中建立统一的访问边界，避免内部调用完全放任不管。

5 安全性

5.1 生命周期管理

5.1.1 有效期设置

访问令牌的有效期通常不宜过长。较短的有效期可以缩小泄露窗口，但也会增加重新获取令牌的频率，需要在安全与体验之间做平衡。

实际系统会根据业务敏感度、客户端类型和风险等级来设定不同的时长。

5.1.2 自动失效与轮换

许多系统会在令牌失效后自动要求重新认证，或通过轮换机制签发新令牌。轮换可以减少长期使用同一凭证带来的风险。

若发现异常登录、权限变更或安全事件，也可借助轮换与失效机制迅速收紧访问范围。

5.2 存储安全

5.2.1 客户端安全存储

客户端应尽量选择更稳妥的方式保存令牌，避免将其暴露在容易被脚本读取或无意泄漏的位置。不同平台需要采用不同策略，例如原生应用与浏览器应用的做法并不相同。

合理的存储方案往往与加密、隔离和最小暴露原则配合使用。

5.2.2 防止泄露与窃取

令牌一旦泄露，就可能被冒用。因此，传输链路应使用加密连接，日志、错误信息和调试输出中也不应明文记录敏感内容。

开发和运维环节中的疏漏，往往比攻击者本身更容易造成令牌外泄。

5.3 常见攻击与防护

5.3.1 重放攻击

攻击者若截获合法令牌，可能在未过期前重复使用，形成重放攻击。防护方式包括缩短有效期、绑定设备或上下文信息，以及在关键操作中增加额外校验。

5.3.2 XSS 与 CSRF 风险

前端存储令牌时，脚本注入攻击可能直接读取并转移凭证；而基于 Cookie 的传递方式则可能面临跨站请求伪造风险。应根据实现方式分别采取内容安全策略、输入过滤、同源限制和防伪标记等措施。

5.3.3 令牌劫持

令牌劫持是指攻击者在网络、浏览器或终端环节截获并接管令牌的行为。防护重点包括加密传输、终端安全、最小权限和及时吊销。

5.4 撤销与吊销机制

在必要时，系统应能使已签发的令牌失效，例如用户主动退出、修改密码、设备丢失或检测到异常行为之后。

对于不透明令牌，撤销通常较直接；对于自包含令牌，系统可能需要借助黑名单、短有效期或版本号等方式实现失效控制。

6 相关标准与协议

6.1 OAuth 2.0

OAuth 2.0 是一种授权框架，广泛用于委托访问。它定义了客户端如何在不直接获取用户密码的情况下，获得受保护资源的访问权限。

访问令牌在该框架中是核心输出之一。

6.2 OpenID Connect

OpenID Connect 建立在 OAuth 2.0 之上，进一步解决身份认证问题。它不仅关注授权，还会通过身份令牌等机制表达用户身份信息。

在许多现代登录系统中，OpenID Connect 与访问令牌共同工作。

6.3 JWT 标准

JWT 是一种用于表示声明的紧凑格式，常作为访问令牌的载体。相关标准定义了其结构、签名方式和相关字段约定。

它因易于跨语言处理、便于网络传输而被广泛采用。

6.4 相关 HTTP 认证机制

访问令牌通常与 HTTP 的认证机制配合使用。最常见的做法是在请求中携带认证信息，由服务器依据约定格式解析并验证。

这使得令牌能够自然融入 Web 协议的请求响应模型中。

7 实现与实践

7.1 服务端实现模式

7.1.1 状态化管理

状态化模式下，服务端保存令牌与会话状态的关联信息。每次请求到来时，都需要查找后台记录以确认令牌是否有效。

这种方式便于撤销、审计和集中控制，适合需要强管理能力的系统。

7.1.2 无状态管理

无状态模式下，服务端不保存或少量保存令牌状态，而主要依赖令牌自身携带的信息完成验证。常见于 JWT 场景。

它有利于扩展和分布式部署，但对签名、过期和权限设计提出了更高要求。

7.2 客户端处理方式

7.2.1 刷新与续期

客户端在访问令牌接近失效或已经失效时，通常会使用刷新机制获取新令牌。这样可以减少用户重复登录的次数。

合理的续期流程应尽量对用户透明，同时保证失败时能平稳回退到重新认证。

7.2.2 自动重试

在短暂的网络波动或令牌刚过期的情况下，客户端可能先尝试刷新，再重试原请求。该方式能提升体验，但需要避免无限重试和并发刷新冲突。

常见做法是统一封装请求拦截器或中间件来处理这一逻辑。

7.3 权限设计实践

7.3.1 细粒度授权

细粒度授权强调把权限拆分到具体功能或资源级别，例如只允许读取、只允许更新某类数据，或只允许访问某个项目空间。

这样的设计更符合实际业务边界，也便于审计和问题排查。

7.3.2 作用域划分

作用域是访问令牌中常见的权限表达方式，用来描述令牌可覆盖的操作范围。合理划分作用域，有助于让客户端按需申请权限，避免过度授权。

作用域命名通常应清晰、稳定，并与业务语义相匹配。

8 常见问题

8.1 令牌过期后的处理

当令牌过期时，系统通常会返回需要重新认证或刷新令牌的提示。客户端应根据返回结果进行续期、重登或引导用户完成下一步操作。

若频繁出现过期问题，可能意味着有效期设置过短、刷新流程异常或客户端保存状态不稳定。

8.2 多设备登录管理

同一账户在多设备上登录时，系统可能为每台设备签发不同令牌，以便分别管理各端状态。这样，某一设备退出或失效时，不一定影响其他设备。

如果业务要求更严格，也可以设置单点在线或会话上限策略。

8.3 令牌与会话的关系

会话通常是服务端维持的一种登录状态记录，而访问令牌是用于访问资源的凭证。两者可以并存，也可以分别采用不同实现方式。

在传统 Web 应用中，会话较常见；在 API 和分布式架构中，访问令牌往往更灵活。

8.4 调试与排错方法

排查令牌问题时，通常要依次检查签发流程、有效期、签名、权限范围、请求携带方式以及服务器日志。若涉及前端，还需确认存储位置、跨域设置和重试逻辑是否正确。

对于结构化令牌，还可以解码查看字段内容，以确认是否存在时钟偏差、受众不符或作用域不足等情况。