关于本文
本文基于 2026-09-06 的 Microsoft Graph / Microsoft identity platform 官方资料进行整理。验证状态：📘 已确认官方规范・未直接使用实际令牌
access token 作为机密信息处理，文章及日志中绝不包含实际值。
向 Microsoft Graph 发送 API 请求时，access token 被 Graph 用于判断“此调用是否来自获准的应用或用户”作为认证凭据。应用程序从 Microsoft identity platform 获取 token，通常将其作为 Bearer token 附加到 HTTP Authorization 头中发送给 Graph。
从获取 token 到调用 Graph
sequenceDiagram
participant U as User / App
participant I as Microsoft identity platform
participant G as Microsoft Graph
U->>I: 認証・token要求
I-->>U: access token
U->>G: Authorization: Bearer <token>
G->>G: tokenとpermissionを検証
G-->>U: 許可されたAPI結果
这并不是每次都直接向 Graph 发送用户名和密码的结构。
什么是 Bearer token
Bearer token 是一种凭据，其性质是“持有该 token 的人”可以使用它。因此，其实际值必须像密码一样谨慎对待。
HTTP 请求的格式概念如下：
GET /v1.0/me HTTP/1.1 Host: graph.microsoft.com Authorization: Bearer <access-token>
请注意不要将实际的 token 粘贴到文章、GitHub、截图或 AI 聊天中。
委派访问（delegated access）与仅应用访问（app-only access）
Microsoft Graph 大致有两种 access scenario（访问场景）。
flowchart TB
A[Graph APIを呼ぶ] --> B{誰として動く?}
B -->|サインインユーザーの代理| C[Delegated access]
B -->|アプリ自身| D[App-only access]
C --> E[Delegated permissions / scopes]
D --> F[Application permissions / app roles]
Delegated access
用户登录，应用程序代表该用户调用 Graph。
在这种情况下，不仅取决于授予应用的 delegated permission，还与用户自身对目标 resource 拥有的权限相关。
App-only access
无需用户登录，以应用自身的 identity 调用 Graph。
这有时用于后台处理或守护程序（daemon/service）等。由于 Application permission 的影响范围往往较大，因此管理员同意和最小权限设计非常重要。
permission 并非“可使用 API 的万能券”
Microsoft Graph 针对各个 resource 和操作公开了细粒度的 permission。
例如存在 User.Read 这样的 permission 名称，可根据所需操作进行选择。
Microsoft 的官方指南也建议申请应用所需的最小权限。
flowchart LR
A[やりたいAPI操作] --> B[必要permissionを確認]
B --> C[最小権限を選ぶ]
C --> D[必要なconsent]
D --> E[token取得]
E --> F[Graph呼び出し]
切勿采取“因为无法运行所以添加高权限 permission”的做法，而应查阅端点的官方 permission 表。
理解 /me 无法用于 app-only 的原因
/me 是表示“当前登录用户”的 alias（别名）。
由于 delegated access 存在登录用户，因此它是有意义的。另一方面，在 app-only 中由于没有以用户身份登录，因此不存在 /me 的上下文。
理解了这个差异，将有助于排查诸如“在 Graph Explorer 中可以运行，但在自建 daemon 中却无法运行”之类的问题。
不要过分信任自己应用中的 access token
access token 虽然可能包含 claims，但客户端不能仅仅因为“能够解码内容”就判断它是正确的 token。
Graph 等 resource server 侧会验证 token，并判断是否允许目标 API 调用。
我们必须将学习目的的 JWT 格式解码文章，与验证 token 的职责区分开来思考。
401 与 403 的思考方式
简化来说：
401 系列：怀疑认证材料，例如缺少 token、无效、过期等
403 系列：即使 token 被识别，也应怀疑是否缺少该操作所需的 permission 或 resource 权限
不过，实际的错误请查阅 Graph 的 error body 以及相应 endpoint 的官方资料。
flowchart TB
A[Graph request failed] --> B{HTTP status}
B -->|401| C[token取得・送信・期限などを確認]
B -->|403| D[permission / consent / user権限 / RBAC等を確認]
B -->|その他| E[Graph error bodyと公式docsを確認]
总结
access token 是用于让 Graph 判断是否为允许调用的凭据（credential）
通常通过 Authorization: Bearer 头发送
delegated access 代表用户，app-only 代表应用本身
将 permission 控制在最小必要范围
/me 在 delegated access 的上下文中使用
切勿将真实的 token 留在日志、GitHub、文章或 AI 中
官方信息・第一手资料
Microsoft Learn — Authentication and authorization basics
https://learn.microsoft.com/en-us/graph/auth/auth-concepts
Microsoft Learn — Overview of Microsoft Graph permissions
https://learn.microsoft.com/en-us/graph/permissions-overview
Microsoft Learn — Get access on behalf of a user
https://learn.microsoft.com/en-us/graph/auth-v2-user
RFC 6750 — Bearer Token Usage
https://www.rfc-editor.org/rfc/rfc6750.html
コメント