日々の仕事やプライベートでMicrosoftアカウントを使っていると、サインイン時に「AADSTS900561: The endpoint only accepts POST requests. Received a GET request.」が表示されることがあります。これはアクセス先が受け付けるHTTPメソッドと実際の要求が一致しないという意味です。この記事では、公式のエラー説明と、アプリ管理者・開発者が要求先とメソッドを調べる手順を整理します。
AADSTS900561：要求先とHTTPメソッドを組で確認する
| 確認対象 | 読み方・次の操作 |
|---|---|
| POSTを受け付ける先へGET | 表示されたエラーが指す不一致。エラーだけでは原因の製品や設定は特定できない |
| ブラウザーの戻る操作の直後だけ | 公式には不正な要求が生じる例として記載。サービスの通常の入口からサインインし直して再現するか確認 |
| 自作アプリで毎回再現 | /authorize・/token・自分のcallbackのどこで失敗するか、URLとメソッドを記録 |
| Outlook.comなどを利用するだけ | アプリコードを変更する必要はない。Outlook利用者向けの切り分け手順へ |
Microsoft公式のAADSTS900561説明では、開発者の誤りとブラウザーの「戻る」で生じる要求を挙げています。一度表示されても通常の入口からの再サインインが成功する場合と、毎回再現する場合を分けます。
AADSTS900561エラーの概要
Microsoft Entra ID（旧Azure AD）のエラー一覧では、アクセス先がサポートするHTTPメソッドに対して、別のメソッドを受け取った状態を示します。表示文が「only accepts POST」「Received a GET」の場合はPOSTを受け付ける先にGETが到着しています。すべてのGET通信が誤りという意味ではありません。
エラーの全文、発生時刻、直前の操作、利用したアプリを残します。Safari・Edge・Xbox・Exchangeハイブリッドといった製品名だけで原因を決めず、毎回同じ入口と手順で再現するかを確認してください。
エラーから分かることと、追加確認が必要なこと
1. 一時的な操作と継続する実装エラーを分ける
戻る操作の直後だけ発生した場合は、エラー画面や途中の認証URLを繰り返し開かず、サービスの通常の入口からやり直します。毎回同じ箇所で再現する場合は、失敗した要求のURL・メソッド・遷移元をアプリ担当者が調べます。
2. 認証ポリシーやハイブリッド構成を原因と決めない
このコードだけで条件付きアクセスやExchangeハイブリッドの不備を断定できません。組織アカウントでは、管理者にエラーIDと再現手順を渡して該当するアプリと認証処理を確認してもらいます。
3. サイト許可やCookie変更は一括の修復手段ではない
Cookie・キャッシュ・拡張機能の確認はブラウザー依存かを調べるための比較です。信頼済みサイトの未設定や通信の遮断を、POSTがGETになる原因だと決めつけないでください。
利用者が最初に行う確認と、管理者へ渡す情報
- サービスの公式入口を開き直し、途中の認証ページのブックマークや戻る操作を使わず再試行する。
- 別のブラウザープロファイル等で同じ入口を試し、同じ場所で再現するか記録する。
- 一つのブラウザーだけの場合は、拡張機能や該当サイトデータを個別に確認する。一括削除やセキュリティ機能の停止から始めない。
- 組織アカウントや自作アプリなら、エラー全文・時刻・アプリ名・直前の操作・Request/Trace ID・Correlation IDを担当者へ渡す。
利用者向けのブラウザー確認はOutlookでAADSTS900561が出る時の手順で説明しています。ここからはアプリの要求先とメソッドを調べる内容です。
認証フローのどの区間でGET／POSTを使うか
公式のOAuth 2.0認可コードフローでは、認可要求とトークン交換、アプリへの戻り先は別の区間です。GETを見つけたという理由だけで全区間をPOSTへ変更しません。
| 区間 | 確認する仕様 |
|---|---|
| /authorizeへの認可要求 | 公式例はURLのクエリーパラメーターを使う |
| /tokenへの認可コード交換 | POST、application/x-www-form-urlencoded、grant_type=authorization_codeなどを確認 |
| アプリのredirect_uriへの戻り | response_mode=queryならGET、form_postならPOST。アプリの受け側と一致させる |
登録したredirect_uriと実際の戻り先が一致するか、受け側がそのresponse_modeを処理できるかを確認します。Microsoftは低水準のHTTP要求を手書きするより、サポートされる認証ライブラリの利用を推奨しています。
自作アプリ：秘密情報をブラウザーへ埋めずに確認する
ブラウザーで動くJavaScriptへclient_secretを埋めてclient_credentialsを実行する方法は使いません。公式のクライアント資格情報フローはアプリ自身の資格情報を使うため、それをWebページや公開ソースへ置かないよう求めています。
| 確認項目 | 修正の方向 |
|---|---|
| ユーザーのサインインか、アプリ単独の処理か | 認可コードフローとclient_credentialsを混ぜない |
| client_credentialsのトークン要求 | サーバー側でPOST・フォーム形式。scopeは対象リソースの識別子に/.defaultを付ける |
| SPAでユーザーを認証 | ブラウザーに秘密を置かず、対応ライブラリと認可コード＋PKCEの仕様を確認 |
| POSTに変更した後 | AADSTS900561が消えても権限・scope・資格情報の別エラーは別途確認 |
本番トークンをコンソールへ出力して確認する必要はありません。要求先、メソッド、grant_type、Content-Typeと、秘密を伏せたエラー情報を比較します。
ネットワーク観点での追加対策
1. プロキシやVPNの影響確認
企業ネットワークやVPNを利用している場合は、利用を許可された環境で再現条件を比較し、アプリ担当者とネットワーク管理者へ結果を渡します。特定の回線だけで失敗しても、プロキシがPOSTをGETへ変換しているとはエラー文だけで判断できません。組織の接続方針を回避する変更は行わず、実際のログで確認します。
2. EdgeのNetworkで失敗した要求を確認
- 開発者ツールの［Network］を開いてから、サービスの通常の入口で再現する。
- 要求一覧で失敗した行を選び、［Headers］のRequest URL・Request Method・状態コードを確認する。
- /authorize、/token、自分のcallbackなど、どの先がGET／POSTを受け取ったかを比較する。
- 必要なログを共有する場合は、Export HAR (sanitized)を選び、内容を確認して担当者の指定した経路で渡す。
Edge DevToolsの公式Network資料では、sanitized HARはCookie・Set-Cookie・Authorization等の機密ヘッダーを除外します。ただしURLや本文まで秘密がないと保証するものではないため、コード・トークン・個人情報が含まれていないか共有前に確認します。
調査の結果で次の担当を選ぶ
- 通常の入口からは成功する：途中の認証URLや戻る操作の利用を避けて継続する。
- 一つの環境でのみ失敗する：ブラウザー・拡張機能・許可された回線の比較結果を残す。
- 自作アプリで再現する：失敗したURLとメソッド、フロー、戻り先の受け側を開発者が照合する。
- 既製サービスで毎回再現する：利用者が認証仕様を書き換えず、サービスの管理者・サポートへ記録を渡す。
製品名ではなく、再現条件を比較する
SafariやXbox、Exchangeハイブリッドで表示されたとしても、製品名だけから原因や修復方法は選べません。比較する場合は、同じサービス・同じアカウント・通常のサインイン入口を使い、変更した条件を一つずつ記録します。
一般利用者向けのブラウザー手順と、自作アプリのHTTP要求の修正は担当が違います。プライベートリレー、条件付きアクセス、保護機能を一括で止めれば解決するという扱いはせず、取得した要求情報に基づいて必要な項目を調べます。
さらに深堀りするための補足
管理者は該当アプリと時刻を照合する
管理者へ渡した時刻・エラーID・アプリ名を使い、利用可能な認証ログやアプリのログと照合します。ログの有無は対象サービスや権限によって異なるため、ポータルで必ず自動修復できるとは考えません。
ログとエラーIDの活用
エラーが発生した際のRequest IdやCorrelation Id、発生時刻を控えておくことで、MicrosoftサポートやIT管理者に問い合わせる際に迅速な対応が可能となります。特に企業アカウントの場合、サポートに依頼する際はこれらのIDと共に、問題再現手順を詳細に伝えるとスムーズです。
外部連携アプリの確認
SharePointやTeams、外部サービスと連携するアプリでは、エラーが生じた要求先と実際のredirect_uriを確認します。アプリ登録の値を確認する場合も、単に古い値だからGETになったと推測せず、認可フローと受け側の仕様に照らして修正してください。
まとめ
AADSTS900561の「only accepts POST」「Received a GET」は、該当する要求先とメソッドの不一致を示します。戻る操作後だけの表示は通常の入口から再試行し、継続する場合はURL・メソッド・時刻とエラーIDを記録します。アプリ開発者は/authorize・/token・callbackを分けて仕様を確認し、ブラウザーへclient_secretを置かないでください。Cookieやサイト許可の一括変更を原因未確認のまま行うより、再現した区間を絞って担当者と調べます。
コメント