リダイレクト URI (応答 URL) の概要と制限
ユーザーをサインインさせるには、アプリケーション側でリダイレクト URI をパラメーターとして指定して、Microsoft Entra 承認エンドポイントにログイン要求を送信する必要があります。 リダイレクト URI とは、Microsoft Entra 認証サーバーからの認証コードとアクセス トークンが目的の受信者にのみ送信されるよう保証する、重要なセキュリティ機能です。 この記事では、Microsoft ID プラットフォームにおけるリダイレクト URI の機能と制限について説明します。
リダイレクト URI とは
リダイレクト URI (応答 URL) とは、ユーザーが正常に承認されアクセス トークンを付与された後で、Microsoft Entra 認証サーバーがユーザーを誘導する場所です。 ユーザーをサインインさせるには、アプリケーション側でリダイレクト URI をパラメーターとして指定して、ログイン要求を送信する必要があります。これにより、ユーザーが正常にサインインした後、認証サーバーがユーザーをリダイレクトし、ログイン要求で指定されたリダイレクト URI にアクセス トークンを発行します。
リダイレクト URI をアプリ登録に追加する必要がある理由
セキュリティ上の理由から、認証サーバーは、アプリ登録に追加されていない URI に対してユーザーのリダイレクトまたはトークンの送信を行いません。 Microsoft Entra ログイン サーバーは、アプリ登録に追加されたリダイレクト URI に対してのみ、ユーザーのリダイレクトおよびトークンの送信を行います。 ログイン要求で指定されたリダイレクト URI が、アプリケーションに追加されたリダイレクト URI と一致しない場合、AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application などのエラー メッセージが表示されます。
エラー コードについて詳しくは、「Microsoft Entra 認証と承認エラー コードについて」を参照してください。
リダイレクト URI をアプリ登録に追加する必要の有無
リダイレクト URI をアプリ登録に追加する必要があるかどうかは、アプリケーションで使用する認証プロトコルによって異なります。 アプリケーションで次の認証プロトコルが使用されている場合は、適切なリダイレクト URI をアプリ登録に追加する必要があります。
- OAuth 2.0 承認コード フロー
- OAuth 2.0 クライアント認証情報フロー
- OAuth 2.0 暗黙的な許可フロー
- OpenID Connect
- シングル サインオンの SAML プロトコル
アプリケーションで次の認証プロトコルまたは機能が使用されている場合は、リダイレクト URI をアプリ登録に追加する必要はありません。
- ネイティブ認証
- OAuth 2.0 デバイス コード フロー
- OAuth 2.0 On-Behalf-Of フロー
- OAuth 2.0 リソース所有者パスワード認証情報フロー
- Windows 統合認証フロー
- シングル サインオンに使用される SAML 2.0 ID プロバイダー (IdP)
リダイレクト URI を追加する必要があるプラットフォーム
構築するアプリケーションのアプリ登録に 1 つ以上のリダイレクト URI が含まれる場合は、パブリック クライアント フロー構成を有効にする必要があります。 次の表は、アプリケーションの動作ベースとするプラットフォームにより、追加する必要がある、または追加してはならないリダイレクト URI の種類に関するガイダンスです。
Web アプリケーションのリダイレクト URI の構成
| アプリケーションの種類 | 一般的な言語/フレームワーク | アプリ登録にリダイレクト URI を追加する必要があるプラットフォーム |
|---|---|---|
| ほとんどのアプリケーション ロジックがサーバー上で実行される従来の Web アプリケーション | Node.js、Web、ASP.NET、Python、Java、ASP.NET Core、PHP、Ruby、Blazor Server | Web |
| 主に Web API を使って Web サーバーと通信する、Web ブラウザーでほとんどのユーザー インターフェイス ロジックが実行されるシングルページ アプリケーション | JavaScript、Angular、React、Blazor WebAssembly、Vue.js | シングルページ アプリケーション (SPA) |
モバイルとデスクトップ アプリケーションのリダイレクト URI の構成
| アプリケーションの種類 | 一般的な言語/フレームワーク | アプリ登録にリダイレクト URI を追加する必要があるプラットフォーム |
|---|---|---|
| この表の下で示すシナリオを除く iOS または macOS アプリ | Swift、Objective-C、Xamarin | IOS/macOS |
| Android アプリ | Java、Kotlin、Xamarin | Android |
| モバイル デバイスまたはデスクトップ マシンでネイティブに実行されるアプリ | Node.js electron、Windows デスクトップ、UWP、React Native、Xamarin、Android、iOS/macOS | モバイル アプリケーションおよびデスクトップ アプリケーション |
次のいずれかの方法を使用して iOS アプリをビルドしている場合は、モバイルおよびデスクトップ アプリケーションのプラットフォームを使用してリダイレクト URI を追加します。
- レガシ SDK を使用する iOS アプリ (ADAL)
- オープンソース SDK を使用する iOS アプリ (AppAuth)
- サポートされていないクロスプラットフォーム技術を使用する iOS アプリ (Flutter)
- OAuth プロトコルを直接実装する iOS アプリ
- サポートされていないクロスプラットフォーム技術を使用する macOS アプリ (Electron)
リダイレクト URI を必要としないアプリケーション
| アプリケーションの種類 | 例/メモ | 関連付けられている OAuth フロー |
|---|---|---|
| キーボードがないデバイスで実行されているアプリケーション | スマート テレビ、IoT デバイス、またはプリンターで実行されているアプリケーション | デバイス コード フロー (詳細) |
| ユーザーを Entra でホストされているログイン Web サイトにリダイレクトし Entra に安全な方法でユーザー パスワードを処理させる代わりに、ユーザーが直接入力するパスワードを処理するアプリケーション。 | このタイプのフローは、認証コード フローなどの高セキュリティなフローほど安全でないため、それらを使用できない場合にのみ使用してください。 | リソース所有者のパスワード認証情報フロー (詳細情報) |
| Web アカウント マネージャーではなく Windows 統合認証フローを使って Windows ドメイン (AD または Azure AD 参加済み) に接続されている Windows またはコンピューター上で実行されているデスクトップまたはモバイル アプリケーション | ユーザーが Entra 認証情報を使って Windows PC システムにサインインした後で自動的にサインインさせるデスクトップまたはモバイル アプリケーション | Windows 統合認証フロー (詳細情報) |
Microsoft Entra アプリケーション向けリダイレクト URI に関する制限
Microsoft Entra アプリケーション モデルでは、リダイレクト URI に対して以下の制限が指定されています。
一部の localhost リダイレクト URI を除き、リダイレクト URI はスキーム
httpsで始まっている必要があります。リダイレクト URI では大文字と小文字が区別されるため、実行中のアプリケーションの URL パスの大文字と小文字が一致する必要があります。
例:
- アプリケーションがそのパスの一部として
.../abc/response-oidcを含む場合は、リダイレクト URI 内に.../ABC/response-oidcを指定しないでください。 Web ブラウザーは大文字と小文字を区別してパスを処理するため、.../abc/response-oidcに関連付けられている cookie は、大文字と小文字が一致しない.../ABC/response-oidcURL にリダイレクトされた場合に除外される可能性があります。
- アプリケーションがそのパスの一部として
パス セグメントで構成されていないリダイレクト URI については、応答の末尾にスラッシュ ('
/') を付加して返されます。 これは、応答モードがqueryまたはfragmentの場合にのみ適用されます。例:
https://contoso.comはhttps://contoso.com/として返されますhttp://localhost:7071はhttp://localhost:7071/として返されます
パス セグメントを含むリダイレクト URI については、応答の末尾にスラッシュは付加されません。
例:
https://contoso.com/abcはhttps://contoso.com/abcとして返されますhttps://contoso.com/abc/response-oidcはhttps://contoso.com/abc/response-oidcとして返されます
リダイレクト URI では、特殊文字 (
! $ ' ( ) , ;) はサポートされませんリダイレクト URI では、国際化ドメイン名はサポートされません
リダイレクト URI の最大数と URI の長さ
セキュリティ上の理由から、最大数のリダイレクト URI を生成することはできません。 シナリオ上、許可される最大制限を超えるリダイレクト URI が必要な場合は、解決方法として次の状態パラメーター アプローチを検討してください。 次の表に、Microsoft ID プラットフォームでアプリ登録に追加できるリダイレクト URI の最大数を示します。
| サインイン中のアカウント | リダイレクト URI の最大数 | 説明 |
|---|---|---|
| いずれかの組織の Microsoft Entra テナント内の Microsoft の職場または教育機関アカウント | 256 | アプリケーション マニフェスト内の signInAudience フィールドは AzureADMyOrg か AzureADMultipleOrgs に設定されます |
| Microsoft の個人用アカウント、職場用アカウント、教育機関用アカウント | 100 | アプリケーション マニフェスト内の signInAudience フィールドは AzureADandPersonalMicrosoftAccount に設定されます |
アプリの登録に追加するリダイレクト URI 1 個につき最大 256 文字を使用できます。
アプリケーション オブジェクトとサービス プリンシパル オブジェクトにおけるリダイレクト URI の違い
- アプリケーション オブジェクトについてのみ、リダイレクト URI を常に追加してください。
- サービス プリンシパルにはリダイレクト URI 値を追加しないでください。これらの値は、サービス プリンシパル オブジェクトがアプリケーション オブジェクトと同期するときに削除される可能性があります。 こうした削除は、2 つのオブジェクト間の同期をトリガーする更新操作に伴い発生する可能性があります。
リダイレクト URI におけるクエリ パラメーターのサポート
アプリケーションのリダイレクト URI にクエリ パラメーターの使用が許可されるのは、職場または教育機関アカウントをもつユーザーのみがサインインするアプリケーションのみです。
Outlook.com (Hotmail)、Messenger、OneDrive、MSN、Xbox Live、Microsoft 365 など、個人用 Microsoft アカウントを使ってユーザーをサインインさせるように構成されたアプリ登録では、リダイレクト URI にクエリ パラメーターを使用することはできません。
| アプリ登録のサインイン対象ユーザー | リダイレクト URI におけるクエリ パラメーターのサポート |
|---|---|
| この組織ディレクトリに含まれるアカウントのみ (Contoso のみ - シングル テナント) | 
|
| 任意の組織ディレクトリに含まれるアカウント(任意の Microsoft Entra ディレクトリ - マルチテナント) |
|
| 任意の組織ディレクトリ (Microsoft Entra ディレクトリ - マルチテナント) に含まれるアカウント、および個人用 Microsoft アカウント (Skype、Xbox など) | 
|
| 個人用 Microsoft アカウントのみ |
|
サポートされているスキーム
HTTPS: HTTPS スキーム (https://) は、すべての HTTP ベースのリダイレクト URI でサポートされています。
HTTP: HTTP スキーム (http://) は localhost URI でのみサポートされます。HTTP スキームは、アクティブなローカル アプリケーションの開発およびテスト中にのみ使用すること。
| リダイレクト URI の例 | 有効/無効 |
|---|---|
https://contoso.com |
有効 |
https://contoso.com/abc/response-oidc |
有効 |
https://localhost |
有効 |
http://contoso.com/abc/response-oidc |
無効 |
http://localhost |
有効 |
http://localhost/abc |
有効 |
Localhost の例外
RFC 8252 のセクション 8.3 と 7.3 に基づいて、Loopback および Localhost タイプのリダイレクト URI には、次の 2 つの特別な考慮事項があります。
- リダイレクトがデバイスから切り離されることはないため、
httpURI スキームが許容されます。 そのため、これら両方の URI を使用できます。http://localhost/myApphttps://localhost/myApp
- ネイティブ アプリケーションでは一時的なポート範囲が頻繁に必要とされるため、リダイレクト URI の照合においては、ポート コンポーネント (
:5001や:443など) は無視されます。 結果として、これらの URI はすべて同等と見なされます。http://localhost/MyApphttp://localhost:1234/MyApphttp://localhost:5000/MyApphttp://localhost:8080/MyApp
開発の観点から見ると、これは以下の点を意味します。
ポートのみが異なる複数のリダイレクト URI を登録しないでください。 ログイン サーバーは、無作為に 1 つを選び、そのリダイレクト URI に関連付けられている動作を使います (たとえば、
web、native、またはspa型のリダイレクト)。これは、同じアプリケーション登録内で異なる認証フロー (認証コードの付与と暗黙のフローなど) を使用する場合に特に重要です。 各リダイレクト URI に適切な応答動作を関連付けるには、ログイン サーバー側でリダイレクト URI を区別できる必要があり、ポートのみが異なる場合はそれをできません。
複数のリダイレクト URI を localhost に登録して開発中にさまざまなフローをテストする場合は、URI のパスコンポーネントを使用してそれらを区別します。 たとえば、
http://localhost/MyWebAppはhttp://localhost/MyNativeAppと一致しません。IPv6 ループバック アドレス (
[::1]) は、現在サポートされていません。
127.0.0.1 以上の localhost が推奨されています
ファイアウォールの正しくない構成や、ネットワーク インターフェイスの名前変更によって、アプリが動作不能になるのを防ぐには、localhost ではなく IP リテラル ループバック アドレス 127.0.0.1 をリダイレクト URI に使用します。 たとえば、https://127.0.0.1のように入力します。
ただし、Azure portal の [リダイレクト URI] テキスト ボックスを使って、http スキームを使うループバックベースのリダイレクト URI を追加することはできません。
127.0.0.1 ループバック アドレスで http スキームを使用するリダイレクト URI を追加するには、現在のところアプリケーション マニフェストで replyUrlsWithType 属性を変更する必要があります。
リダイレクト URI のワイルドカードに関する制限事項
https://*.contoso.com のようなワイルドカード URI は、便利に思えることもありますが、セキュリティへの影響のため、回避する必要があります。 OAuth 2.0 仕様 (RFC 6749 のセクション 3.1.2) によると、リダイレクト エンドポイント URI は絶対値 URI にする必要があります。 もし構成されたワイルドカード URI がリダイレクト URI と一致すると、リダイレクト URI 内のクエリ文字列とフラグメントが削除されます。
ワイルドカード URI は、現在、個人用 Microsoft アカウントと職場または教育機関のアカウントをサインインさせるように構成されているアプリの登録ではサポートされていません。 ただし、組織の Microsoft Entra テナント内で職場または教育機関のアカウントのみをサインインさせるように構成されているアプリの場合は、ワイルドカード URI が許可されています。
職場または教育機関のアカウントでサインインするアプリの登録に、ワイルドカードを含むリダイレクト URI を追加するには、Azure portal の [アプリの登録] で、アプリケーション マニフェスト エディターを使用します。 マニフェスト エディターを使用して、ワイルドカードを含むリダイレクト URI を設定することも可能ですが、RFC 6749 のセクション 3.1.2 に従うことを強くお勧めします。 絶対値 URI のみを使用するようにしてください。
シナリオ上、許可される最大限度を超えるリダイレクト URI が必要な場合は、ワイルドカードを含むリダイレクト URI を追加する代わりに、次の状態パラメーター アプローチを検討してください。
状態パラメーターの使用
お使いのシナリオによりいくつかのサブドメインをもつ必要がある場合は、認証成功時にユーザーを開始時と同じページにリダイレクトしますが、状態パラメーターを使用すると便利な場合があります。
このアプローチでは:
- 認証エンドポイントから受け取ったセキュリティ トークンを処理する「共有」リダイレクト URI をアプリケーション別に作成します。
- アプリケーション側から、状態パラメーターの一部として、アプリケーション固有のパラメーター (ユーザーの起点になったサブドメイン URL や、ブランディングなどの任意の情報) を送信できます。 状態パラメーターの使用時、CSRF 対策をしてください。仕様は RFC 6749 のセクション 10.12 にあります。
- アプリケーション固有のパラメーターには、アプリケーション側でのユーザー向けの適切なエクスペリエンスのレンダリングのため、つまりアプリケーションの適切な状態を構築するために必要な情報がすべて含まれます。 Microsoft Entra 承認エンドポイントにより状態パラメーターから HTML が取り除かれるため、このパラメーターで HTML コンテンツを渡そうとしないこと。
- Microsoft Entra ID は、共有リダイレクト URI に応答を送信するとき、状態パラメーターをアプリケーションに返します。
- その後、アプリケーションは状態パラメーターの値を利用して、ユーザーを次にどの URL に誘導するかを決定できます。 CSRF 対策の有効性を確認してください。
警告
このアプローチでは、セキュリティを侵害されたクライアントが状態パラメーターで送信された追加パラメーターを変更し、ユーザーを別の URL にリダイレクトできてしまいます。これは RFC 6819 にも説明されているオープン リダイレクターの脅威です。 そのため、クライアントは状態を暗号化するか、もしくはリダイレクト URI に含まれるドメイン名をトークンと照合するなど、何か他の手段で状態を検証することによって、これらのパラメーターを保護する必要があります。
次のステップ
アプリ登録におけるアプリケーション マニフェストについて学習します。