ログイン時に「AADSTS50011」「redirect URI does not match」と表示されたら、まずエラー画面に示されたURIをそのまま登録するのではなく、アプリが送った値とMicrosoft Entraのアプリ登録に保存された値を並べて比較します。エラーの意味は、認証要求に含まれるredirect URIが、そのアプリ登録のredirect URIと一致しないことです。ただし、要求側の設定が誤っている場合もあります。アプリの実際のcallback先が正しいと確認できるまでは、Entra側へURIを追加しないでください。
この記事では、利用者が管理者へ渡せる差分表を作り、変更する場所を特定するところまでを扱います。特定のテナントやアプリ登録を操作した実測手順ではありません。アプリのコード、設定、テナントには接続していないため、どのURIが正しいかを一般論だけで決めることはできません。
目次
最初に保全する情報
エラー画面から、AADSTSコード、エラー全文、表示されたredirect URI、Application (client) ID、発生時刻、Trace ID、Correlation IDを記録します。これらにはテナントやアプリを識別する値が含まれるため、公開の問い合わせ欄やSNSへ貼らず、組織の管理者またはアプリ保守担当へ必要な範囲だけ共有してください。エラー説明には、URIが不一致であることを示す値が含まれる場合があります。コード番号だけで原因を決めず、現行のMicrosoftエラー情報とエラー全文を併用します。Microsoftはエラーコードや文言を変更する場合があると説明しているため、古い画面キャプチャの説明を現在の仕様として固定しないことが重要です。
記録用の最低限の項目は次のとおりです。
・発生日時とタイムゾーン
・エラー画面の全文（秘密情報を含む場合は安全な経路で共有）
・requested redirect URI（省略・URLデコード・大文字小文字の変換をしない）
・Application IDと対象テナント
・利用者が実行した操作と、発生環境（本番、検証、ローカル）
・可能ならアプリログ側の認証要求と、失敗したリクエストのTrace ID / Correlation ID
URLを写す際、ブラウザーのアドレス欄にある認証要求全体を無造作にコピーしないでください。認証要求にはstate、nonce、コード、セッション識別子などが含まれることがあります。切り分けに必要なのは、通常はredirect_uriパラメーターとアプリを特定する情報です。トークン、認証コード、Cookie、client secretを共有しないでください。
まずOIDC / OAuthとSAMLを分ける
AADSTS50011のMicrosoftトラブルシューティング資料は、Microsoft Entra IDを使うOpenID Connect（OIDC）またはOAuth 2.0認証で、要求のredirect URIとアプリ登録のredirect URIが一致しない状況を説明しています。redirect URIは、認証後に認証サーバーから利用者が戻されるアプリ側の場所です。OAuth/OIDCでは要求パラメーターとして送られ、Entraはアプリ登録と照合します。
「reply URL」という用語はSAMLでも使われますが、設定画面の名称が似ていることだけを根拠に、OIDC/OAuthのredirect URIとSAMLのReply URLを同じ値・同じ登録場所として扱わないでください。まずアプリが実際にどのプロトコルでログインしているかを確認します。SAMLなら、サービスプロバイダー設定やSAMLの応答先を含む別の構成情報を担当者に確認し、AADSTS50011向けの手順をそのまま当てはめないでください。
複数の認証方式が同じサービスにある場合、利用者が見ているサインイン経路を確認します。Microsoftのredirect URIガイドは、OAuth 2.0 authorization code、implicit、OpenID Connect、SAML SSOなどで登録が関係する場合と、device codeやOn-Behalf-Ofなど登録を必要としない場合を区別しています。エラーが出たからといって、すべてのフローへ同じURIを登録すれば直るわけではありません。製品の認証方式が分からない場合は、ベンダーのEntra連携手順またはアプリ保守担当に確認します。
requested URIと登録値を一文字ずつ比較する
比較時は、URI全体を「scheme」「host」「port」「path」「query」に分けます。アプリ登録には似た値が複数存在し得るので、先頭から目視で読むだけでなく、各部分を別列にして差を記録します。
比較項目の例：
・scheme：https と http
・host：login.example.jp と app.example.jp
・port：443、8443など。localhost以外ではportの違いを無視しない
・path：/auth/callback と /signin-oidc
・pathの大文字小文字：/Callback と /callback
・末尾スラッシュ：/callback と /callback/
・query：アプリやアカウント種別の条件に合うか
・登録先platform：Web、SPA、Mobile and desktop等がアプリ形態と一致するか
Microsoftの現行ガイドではredirect URIのpathは大文字小文字を区別し、アプリ実行中のpathと一致させる必要があります。pathを含まないURIでは、response modeがqueryまたはfragmentの場合に応答で末尾スラッシュが付くことがあり、pathを含む場合は同様に追加されないと説明されています。ブラウザー上で同じサイトに見えるかどうかではなく、認証要求で実際に送信された文字列と登録値を比較してください。
一般にHTTPSが求められ、HTTPが認められる例外はlocalhost等のローカル開発用です。localhostのport照合には特別な扱いがありますが、この例外を本番ホストへ広げてはいけません。localhost以外のportは照合対象として確認します。また、query parameterの可否は登録されたサインイン対象アカウント等の条件によって変わります。マルチテナント・個人Microsoftアカウントを含む場合は、URLのquery部分を自己判断で追加・削除せず、アプリの認証仕様を確認します。
このような差分表を作ると、担当者間で「どの値を、どちらの場所で直すか」を共有しやすくなります。
項目｜要求で送られた値｜アプリ登録の候補値｜一致
scheme｜https｜https｜一致
host｜login.example.jp｜login.example.jp｜一致
port｜443｜443｜一致
path｜/signin-oidc｜/signin-oidc/｜不一致候補
pathの大小文字｜/Callback｜/callback｜不一致候補
platform｜Webアプリ｜SPA登録｜要確認
上の値は比較方法を示す仮例であり、実在サービスや推奨callback URIを示しません。エラー画面に表示されたURIは比較材料です。適切な値はアプリ固有の設定・ベンダー資料・稼働中の認証要求から確定します。
変更する担当と場所を決める
requested URIがアプリの意図したcallback先であり、アプリ登録にだけ欠けていると、アプリ担当と管理者が確認できた場合は、アプリ登録のAuthenticationにある正しいplatform構成へ追加する対応が候補になります。Microsoftのトラブルシューティング資料も、該当アプリ登録をApplication IDで特定し、AuthenticationのPlatform configurationsを確認する流れを案内しています。組織の承認手順に従い、権限のある管理者が変更してください。変更を提案する側が権限を持たない場合、管理者の代わりに別のURIを推測して登録しないでください。
逆に、要求に含まれるURIが誤った環境、誤ったホスト名、古いcallback path、誤ったアプリ設定から出ているなら、Entra登録にそれを追加するのではなく、アプリのコード・環境変数・認証ライブラリ設定・ベンダー側構成を直す必要があります。Microsoftの資料も、要求から送られたURIが本来の値ではない場合、アプリのコードまたは構成を更新するよう明記しています。これは誤ったredirect先を許可リストへ入れて一時的にエラーだけ消すことを防ぐ重要な判断点です。
アプリがWebかSPAか、またはモバイル・デスクトップかで、登録すべきplatformが異なります。サーバー側で主な処理を行う従来型Webアプリと、ブラウザーで動くSPAを同じ種類として扱わないでください。アプリの作りを判断できない場合は、使用フレームワークだけで断定せず、認証フローとアプリの公式セットアップ手順を確認します。Platformの選択はredirect URIの比較と同時に確認し、URI文字列が一致しているように見えるのにエラーが残る場合も、構成種別が適切かを担当者へ確認します。
Microsoftはredirect URIをApplication objectに追加し、service principalへ直接追加しないよう案内しています。通常のアプリ登録画面で対象アプリを特定し、所有権・テナント・変更権限を確認してから、承認された変更を行ってください。管理者権限がない利用者は、値の登録を自分で試すのではなく、必要な情報を添えて登録管理者へ依頼します。
変更依頼に含める安全な情報
アプリ保守担当・Entra管理者へ依頼するときは、次の形式でまとめます。
-
対象アプリ名とApplication ID
-
対象テナント、発生環境、本番か検証か
-
OIDC/OAuthかSAMLか（確認済みか、未確認かも記載）
-
エラー画面のrequested URI
-
アプリ側の公式設定または稼働構成で確認した正しいcallback URI
-
App registrationのplatformと登録URIの現在値
-
両者の差分（scheme、host、port、path、大小文字、slash、query）
-
どちらを修正すべきかの根拠と承認者
-
変更後に再試行する担当者と時間帯
依頼文の例：
「Application IDが末尾****のアプリで、2026-10-15のログイン時にAADSTS50011が発生しました。エラーに表示されたrequested URIと、アプリ設定で確認したcallback URIを添付の差分表に分けています。認証方式はOIDCです。requested URIが意図した本番callbackか、EntraのApp registrationの正しいplatform構成に登録済みかを確認してください。もしrequested URIがアプリ側の誤設定なら、Entraへ追加せずアプリ設定の修正要否をご判断ください。変更は通常の承認手順と担当権限の下でお願いします。」
これは依頼の書き方の例であり、Application IDをメール等へ無条件に記載するよう勧めるものではありません。組織のチケットシステムなど、適切なアクセス制御のある経路を使います。エラー全文を添付する場合は、認証コード、token、Cookie、secret、stateなどが混入していないか確認します。
修正後の再試行と切り分け
設定変更を行った場合、変更者・変更対象・変更値・変更前後・承認記録を残します。MicrosoftのAADSTS50011トラブルシューティング資料は、変更の反映まで3〜5分待ってから要求を再送する手順を案内しています。これはMicrosoft資料の目安であり、すべてのアプリや環境で同じ時間に反映される保証ではありません。反映後も再試行して同じエラーが出る場合、同じURIを何度も追加せず、最新のエラー全文・Trace ID・Correlation IDと現在の登録値を再比較します。
再試行時は、同じ利用者、同じテナント、同じ環境、同じアプリID、同じログイン経路かを確認します。ブラウザーやアプリのキャッシュが結果に影響する状況では、Microsoft資料が示すInPrivate等の確認方法も候補ですが、認証方式やセッションを変えて別の成功経路を試すだけで、原因が解決したとは結論づけないでください。再現しなくなった場合でも、URIの修正が正しい環境・platformへ適用され、開発・検証・本番の各環境が分離されているかを確認してから作業を閉じます。
まだ解消しないときは、1) requested URIが更新後も同じか、2) Application IDとテナントが対象と一致するか、3) 同じアプリ登録の正しいplatformにURIがあるか、4) pathの大文字小文字・末尾slash・port・queryが一致するか、5) アプリ側のcallback設定が期待通りか、6) 変更が別の登録や別環境に適用されていないかを順に確認します。Entraのエラーコード・エラー文は変更されることがあるため、画面の情報をその時点のMicrosoft資料と照合します。原因が一致しないときは、管理者またはアプリ提供元へ、秘密情報を除いた再現時刻とTrace / Correlation IDを添えて問い合わせます。
よくある誤修正
・エラーに表示されたURIを確認せず、そのまま本番登録へ追加する。requested URIそのものが誤っていれば、誤った戻り先を許可することになります。
・ホスト名だけを合わせてpathや大文字小文字を無視する。Microsoftの仕様上、pathの大文字小文字は照合に影響します。
・localhostでportが無視される例を本番URLへ適用する。portの例外はlocalhostに限られます。
・WebとSPAのplatformを取り違えたままURIだけを追加する。アプリ形態に沿ったplatform構成か確認します。
・OIDC/OAuthとSAMLの設定を同じものとして扱う。ログイン経路を特定し、対応する設定画面とベンダーの手順を使います。
・エラー全文を公開チャットや第三者へ貼る。trace情報以外に認証要求の機密値が入っていないか確認します。
・開発用のcallbackを本番登録に混ぜる。環境別登録を使うなど、不要なredirect先を本番へ公開しない設計にします。
・ワイルドカードで不一致を回避する。Microsoftはセキュリティ上の理由からabsolute URIを推奨し、wildcard利用にも制限を説明しています。
修正の完了条件は、ログインが一度通ることだけではありません。認証要求が意図したアプリと環境から送られ、正しいApplication IDとテナントを参照し、公式に確認したcallback URIが適切なplatformへ登録され、不要な開発用URIや広すぎるwildcardを追加していないことまで確認します。確認できない条件が残る場合は、「直ったはず」として終えず、未確認項目と担当者を残します。
30秒で確認するチェックリスト
□ エラー全文、時刻、Application ID、requested redirect URIを安全に記録した
□ OIDC/OAuthとSAMLのどちらか確認した
□ requested URIがアプリの意図したcallbackである根拠を確認した
□ Entraの登録先Application ID・テナント・platformを確認した
□ scheme、host、port、path、pathの大文字小文字、slash、queryを比較した
□ URIが誤っている側を特定し、権限のある担当者を決めた
□ 承認された一方の設定だけを修正し、変更内容を記録した
□ Microsoft資料の目安時間を考慮して再試行し、最新エラーを再確認した
□ token、認証コード、Cookie、secretを不用意に共有していない
ここまでできれば、単に「redirect URIを追加する」ではなく、どの設定を誰が直すべきかを説明できます。アプリ設定が誤っているならEntra登録へ追加しない、正しいURIがアプリ側で確定し登録側に欠ける場合だけ管理者へ追加を依頼する、という二択を判断できる状態が読了の目標です。
公式資料
Microsoft Learn｜AADSTS50011 redirect URI mismatch troubleshooting
確認日：2026-10-15
Microsoft Learn｜Redirect URI (reply URL) outline and restrictions
https://learn.microsoft.com/en-us/entra/identity-platform/reply-url（新しいタブで開く）
確認日：2026-10-15
Microsoft Learn｜Microsoft Entra authentication and authorization error codes
https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes（新しいタブで開く）
確認日：2026-10-15