Microsoft Graphの403 Authorization_RequestDeniedやInsufficient privileges to complete the operationは、すぐに「API permissionを追加すれば直る」とは限りません。呼び出したAPI method、OAuth flow、tokenのaud・scp・roles、permissionのconsent、delegated callならサインインユーザー自身の権限やlicenseを順に照合します。最初に対象API methodのMicrosoft Learnでleast-privileged permissionを確認し、必要な権限だけを管理者へ依頼してください。
Microsoftの認証エラーガイドは、permissionの種類違い、consent不足、ユーザー権限・license不足、Graph以外をaudienceとするtoken、Conditional Accessなどを403の原因候補として挙げています。どの原因かは個別のAPI methodと応答内容で変わります。特定tenantやアプリを確認した結果ではないため、記事の手順を実際のエラー応答と照合してください。
目次
変更前にエラーと呼び出し条件を保存する
同じアプリでも、ユーザーとして呼ぶdelegated flowと、daemonとして呼ぶapplication flowでは認可主体が異なります。権限を追加する前に、失敗した一件を次の形で記録します。
-
Graph endpoint、HTTP method、API version、対象resource
-
HTTP status、error code/message、時刻、Graph request-id / client-request-id
-
token acquisition flowと対象tenant
-
呼び出しがdelegatedかapplicationか、サインインユーザーの有無
-
API methodのpermission referenceに示されたleast-privileged permission
-
エラーが起きた操作と成功する操作の違い
Authorization header、access token全体、client secret、ユーザーの個人情報は共有しないでください。調査にtoken claimが必要なときも、承認されたローカル環境で必要なclaimだけ確認し、tokenそのものをWeb上のdecode serviceやチャットへ貼らないようにします。
1. 呼び出し主体とOAuth flowを合わせる
Microsoft Graphの403では、アプリに登録したpermissionと、実際に取得したaccess tokenのpermission typeが一致しているかを確認します。Microsoftのガイドでは、application permissionを設定しているのにdelegated interactive flowでtokenを取得する、またはdelegated permissionを設定しているのにclient credentials flowを使うと、permissionの型が合わず失敗する例が説明されています。
表は横にスクロールできます
| 実行形態 | 呼び出し主体 | tokenで主に確認するclaim | 次に確認すること |
|---|---|---|---|
| Delegated access | アプリがサインインユーザーに代わって呼ぶ | scp（delegated scopes） | consentされたscopeと、ユーザー本人のdirectory role / resource権限 |
| Application access | ユーザーなしでアプリ自身が呼ぶ | roles（application permissions） | app-only permission、必要なadmin consent、API methodの対応可否 |
| Flowとpermission typeが不一致 | 期待した主体と実際のtokenが異なる | 期待したclaimがない、または別の型 | MSALで選択したflow、scope、tokenを取得したtenant・resource |
scpとrolesは診断の手掛かりですが、ひとつのclaimだけでAPI全体が許可されたとは判定できません。各Graph API methodが受け付けるpermission type、必要なdelegated / application permission、ユーザーの役割要件を、該当するmethod referenceで確認します。あるAPIで使えるapplication permissionが別のAPIにも使えるとは限りません。
2. tokenのaudienceがMicrosoft Graphか確認する
access tokenのaudは、そのtokenを受け取るresourceを示します。Microsoft Graph向けAPIへ、Azure AD Graph、Outlook、SharePointなど別resource向けに取得したtokenを送ると、audienceが一致せず403になる場合があります。
クライアントが要求したscope/resourceと、実際に呼び出したhost・APIを照合してください。tokenを安全な環境で確認できる場合は、secretを共有せずaud、scpまたはroles、iss、tenant・アプリ識別の整合を調べます。JWTを読めること自体は署名検証や正当性の証明ではありません。tokenの発行・更新はMSALなど公式に推奨される認証ライブラリ経由で行い、手作業でtokenを作り変えないでください。
3. API methodに必要な最小permissionとconsentを照合する
「Microsoft Graphの読み取り」などの大まかな名称ではなく、失敗したendpointのmethod referenceにあるpermission tableを確認します。
-
API method・resource・HTTP methodを確定する。
-
delegated / applicationのどちらで実行するかを決める。
-
permission referenceのleast-privileged欄から必要な候補を特定する。
-
Entra app registrationに同じ種類のpermissionが設定されているか確認する。
-
tenantでconsent済みか、管理者承認が必要なpermissionかを権限者が確認する。
-
再取得したtokenで
scp/rolesが想定と整合するか、秘密を出さず確認する。
アプリ登録へpermissionを追加しただけで、既存のaccess tokenへ新しい権限が即時反映されるとは限りません。consent後は対象tenant・flowで新しいtokenを取得し、該当API methodを再試験します。管理者へ依頼するときは、endpoint、flow、必要な最小permission、失敗時刻とrequest-idを渡し、理由のない包括的なDirectory権限を要求しないでください。
4. delegatedならユーザー自身の権限・licenseも確認する
delegated permissionでは、Graphはアプリに与えられたpermissionだけでなく、サインインユーザーが持つ権限も評価します。Microsoftのauthorization error guideによると、ユーザーに対象操作のprivilegeがない、または参照するデータに必要なlicenseがない場合も403になり得ます。
そのため、同じアプリ・同じendpointでも、別ユーザーでは結果が違うことがあります。管理者ユーザーで成功したから一般ユーザーでも成功するとは限りません。逆に、application permissionを使うdaemon flowにサインインユーザーの権限を当てはめても原因は特定できません。API methodが要求するユーザーrole・license条件を確認し、誰の権限不足かを切り分けます。
5. Conditional Accessやresource固有条件を分ける
Conditional Accessによって追加の認証情報が必要なとき、token取得時にinteraction_requiredが出る場合や、Graph呼び出しで403 insufficient_claimsが返る場合があります。応答に含まれるchallengeに従うべきケースと、Graph permission不足は別です。Microsoft Authentication Library（MSAL）によるConditional Access challenge handlingを確認し、追加認証を安全に完了してください。
また、一部Graph APIは対象サービス固有の条件に影響されます。Microsoftのエラーガイドは、Exchange Onlineに関係するAPIではEWS application access policyが拒否要因となり得る例や、ネストされたグループの権限が異なる場合の例を示しています。すべてのAuthorization_RequestDeniedが同じpermission追加で解決すると考えず、error code/messageに具体的なpolicyやresourceが示されていないか読みます。
症状別の切り分け表
表は横にスクロールできます
| 症状・確認結果 | 優先して確認すること | 避ける対応 |
|---|---|---|
scpが期待どおりでない | delegated flow、要求したscope、tenant、consent、token取得時刻 | application permissionを無条件に追加する |
rolesがない / 異なる | client credentials flow、application permission、admin consent、対象tenant | delegated flow用scopeだけを追加し続ける |
audがMicrosoft Graphでない | token要求時のresource / scopeとGraph endpoint | tokenを別APIへ流用する |
| app permissionはあるがdelegated requestが失敗 | サインインユーザーのrole、license、resourceへのアクセス | 広いDirectory権限でユーザー不足を隠す |
insufficient_claimsや追加認証要求 | Conditional Access challengeとMSALの再認証処理 | 追加claimを無視して同じtokenを繰り返す |
| 特定resourceだけ403 | Graph methodのpermission表、resource固有policy、request-id | Graph全体の権限を一律に広げる |
| consent直後も失敗 | tenant、正しいapp、consent済みpermission、再取得token | 古いtokenを使って設定だけを何度も変更する |
HTTP 401と403も分けます。Microsoftのガイドは、401ではtokenの欠落・無効・期限切れなどのvalidityを先に確認し、403では権限、consent、ユーザー権限、resource audienceなどのauthorizationを調べるよう整理しています。実際のresponse codeとbodyを優先し、statusだけで原因を断定しないでください。
管理者へ依頼するときのメモ
tenant administratorへ権限確認を依頼する場合、次を記載すると最小範囲を検討しやすくなります。
-
Graph endpoint / method / resource
-
flow：delegated または application
-
対象tenant、app registrationの識別子
-
API method referenceのleast-privileged permission
-
現在のconsent状態、取得tokenにある必要claimの有無（claim値は安全な範囲のみ）
-
error code、時刻とtimezone、request-id
-
期待する操作と、再現時に使ったユーザーの必要role/license
-
希望する確認：設定閲覧、consentの要否判断、変更後tokenによる限定再試験
client secret、access token、Authorization headerを依頼文へ入れません。権限の変更を承認できるのはtenantの権限者です。十分な根拠がないままGlobal Administrator等の強いroleをアプリやユーザーへ付与しないでください。
再試験の手順と完了条件
原因を一つずつ確認し、permission追加、consent、ユーザー変更、flow変更を同時に行わないでください。変更前後の記録を分ければ、どの条件が結果へ影響したかを追えます。
-
正しいtenant・Graph endpoint・OAuth flowを固定する。
-
対象API methodの最小permissionとユーザー条件を照合する。
-
管理者が必要なconsentや設定を判断した場合、承認された変更だけを実施する。
-
同じtenant・flowで新しいtokenを取得する。
-
機微情報を出さず必要claimを照合し、限定したAPI callを一度実行する。
-
新しいHTTP status、error code、request-idを保存し、想定外のresourceへアクセスしていないか確認する。
次にすること： 失敗したGraph endpointと呼び出し主体を確定し、tokenのaudとdelegatedならscp、applicationならrolesを安全に照合します。そのうえでAPI methodのleast-privileged permission・consent・ユーザー条件を見ます。原因が一つに絞れる前に広いpermissionを足さず、必要な場合だけtenant adminへ具体的な依頼を出してください。
参考資料
Evidence checked: 2026-10-15. No Entra tenant, app registration, access token, user role, license, or Graph request was inspected.