Microsoft Entra IDで`prompt=consent`が管理者同意済みでも一般ユーザーをブロックするようになった件

Microsoft Entra IDで`prompt=consent`が管理者同意済みでも一�般ユーザーをブロックするようになった件
カテゴリ
技術
タグ
Microsoft
Entra ID
OAuth
OIDC

TL;DR

  • Microsoft Entra ID (旧Azure AD) のOAuth認可フローで、prompt=consentを使用すると、テナント全体の管理者同意が付与済みであっても一般ユーザーが「管理者の承認が必要」画面でブロックされるように挙動が変わったよう
  • prompt=select_account 等に変更すると同じユーザーが問題なく認証できる
  • 2026年3月頃から複数の報告がMicrosoft Q&Aに上がっている
  • クライアント側ではなくMicrosoft側でアナウンス無く挙動が変わっており、仕様変更か不具合かは不明だが私は不具合であると考えている(後述)

背景

Microsoft Graph API経由のOutlook連携機能のためにOAuth 2.0認可コードフローを使っていて、認可URLにはprompt=consentを指定していました。
これは、ユーザーにアプリがアクセスするスコープ(権限)を明示的に表示し、透明性を確保するためです。

発生した事象

2026年3月頃から、以下の事象が発生するようになりました:

  1. Entra IDのユーザ同意設定が以下の何れかの場合:(組織利用では一般的な設定である理解)
  • 「ユーザーの同意を許可しない」
  • 「選択したアクセス許可に対して、検証済みの発行元からのアプリに対するユーザーの同意を許可する」
  1. テナントの管理者(Global Administrator)が「組織の代理として同意する」にチェックを入れて承諾済み
  2. 一般ユーザーがOutlook連携を行おうとすると「管理者の承認が必要」画面が表示される
  3. 管理者が再度承認しても、一般ユーザーのブロックは解消されない

再現条件の切り分け

検証の結果、promptパラメータの値のみで結果が分かれることが判明しました:

promptパラメータ管理者同意済みの一般ユーザー結果
prompt=consentブロックされるNG
prompt=select_account正常に認証できるOK
パラメータなし正常に認証できるOK

同じユーザー、同じ権限、同じ管理者同意の状態で、promptパラメータだけで結果が異なります。

同時期のMicrosoft Q&A上の類似報告

同様の問題は2026年初頭から複数報告されています:

Microsoftへの不具合報告

上記Q&Aなどでは、現挙動を仕様である前提として、prompt=consentの削除での回避などで終わってしまっていたので、 その仕様が不適切だとして「不具合では?」というQ&Aを投稿することとした。ここでの反応が悪ければ別の手段も再考します。

https://learn.microsoft.com/en-us/answers/questions/5847660/bug-report-prompt-consent-blocks-non-admin-users-e

この挙動の問題点(不具合だと考えられる根拠)

1. prompt=consentのOIDC仕様上の定義との乖離

promptパラメータはMicrosoft独自仕様ではなく、OpenID Connect Core 1.0 Section 3.1.2.1で定義されている標準パラメータです:

The Authorization Server SHOULD prompt the End-User for consent before returning information to the Client.

仕様上は「同意画面を表示する」というUIヒントであり、「ユーザーに同意権限がなければブロックする」とは定義されていません。

2. 管理者同意の無効化

prompt=consentが指定されると、Entra IDは既存の管理者同意を無視して、あたかも同意が存在しないかのように振る舞います。これにより:

  • prompt=select_account: 管理者同意が尊重される → 通過
  • prompt=consent: 管理者同意が無視される → ブロック

ポリシー判定(アプリが認可されているかどうか)が、UXパラメータ(同意画面を出すかどうか)に依存しているのは論理的に不整合です。

3. スコープ表示と管理者同意の両立が不可能に

prompt=consentには「ユーザーにアプリがアクセスするスコープを表示する」という正当なユースケースがあります。特にメールの読み書きのような高権限スコープでは、ユーザーへの透明性確保は重要です。

現在の挙動では:

  • スコープを表示したい → prompt=consentを使う → 一般ユーザーがブロックされる
  • ブロックを回避したい → prompt=select_accountを使う → スコープが表示されない

「スコープの表示」と「管理者同意の尊重」を両立する手段がなくなっています。

4. 管理者同意のみなら通るのに、ユーザー同意が加わると壊れる

最も不可解な点です:

  • ユーザーフローで同意が求められない場合(prompt=select_account): 管理者同意だけで十分 → OK
  • ユーザーフローで同意が求められる場合(prompt=consent): 管理者同意があっても、ユーザーにも同意権限が必要 → NG

管理者同意が付与されている状態で、ユーザー同意のフローが「加わる」ことによって、かえって管理者同意が無効化されるという矛盾した挙動です。

5. Microsoftの公式ガイダンスも実装困難

Microsoftのトラブルシューティングガイド Step 7では次のように案内されています:

Sometimes, signing in to the application requires passing the prompt parameter of consent or admin_consent. Once the application obtains consent, make sure the prompt parameter isn't specified.

これは「初回のconsent取得時はprompt=consentを使い、取得後は外す」ことを意味しますが、実装上これは非現実的です:

  • 認可URLを構築する時点(トークン取得前)で、そのテナントの同意状態を事前に知るAPIが存在しない
  • マルチテナントアプリでは、テナントごとに同意状態が異なり、Entra側で同意が取り消されてもアプリ側に通知されない

考えられる原因

2025年7月にMicrosoftはテナントのデフォルトのユーザー同意ポリシーをより制限的な設定に自動移行しています(MC1097272)。この変更自体は2025年8月末までにロールアウト完了とされていますが、prompt=consentとの組み合わせで問題が顕在化した時期は2026年初頭からです。

また、2026年3月にはConditional Accessの強化変更(OIDCスコープへの適用拡大)も予告されており、複数の変更が重なって影響している可能性があります。

いずれにしても、アプリケーション側の変更なしに挙動が変わっているため、Microsoft側の変更が原因であることは確実です。

回避策

認可URLのprompt=consentprompt=select_accountに変更します。

1- prompt=consent
2+ prompt=select_account
3

これにより:

  • 管理者同意が尊重され、一般ユーザーがブロックされなくなる
  • アカウント選択画面は表示されるため、UXとしても不自然ではない
  • ただし、ユーザーにスコープが表示されなくなるトレードオフがある

まとめ

項目内容
影響を受けるアプリprompt=consentを使用するOAuthアプリ全般
発生条件一般ユーザーの同意制限あり + prompt=consent使用
発生時期2026年3月頃〜
回避策prompt=select_accountへの変更
根本対応Microsoft側の修正待ち

prompt=consentは「同意画面を見せる」ための標準的なOIDCパラメータですが、現在のMicrosoft Entra IDでは管理者同意を無効化してユーザーをブロックするトリガーになってしまっています。同様の問題に遭遇した場合は、prompt=select_accountへの変更を検討してください。


関連記事