公開したWebサービスだけMicrosoftログインに失敗し、画面に「AADSTS50011」と表示される場合は、認証要求で送信されたリダイレクトURIと、Microsoft Entra IDのアプリ登録に許可されているリダイレクトURIが一致していません。
対処では、エラー画面に表示された「アプリケーションID」と「リダイレクトURI」を正確に記録することが重要です。そのうえで、正しい本番URLが未登録ならMicrosoft Entra IDへ追加し、localhostや旧ドメインなどの誤ったURLをアプリが送信しているなら、アプリ側の設定を修正します。
エラーに表示されたURLを確認せず、そのまま許可済みURIへ追加するのは避けてください。
AADSTS50011が示していること
AADSTS50011は、OAuth 2.0またはOpenID ConnectによるMicrosoftログインで、次の2つが一致しないときに発生するエラーです。
- Webサービスが認証要求で送信したリダイレクトURI
- Microsoft Entra IDのアプリ登録に設定されたリダイレクトURI
リダイレクトURIとは、Microsoftでの認証が完了したあと、ユーザーと認証結果をWebサービスへ戻すためのURLです。Microsoft Entra IDは、認証要求で指定されたURIがアプリ登録の許可済みURIに含まれているかを確認し、一致しなければ処理を停止します。([Microsoft Learn][1])
たとえば、Microsoft Entra IDに次のURIが登録されているとします。
https://service.example.jp/auth/callbackところが、公開したWebサービスが次のURIを送信していれば、AADSTS50011が発生します。
http://localhost:3000/auth/callbackこの例では、本番サービスからlocalhostへ戻るのは意図した動作ではありません。そのため、localhostを本番用のアプリ登録へ追加するのではなく、Webサービスの環境変数や認証設定を修正するのが適切です。
最初にエラー画面から記録する項目
設定を変更する前に、AADSTS50011のエラー画面から次の2項目を記録します。
| 記録する項目 | 確認する内容 |
|---|---|
| アプリケーションID | エラー対象となっているアプリ登録のID |
| リダイレクトURI | 実際の認証要求で送信された戻り先URL |
エラーメッセージは、概ね次のような内容です。
AADSTS50011:
The redirect URI 'https://service.example.jp/auth/callback'
specified in the request does not match the redirect URIs
configured for the application 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'.これは説明用の例です。実際には、エラー画面に表示された値を省略せず記録してください。
特に重要なのは、アプリケーションIDです。Microsoft Entra IDには似た表示名のアプリ登録を複数作成できるため、アプリ名だけを頼りにすると、開発用や旧環境用の別アプリを変更してしまう可能性があります。Microsoftの案内でも、エラーに表示されたアプリケーションIDを使用して対象のアプリ登録を特定する手順が示されています。([Microsoft Learn][1])
AADSTS50011を直す手順
エラーのアプリケーションIDで対象を特定する
アプリ登録を変更できる権限を持つアカウントで、Microsoft Entra管理センターまたはAzureポータルを開きます。
画面上では、次の順に進みます。
Microsoft Entra ID
→ App registrations
→ 対象のアプリ登録
→ Authentication対象のアプリは、表示名ではなく、エラー画面に記載されたアプリケーションIDで照合してください。Microsoft Learnでも、AADSTS50011のエラーからアプリケーションIDをコピーし、そのIDを使って「App registrations」から対象を開く手順が案内されています。([Microsoft Learn][1])
「Enterprise applications」ではなく、「App registrations」にあるアプリケーションオブジェクトを確認します。リダイレクトURIはアプリケーションオブジェクト側へ設定するもので、サービスプリンシパル側へ直接設定する運用は避ける必要があります。([Microsoft Learn][2])
Authenticationで登録済みURIを確認する
対象のアプリ登録を開いたら、「Authentication」の「Platform configurations」で、登録済みのリダイレクトURIを確認します。
プラットフォームは、アプリの構成に応じて異なります。
| アプリの構成 | 一般的なプラットフォーム |
|---|---|
| サーバー側で認証処理を行うWebアプリ | Web |
| ブラウザ上で動作するReactやVue.jsなどのSPA | Single-page application |
| デスクトップアプリやモバイルアプリ | Mobile and desktop applicationsなど |
Microsoft Learnでは、ASP.NET Core、Node.js、Python、Java、PHPなどの一般的なサーバー型Webアプリは「Web」、React、Angular、Vue.jsなどのSPAは「Single-page application」に登録する構成が示されています。([Microsoft Learn][2])
エラー画面に表示されたリダイレクトURIと、登録済みURIを見比べます。確認するときは、次の部分を省略せず比較してください。
httpとhttps- ドメイン名
- サブドメイン
- ポート番号
- URLのパス
- パスの大文字と小文字
- 末尾のスラッシュ
Microsoft Entra IDのリダイレクトURIは、本番のWebサービスでは原則としてHTTPSを使用します。また、URLパスの大文字と小文字は区別されます。たとえば、/auth/Callbackと/auth/callbackは同一の設定として扱わないよう注意が必要です。([Microsoft Learn][2])
登録側とアプリ側のどちらを直すか判断する
エラーに表示されたURIを確認したら、次の基準で対応を分けます。
| エラーに表示されたURI | 判断 | 対応 |
|---|---|---|
| 正しい本番用コールバックURL | アプリ登録への追加漏れ | Authenticationへ正確なURIを追加 |
| localhostや127.0.0.1 | 公開環境が開発用設定を使用している可能性 | アプリ側の環境変数や認証設定を修正 |
| 旧ドメイン | デプロイ後も古い設定が残っている可能性 | 本番設定を現在のドメインへ変更 |
| プレビュー用ドメイン | 公開URLの判定や環境設定が不適切な可能性 | 正式な公開URLを送信するよう修正 |
| 想定と異なるパス | コールバックパスの設定不一致 | 登録値またはアプリ設定を正しいパスへ統一 |
| 想定外のアプリケーションID | 別のクライアントIDを使用している可能性 | 本番環境のクライアントIDを確認 |
正しい本番URIが未登録の場合
エラーに表示されたURIが、実際に使用したい本番の戻り先であれば、「Authentication」の該当プラットフォームにそのURIを追加します。
例として、公開サービスの正しい戻り先が次のURLだったとします。
https://service.example.jp/api/auth/callback/microsoftWebサービスがこのURIを送信しており、Microsoft Entra ID側に登録されていないのであれば、同じ文字列をリダイレクトURIへ追加します。
登録時に、ドメイン部分だけを登録しても一致しません。
https://service.example.jp認証要求が具体的なコールバックパスを送信している場合は、そのパスを含めて登録する必要があります。認証要求で送信されたURIが、登録済みURIのいずれにも一致しない場合、Microsoft Entra IDはAADSTS50011を返します。([Microsoft Learn][1])
誤ったURIをアプリが送信している場合
エラーにlocalhost、旧ドメイン、検証環境のURLなどが表示されている場合は、そのURIを無条件でMicrosoft Entra IDへ追加しないでください。
確認する設定の例は次のとおりです。
REDIRECT_URI
CALLBACK_URL
BASE_URL
APP_URL
PUBLIC_URL
AUTH_URL実際の変数名は、利用しているフレームワークや認証ライブラリによって異なります。
また、リダイレクトURIをコードへ直接記述している場合は、開発用URLが残っていないか確認します。
// 説明用の例
const redirectUri =
process.env.MICROSOFT_REDIRECT_URI ??
"http://localhost:3000/auth/callback";このようなフォールバックがあると、本番環境で環境変数が設定されていない場合に、localhostが送信されることがあります。修正後は、設定ファイルを変更しただけで終わらせず、本番環境へ再デプロイされていることまで確認してください。
Microsoft Learnでも、アプリから送信されたリダイレクトURIが意図した値ではない場合は、アプリケーションのコードまたは構成を更新するよう案内されています。([Microsoft Learn][1])
保存後に反映を待って再試行する
リダイレクトURIを追加または変更したら、設定を保存します。
Microsoftの案内では、変更が反映されるまで3〜5分待ってから、ログイン要求を再実行する手順が示されています。([Microsoft Learn][1])
再試行は次の順で行います。
- Microsoft Entra ID側の設定が保存されていることを確認する
- 必要に応じてWebサービスを再デプロイまたは再起動する
- 3〜5分程度待つ
- 通常のブラウザでログインを試す
- 状況が変わらない場合はInPrivateやシークレットウィンドウで試す
InPrivateブラウズは、古いログインセッションやブラウザ側の状態を切り分けるための手段です。リダイレクトURIそのものが不一致のままであれば、InPrivateに切り替えてもAADSTS50011は解消しません。
公開したWebサービスだけ失敗する主な原因
ローカル環境ではMicrosoftログインできるのに、公開環境だけAADSTS50011になる場合は、開発環境と本番環境の差を確認します。
本番用のリダイレクトURIを登録していない
開発中は次のURIだけを登録していることがあります。
http://localhost:3000/auth/callback公開後は、たとえば次のURIが必要です。
https://service.example.jp/auth/callback本番URLが正しい戻り先であれば、対象のアプリ登録へ追加します。
本番環境がlocalhostを送信している
アプリ登録に本番URIを追加していても、認証要求がlocalhostを送信していれば失敗します。
この場合はMicrosoft Entra ID側ではなく、公開環境の設定を確認します。特に、デプロイ先へ環境変数を登録したあと、再デプロイや再起動が必要な構成では、古い値が使われ続けることがあります。
カスタムドメインへの変更が反映されていない
初期ドメインから独自ドメインへ切り替えたあと、どちらか一方だけが古いURLのまま残ることがあります。
登録済み:
https://project.example-host.com/auth/callback
実際の公開URL:
https://service.example.jp/auth/callback現在利用する正式なドメインを決め、アプリ登録とWebサービスの設定を統一します。
コールバックパスが一致していない
ドメインが同じでも、パスが異なれば一致しません。
登録済み:
https://service.example.jp/auth/callback
認証要求:
https://service.example.jp/api/auth/callback認証ライブラリによって既定のコールバックパスが決まっている場合があります。推測で設定せず、エラー画面に表示された実際のURIとアプリの設定を照合してください。
本番環境が別のアプリケーションIDを使用している
開発用と本番用でアプリ登録を分けている場合、本番環境のクライアントIDが開発用のままになっていることがあります。
この場合、正しい本番アプリのAuthentication画面を修正しても、エラーは解消しません。エラーに表示されたアプリケーションIDと、本番環境に設定したクライアントIDが一致しているか確認します。
リダイレクトURIを無条件で追加してはいけない理由
リダイレクトURIは、認証完了後の応答を返す重要な宛先です。Microsoft Entra IDが未登録のURIへのリダイレクトを拒否するのは、意図しないWebサイトへ認証結果を送らないためです。([Microsoft Learn][2])
そのため、次のようなURIを見つけても、理由を確認せず追加するのは避けます。
- 管理していないドメイン
- localhost
- 廃止した旧ドメイン
- 一時的なプレビューURL
- 誤字を含むURL
- HTTPの本番URL
- 用途を確認できないコールバックパス
Microsoft Learnでは、不要な開発環境のリダイレクトURIを本番アプリへ残さず、開発用と本番用でアプリ登録を分ける方法も示されています。([Microsoft Learn][2])
最低限、次のように分離すると管理しやすくなります。
| アプリ登録 | 登録するURIの例 |
|---|---|
| サービス名 Development | localhost、開発環境 |
| サービス名 Production | 正式な本番ドメインのみ |
修正してもAADSTS50011が続くときの確認項目
設定を変更しても解消しない場合は、再度表示されたエラーを確認してください。修正前と修正後で、アプリケーションIDやリダイレクトURIが変わっている可能性があります。
確認順は次のとおりです。
- エラーに表示されたアプリケーションIDは、修正したアプリ登録と一致しているか
- エラーに表示されたリダイレクトURIを、そのまま登録値と比較したか
- URIを正しいプラットフォームへ登録したか
- アプリ側の設定変更を本番へ再デプロイしたか
- 設定保存後、3〜5分待ったか
- 別ブラウザまたはInPrivateでも同じURIが表示されるか
特に、エラーのURIが修正前と変わっていない場合は、本番環境へ新しい設定が反映されていない可能性があります。
反対に、URIは正しくなったものの別の認証エラーへ変わった場合は、AADSTS50011の不一致自体は解消したと考えられます。その場合は、新しく表示されたエラーコードを基準に、クライアントシークレット、テナント、権限、同意設定などを別途確認します。
エラー情報を共有するときの注意点
管理者や開発担当者へ情報を共有する場合は、次の項目が分かると切り分けしやすくなります。
- エラーコード
- アプリケーションID
- エラーに表示されたリダイレクトURI
- 発生した環境
- 発生日時
- ローカル環境では成功するか
- 本番環境だけで発生するか
ただし、URLのクエリ文字列などに認証コードや秘密情報が含まれている場合は、そのまま公開しないでください。クライアントシークレット、アクセストークン、認証コード、Cookieなども、記事、チャット、公開リポジトリへ掲載しないようにします。
AADSTS50011は登録不足か誤送信かを切り分ける
AADSTS50011を解決する際は、最初からリダイレクトURIを追加するのではなく、次の順で確認します。
- エラー画面のアプリケーションIDとリダイレクトURIを記録する
- アプリケーションIDで正しいApp registrationを開く
- Authenticationの登録済みURIと照合する
- 正しい本番URIなら登録へ追加する
- localhostや旧ドメインならアプリ側の設定を直す
- 保存後3〜5分待ち、再度ログインする
判断の基準は、エラーに表示されたURIが、認証後に本当に戻したい本番URLかどうかです。
正しいURLならMicrosoft Entra IDへ登録し、誤ったURLならWebサービス側を修正します。この分岐を守れば、不要なリダイレクトURIを増やさず、安全にMicrosoftログインを復旧できます。
[1]: https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/app-integration/error-code-AADSTS50011-redirect-uri-mismatch “Error AADSTS50011 the redirect URI does not match the redirect URIs configured for the application | Microsoft Learn”
[2]: https://learn.microsoft.com/en-us/entra/identity-platform/reply-url “Redirect URI (reply URL) best practices and limitations – Microsoft identity platform | Microsoft Learn”
コメント