リダイレクト URI (応答 URL) に関する制約と制限
リダイレクト URI、すなわち応答 URL は、アプリが正しく承認され、認証コードまたはアクセス トークンが付与されると、承認サーバーがユーザーを送り出す場所です。 承認サーバーは、リダイレクト URI にこのコードまたはトークンを送信するため、アプリ登録プロセスの一環として正しい場所を登録することが重要です。
Azure Active Directory (Azure AD) アプリケーション モデルでは、URI のリダイレクトに次の制限が指定されます。
リダイレクト URL は、スキーム
httpsで始まる必要があります。 localhost リダイレクト URI には例外がいくつかあります。リダイレクト URI では大文字と小文字が区別され、実行中のアプリケーションの URL パスの大文字と小文字が一致する必要があります。 たとえば、そのパス
.../abc/response-oidcの一部としてアプリケーションが含まれている場合に、リダイレクト URL 内で.../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 の最大数
次の表に、Microsoft の ID プラットフォームでアプリの登録に追加できるリダイレクト URI の最大数を示します。
| サインイン中のアカウント | リダイレクト URI の最大数 | 説明 |
|---|---|---|
| 組織の Azure Active Directory (Azure AD) テナントにある Microsoft の職場または学校アカウント | 256 | アプリケーション マニフェストの signInAudience フィールドは AzureADMyOrg か AzureADMultipleOrgs に設定されています |
| Microsoft の個人用アカウント、職場用アカウント、学校用アカウント | 100 | アプリケーション マニフェストの signInAudience フィールドは AzureADandPersonalMicrosoftAccount に設定されています |
セキュリティ上の理由から、最大数のリダイレクト URI を発生することはできません。 シナリオ上、許可される最大制限を超えるリダイレクト URI が必要な場合は、解決方法として次の状態パラメーター アプローチを検討してください。
URI の最大長
アプリの登録に追加するリダイレクト URI ごとに最大 256 文字を使用できます。
アプリケーション オブジェクトとサービス プリンシパル オブジェクトにおけるリダイレクト URI
- リダイレクト URI は常にアプリケーション オブジェクトにのみ追加します。
- サービス プリンシパルにはリダイレクト URI を追加しないでください。サービス プリンシパル オブジェクトがアプリケーション オブジェクトと同期するとき、これらの値が削除されることがあるためです。 これは 2 つのオブジェクト間で同期をトリガーする更新操作に起因して発生します。
リダイレクト URI におけるクエリ パラメーターのサポート
アプリケーションのリダイレクト URI にクエリ パラメーターが許可されるのは、サインインするユーザーが職場または学校アカウントを有するユーザー "のみ" の場合です。
Outlook.com (Hotmail)、Messenger、OneDrive、MSN、Xbox Live、Microsoft 365 など、個人用 Microsoft アカウントを有するユーザーのサインインを処理するように構成されたアプリの登録では、リダイレクト URI のクエリ パラメーターは許可されません。
| アプリ登録のサインイン対象ユーザー | リダイレクト URI でのクエリ パラメーターのサポート |
|---|---|
| この組織ディレクトリのみに含まれるアカウント (Contoso のみ - シングル テナント) | 
|
| 任意の組織ディレクトリ内のアカウント (任意の Azure AD ディレクトリ - マルチテナント) |
|
| 任意の組織のディレクトリ (Azure AD ディレクトリ - マルチテナント) 内のアカウントと、個人用の 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 を登録しないでください。 ログイン サーバーでは任意のものが選択され、そのリダイレクト URI に関連付けられている動作が使用されます (たとえば、リダイレクトが
web型か、native型か、spa型か)。これは、同じアプリケーションの登録で異なる認証フロー (認可コードの付与と暗黙のフローなど) を使用する場合に特に重要です。 各リダイレクト URI に適切な応答動作を関連付けるには、ログイン サーバーがリダイレクト 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 アカウントと職場または学校のアカウントにサインインするように構成されているアプリの登録ではサポートされていません。 ただし、組織の Azure AD テナントで、職場または学校のアカウントにのみサインインするように構成されているアプリの場合は、ワイルドカード URI が許可されます。
職場または学校のアカウントにサインインするアプリの登録に、ワイルドカードを含むリダイレクト URI を追加するには、Azure portal の [アプリの登録] で、アプリケーション マニフェスト エディターを使用します。 マニフェスト エディターを使用して、ワイルドカードを含むリダイレクト URI を設定することも可能ですが、RFC 6749 のセクション 3.1.2 に準拠することを強くお勧めします。 絶対 URI のみを使用するようにしてください。
シナリオ上、許可される最大制限を超えるリダイレクト URI が必要な場合は、ワイルドカードを含むリダイレクト URI を追加する代わりに、次の状態パラメーター アプローチを検討してください。
状態パラメーターを使用する
いくつかのサブドメインがあり、シナリオ上それが必要である場合は、認証成功時にユーザーを開始時と同じページにリダイレクトしますが、状態パラメーターを使用すると便利な場合があります。
このアプローチでは:
- 認証エンドポイントから受け取ったセキュリティ トークンを処理する "共有" リダイレクト URI をアプリケーション別に作成します。
- アプリケーションでは、状態パラメーターで、アプリケーション固有のパラメーター (ユーザーの起点になったサブドメイン URL やブランド情報のような任意のもの) を送信できます。 状態パラメーターの使用時、CSRF 対策をしてください。仕様はセクション 10.12 of RFC 6749 にあります。
- アプリケーション固有のパラメーターには、ユーザーにとって適切なエクスペリエンスをアプリケーションから与えるために、つまり、アプリケーションの適切な状態を構築するために必要な情報がすべて含まれます。 Azure AD 認証エンドポイントにより状態パラメーターから HTML が取り除かれます。そのため、このパラメーターでは HTML コンテンツを渡さないようにしてください。
- Azure AD から "共有" リダイレクト URI に応答を送信するとき、状態パラメーターがアプリケーションに返されます。
- その後、ユーザーをさらに送信する宛先となる URL を決定する目的で、状態パラメーターの値をアプリケーションで利用できます。 CSRF 対策の有効性を確認してください。
警告
この手法では、セキュリティを侵害されたクライアントが状態パラメーターで送信された追加パラメーターを変更し、ユーザーを別の URL にリダイレクトすることを許します。これは RFC 6819 に説明があるオープン リダイレクターの脅威です。 そのため、クライアントは状態を暗号化するか、リダイレクト URI に含まれるドメイン名をトークンと比べて検証するなど、何か他の手段で状態を検証することによって、これらのパラメーターを保護する必要があります。
次の手順
アプリの登録のアプリケーション マニフェストについて学習します。