Access Token 是什么
一句话总结
Access Token 是 OAuth 2.0 签发的”数字房卡”——它不写你的名字，只写了”谁在什么时间内能访问什么资源”。API 收到它就知道放不放行。
🤔 为什么会有它 / 解决了什么问题
没有 Access Token 的话，每次调 API 都要传用户名密码。密码满天飞的后果：日志里全是明文密码、第三方应用拿着密码为所欲为、改密码后所有集成全断。
Access Token 解决的正是这个问题：你给第三方应用的不是密码，而是一张写着权限范围的、会过期的令牌。
🔍 具体原理 / 运作逻辑
Access Token 和 ID Token 是 OIDC 流程同时签发的两个令牌，分工不同：
| Access Token | ID Token | |
|---|---|---|
| 给谁用 | API（后端验证） | SP（前端验证） |
| 包含什么 | scopes（权限范围） | 用户信息（name, email） |
| 格式 | 通常不透明字符串 | JWT（可解码） |
| 谁验证 | Resource Server | SP |
具体流程：Grafana 拿到 Access Token 后 → 调 Frappe API → Frappe 检查 Token 的 scope → 决定是否返回数据。
更硬核的技术细节（点击展开）
Frappe 签发的 Access Token 实际是一个 Bearer Token（持有者令牌）——谁持有它，谁就有权限。所以：
- 必须走 HTTPS，防止中间人截获
- 有效期通常 1 小时（3600 秒）
- 可以配合 Refresh Token 自动续期，避免频繁重登录
- 可以通过
/api/method/frappe.integrations.oauth2.introspect_token检查 Token 是否还有效
🧭 什么情况下会用到 / 什么场景会遇到它
- 写脚本调用 Frappe API 时，先在 OAuth Client 拿到 Access Token，然后
Authorization: Bearer <token> - 任何”用 Token 调 API”的场景
🔗 关联 / 经常一起出现的概念
- ID Token：同时签发但用途不同——一个证明身份，一个授权访问
- OAuth 2.0：Access Token 是 OAuth 2.0 的核心产物
- OIDC：OIDC 在 Access Token 之外多签了一个 ID Token
⚠️ 注意事项 / 常见误区
- Access Token 不是身份证明，不要用它来判断”用户是谁”
- Bearer Token 意味着谁拿到就能用——泄露等于密码泄露
- 浏览器/前端不要存 Access Token（除非用 BFF 模式），放后端
📎 记忆锚点
Access Token = 酒店房卡。上面没有你的名字，只有”房间号 + 有效期”。谁拿到都能进，所以要保护好别丢。
📝 更新日志
| 日期 | 改动 | 原因 |
|---|---|---|
| 2026-07-09 | 首次创建 | Frappe SSO/OIDC 集成准备 |