リダイレクト 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 ごとに最大 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 で "のみ" サポートされ、アクティブなローカル アプリケーションの開発およびテスト中にのみ使用する必要があります。
| リダイレクト 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 が推奨されています
ファイアウォールの正しくない構成や、ネットワーク インターフェイスの名前変更によって、アプリが動作不能になるのを防ぐには、リダイレクト URI で localhost ではなく IP リテラル ループバック アドレス 127.0.0.1 を使います。 たとえば、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 仕様 (セクション 3.1.2 of RFC 6749) によると、リダイレクト エンドポイント 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 に含まれるドメイン名をトークンと比べて検証するなど、何か他の手段で状態を検証することによって、これらのパラメーターを保護する必要があります。
次のステップ
アプリの登録のアプリケーション マニフェストについて学習します。