この記事について
この記事は、2026-09-06時点のMicrosoft Graph / Microsoft identity platformの公式資料を確認して整理しています。検証ステータス：📘 公式仕様確認済み・実トークン未使用
access tokenは秘密情報として扱い、記事・ログには実値を載せません。
Microsoft GraphへAPIリクエストを送るとき、access tokenは「この呼び出しが許可されたアプリ・ユーザーから来ているか」をGraph側が判断するための認証材料として使われます。アプリはMicrosoft identity platformからtokenを取得し、通常はHTTP AuthorizationヘッダーへBearer tokenとして付けて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を持っている者」が利用できる性質を持つcredentialです。そのため、実値をパスワードと同じように慎重に扱います。
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には大きく2つの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を追加する」という進め方ではなく、endpointの公式permission表を確認します。
/me がapp-onlyで使えない理由を理解する
/meは「サインインしているユーザー」を表すaliasです。
delegated accessではサインインユーザーがいるため意味があります。一方、app-onlyではユーザーとしてサインインしていないので、/meという文脈がありません。
この違いを理解すると、Graph Explorerでは動いたのに自作daemonでは動かない、といった問題の切り分けにつながります。
access tokenを自分のアプリで信用しすぎない
access tokenにはclaimsが含まれる場合がありますが、クライアント側が「中身をdecodeできたから正しいtoken」と判断するものではありません。
Graphなどresource server側がtokenを検証し、対象APIを許可するか判断します。
JWT形式を学習目的でdecodeする記事とは、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
コメント