リダイレクト 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 の構成

次のいずれかの方法を使用して iOS アプリをビルドしている場合は、モバイルおよびデスクトップ アプリケーションのプラットフォームを使用してリダイレクト URI を追加します。

• レガシ SDK を使用する iOS アプリ (ADAL)
• オープンソース SDK を使用する iOS アプリ (AppAuth)
• サポートされていないクロスプラットフォーム テクノロジを使用する iOS アプリ (Flutter)
• OAuth プロトコルを直接実装する iOS アプリ
• サポートされていないクロスプラットフォーム テクノロジを使用する macOS アプリ (Electron)

リダイレクト URI を必要としないアプリケーション

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-oidc URL にリダイレクトされた場合に除外される可能性があります。

• パス セグメントで構成 "されていない" リダイレクト 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 が必要な場合は、解決方法として次の状態パラメーター アプローチを検討してください。 次の表では、Microsoft ID プラットフォームでアプリ登録に追加できるリダイレクト URI の最大数を示します。

アプリの登録に追加するリダイレクト 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 で "のみ" サポートされ、アクティブなローカル アプリケーションの開発およびテスト中にのみ使用する必要があります。

Localhost の例外

RFC 8252 のセクション 8.3 と 7.3 に従って、"loopback" または "localhost" リダイレクト URI には、次の 2 つの特別な考慮事項があります。

1. リダイレクトがデバイスから切り離されることはないため、http URI スキームを指定できます。 そのため、これら両方の URI を使用できます。
   • http://localhost/myApp
   • https://localhost/myApp
2. ネイティブ アプリケーションでは一時的なポート範囲が頻繁に必要とされるため、リダイレクト URI の照合目的では、ポート コンポーネント (:5001や :443 など) は無視されます。 結果として、これらの URI はすべて同等と見なされます。
   • http://localhost/MyApp
   • http://localhost:1234/MyApp
   • http://localhost:5000/MyApp
   • http://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 を追加する代わりに、次の状態パラメーター アプローチを検討してください。

状態パラメーターを使用する

いくつかのサブドメインがあり、シナリオ上それが必要である場合は、認証成功時にユーザーを開始時と同じページにリダイレクトしますが、状態パラメーターを使用すると便利な場合があります。

このアプローチでは:

1. 認証エンドポイントから受け取ったセキュリティ トークンを処理する "共有" リダイレクト URI をアプリケーション別に作成します。
2. アプリケーションでは、状態パラメーターで、アプリケーション固有のパラメーター (ユーザーの起点になったサブドメイン URL やブランド情報のような任意のもの) を送信できます。 状態パラメーターの使用時、CSRF 対策をしてください。仕様は RFC 6749 のセクション 10.12 にあります。
3. アプリケーション固有のパラメーターには、アプリケーションでユーザーに適切なエクスペリエンスをレンダリングするため、つまりアプリケーションの適切な状態を構築するために必要な情報がすべて含まれます。 Microsoft Entra 承認エンドポイントにより状態パラメーターから HTML が取り除かれるため、このパラメーターで HTML の内容を渡さないでください。
4. Microsoft Entra ID は、"共有" リダイレクト URI に応答を送信するとき、状態パラメーターをアプリケーションに送り返します。
5. その後、ユーザーをさらに送信する宛先となる URL を決定する目的で、状態パラメーターの値をアプリケーションで利用できます。 CSRF 対策の有効性を確認してください。

次のステップ

アプリの登録のアプリケーション マニフェストについて学習します。