[!info] related notes

• 所属 MOC: 后端开发 MOC、安全 MOC
• 前置概念: Cookie、Session、Token 与 JWT 的关系
• 并列概念: Refresh Token、Server-side Session 鉴权
• 相关格式: JWT
• 关系笔记: Stateful、Stateless 与 Hybrid 认证架构

Access Token

一句话定义

Access Token 是调用受保护资源时携带的访问凭证。它通常生命周期较短、使用频率高，用来让 Resource Server 建立调用方身份与一部分授权上下文。

它是“角色”，不是格式

Access Token
= 这个凭证拿来访问 API

JWT / opaque string
= 这个凭证采用什么表示方式

所以 Access Token 可以是 JWT，也可以是不透明随机字符串。JWT 并不天然等于 Access Token，Refresh Token 也不要求使用 JWT。

典型请求链

Client
  │ Authorization: Bearer <access-token>
  ▼
Resource Server
  │
  ├─ 验证凭证真实性/有效期
  ├─ 建立 principal
  └─ 执行业务授权

如果 Access Token 是自包含且可本地验证的 JWT，Resource Server 可以只验证签名、exp、iss、aud、scope 等，不必每次访问 Session Store。

如果 Access Token 是 opaque token，则通常需要通过服务端状态查询或 introspection 才知道它代表什么。

为什么通常短期有效

短期 Access Token 的核心目的之一是限制“已签发快照”和“当前真实状态”之间的滞后窗口。

例如 12:00 签发 Token，12:01 用户被封禁；如果 Resource Server 只做本地 JWT 验证，那么这个 Token 在过期前可能仍被接受。因此 TTL 越长，撤销或权限变化的 stale window 越大。

5 分钟、15 分钟等只是工程取值，不是协议规定的固定标准。

Access Token 能证明到哪一层

它通常可以帮助回答：

你是谁？
这个凭证由谁签发？
它有没有过期？
它带有哪些 scope / role？

但不能自动回答所有资源级权限：

User 42 能不能修改 Assessment 789？

这仍可能需要根据当前数据库状态检查 ownership、组织成员关系、资源状态或其他 Policy。

因此：

Access Token
→ Authentication + coarse-grained authorization context

Business Policy / DB
→ fine-grained resource authorization

与 Session 的关系

两种常见模式：

每请求查 Session

Access Token 只作为定位/认证凭证，每次请求还要查服务端 Session。这样即时撤销强，但失去一部分无状态优势。

短期无状态快路径

Access Token 本地验证，不查 Session；只有 Refresh、Logout、Revocation 等生命周期操作回到 Session/Grant Store。这是典型 Hybrid 架构。

浏览器中的传输与存储

Access Token 可以通过：

• Authorization: Bearer ...
• Cookie

传输。若由 JavaScript 主动加 Header，通常要考虑 XSS 窃取；若放在自动携带 Cookie，则还要考虑 CSRF、SameSite 等边界。

边界与常见误解

• Access Token 不等于 JWT。
• Access Token 不等于 Session。
• Access Token 验证成功不等于当前资源操作一定被授权。
• “短期”是风险窗口设计，不存在所有系统统一的 5 分钟标准。
• 是否需要每请求查 Session 取决于架构，不是 Access Token 的定义。