リダイレクト URI および応答 URL に関する制約と制限Redirect URI/reply URL restrictions and limitations

リダイレクト URI、または応答 URL は、アプリが正常に承認され、認証コードまたはアクセス トークンが付与されたとき、認証サーバーがユーザーを送信する場所です。A redirect URI, or reply URL, is the location that the authorization server will send the user to once the app has been successfully authorized, and granted an authorization code or access token. このコードまたはトークンはリダイレクト URI または応答トークンに含まれます。そのため、アプリ登録プロセスの一環として正しい場所を登録することが重要です。The code or token is contained in the redirect URI or reply token so it's important that you register the correct location as part of the app registration process.

応答 URL には、次の制限が適用されます。The following restrictions apply to reply URLs:

  • 応答 URL は、スキーム https で始まる必要があります。The reply URL must begin with the scheme https.

  • 応答 URL では大文字と小文字が区別されます。The reply URL is case-sensitive. 大文字と小文字の区別は、実行中のアプリケーションの URL パスの場合と一致している必要があります。Its case must match the case of the URL path of your running application. たとえば、ご利用のアプリケーションがそのパス .../abc/response-oidc の一部として含まれている場合は、応答 URL 内では .../ABC/response-oidc と指定しないでください。For example, if your application includes as part of its path .../abc/response-oidc, do not specify .../ABC/response-oidc in the reply URL. Web ブラウザーでは大文字と小文字を区別を区別するものとしてパスが処理されるため、.../abc/response-oidc に関連付けられている cookie は、大文字と小文字が一致しない .../ABC/response-oidc URL にリダイレクトされた場合に除外される可能性があります。Because the web browser treats paths as case-sensitive, cookies associated with .../abc/response-oidc may be excluded if redirected to the case-mismatched .../ABC/response-oidc URL.

リダイレクト URI の最大数Maximum number of redirect URIs

次の表では、アプリの登録時に追加できるリダイレクト URI の最大数を示しています。The following table shows the maximum number of redirect URIs that you can add when you register your app.

サインイン中のアカウントAccounts being signed in リダイレクト URI の最大数Maximum number of redirect URIs 説明Description
組織の Azure Active Directory (Azure AD) テナントにある Microsoft の職場または学校アカウントMicrosoft work or school accounts in any organization's Azure Active Directory (Azure AD) tenant 256256 アプリケーション マニフェストの signInAudience フィールドは AzureADMyOrgAzureADMultipleOrgs に設定されていますsignInAudience field in the application manifest is set to either AzureADMyOrg or AzureADMultipleOrgs
Microsoft の個人用アカウント、職場用アカウント、学校用アカウントPersonal Microsoft accounts and work and school accounts 100100 アプリケーション マニフェストの signInAudience フィールドは AzureADandPersonalMicrosoftAccount に設定されていますsignInAudience field in the application manifest is set to AzureADandPersonalMicrosoftAccount

URI の最大長Maximum URI length

アプリ登録に追加するリダイレクト URI ごとに最大 256 文字を使用できます。You can use a maximum of 256 characters for each redirect URI that you add to an app registration.

サポートされているスキームSupported schemes

現在、Azure AD アプリケーション モデルでは、組織の Azure Active Directory (Azure AD) テナントで Microsoft の職場または学校アカウントにサインインするアプリに対して、HTTP と HTTPS の両方のスキームがサポートされています。The Azure AD application model today supports both HTTP and HTTPS schemes for apps that sign in Microsoft work or school accounts in any organization's Azure Active Directory (Azure AD) tenant. つまり、アプリケーション マニフェストの signInAudience フィールドは、AzureADMyOrg または AzureADMultipleOrgs に設定されています。That is signInAudience field in the application manifest is set to either AzureADMyOrg or AzureADMultipleOrgs. 個人用の Microsoft アカウントと職場および学校のアカウントにサインインするアプリ (つまり、signInAudienceAzureADandPersonalMicrosoftAccount に設定されている) では、HTTPS スキームのみが許可されます。For the apps that sign in Personal Microsoft accounts and work and school accounts (that is signInAudience set to AzureADandPersonalMicrosoftAccount) only HTTPS scheme is allowed.

注意

新しいアプリの登録エクスペリエンスでは、開発者は UI で HTTP スキームを使用して URI を追加することはできません。The new App registrations experience doesn't allow developers to add URIs with HTTP scheme on the UI. 職場または学校アカウントにサインインするアプリに対して HTTP URI を追加することは、アプリ マニフェスト エディターでのみサポートされます。Adding HTTP URIs for apps that sign in work or school accounts is supported only through the app manifest editor. 今後、新しいアプリではリダイレクト URI で HTTP スキームを使用できなくなります。Going forward, new apps won't be able to use HTTP schemes in the redirect URI. ただし、リダイレクト URI に HTTP スキームを含む以前のアプリは引き続き動作します。However, older apps that contain HTTP schemes in redirect URIs will continue to work. 開発者は、リダイレクト URI で HTTPS スキームを使用する必要があります。Developers must use HTTPS schemes in the redirect URIs.

Localhost の例外Localhost exceptions

RFC 8252 のセクション 8.37.3 に従って、"loopback" または "localhost" リダイレクト URI には、次の 2 つの特別な考慮事項があります。Per RFC 8252 sections 8.3 and 7.3, "loopback" or "localhost" redirect URIs come with two special considerations:

  1. リダイレクトでデバイスを離れることはないため、http URI スキームは許容可能です。http URI schemes are acceptable, since the redirect never leaves the device. これは、http://127.0.0.1/myApp の他に、https://127.0.0.1/myApp も許容可能であることを意味します。This means http://127.0.0.1/myApp is acceptable, as well as https://127.0.0.1/myApp.
  2. ネイティブ アプリケーションでは一時的なポート範囲が頻繁に必要とされるため、ポート コンポーネント (:5001:443 など) は、リダイレクト URI との照合のために無視されます。Due to ephemeral port ranges often needed by native applications, the port component (e.g. :5001, or :443) is ignored for the purposes of matching a redirect URI. その結果、http://127.0.0.1:5000/MyApphttp://127.0.0.1:1234/MyApp は、どちらも http://127.0.0.1/MyApphttp://127.0.0.1:8080/MyApp と一致します。As a result, http://127.0.0.1:5000/MyApp and http://127.0.0.1:1234/MyApp both match http://127.0.0.1/MyApp as well as http://127.0.0.1:8080/MyApp

開発の観点から見ると、これはいくつかのことを意味します。From a development standpoint, this means a few things:

  1. ポートのみが異なる場合は、複数の応答 URI を登録しないでください。Do not register multiple reply URIs where only the port differs. ログイン サーバーでは任意のものが選択され、その応答 URI に関連付けられている動作が使用されます (たとえば、webnativespa 型のリダイレクトであるかどうか)。The login server will pick one arbitrarily, and use the behavior associated with that reply URI (for example, whether it is a web, native, and spa -type redirect.
  2. 複数のリダイレクト URI を localhost に登録して開発中にさまざまなフローをテストする必要がある場合は、URI の "パス" コンポーネントを使用してそれらを区別します。If you need to register multiple redirect URIs on localhost to test different flows during development, differentiate them using the path component of the URI. http://127.0.0.1/MyWebApphttp://127.0.0.1/MyNativeApp は一致しません。http://127.0.0.1/MyWebApp does not match http://127.0.0.1/MyNativeApp.
  3. RFC ガイダンスに従って、リダイレクト URI で localhost を使用しないでください。Per RFC guidance, you should not use localhost in the redirect URI. 代わりに、実際のループバック IP アドレス 127.0.0.1 を使用します。Instead, use the actual loopback IP address - 127.0.0.1. これにより、正しく構成されていないファイアウォールや名前が変更されたネットワーク インターフェイスによるアプリの破損が防止されます。This prevents your app from being broken by misconfigured firewalls or renamed network interfaces.

注意

現時点では、IPv6 ループバック ([::1]) はサポートされていません。At this time, IPv6 loopback ([::1]) is not supported at this time. これは後日追加される予定です。This will added at a later date.

URI にワイルドカードを使用する制限Restrictions using a wildcard in URIs

https://*.contoso.com のようなワイルドカード URI は便利ですが、避けてください。Wildcard URIs, such as https://*.contoso.com, are convenient but should be avoided. リダイレクト URI にワイルドカードを使用すると、セキュリティ面で影響が出ます。Using wildcards in the redirect URI has security implications. OAuth 2.0 仕様 (セクション 3.1.2 of RFC 6749) によると、リダイレクト エンドポイント URI は絶対 URI にする必要があります。According to the OAuth 2.0 specification (section 3.1.2 of RFC 6749), a redirection endpoint URI must be an absolute URI.

Microsoft の個人用アカウント、職場用アカウント、学校用アカウントにサインインするように構成されているアプリの場合、Azure AD アプリケーション モデルではワイルドカード URI がサポートされません。The Azure AD application model doesn't support wildcard URIs for apps that are configured to sign in personal Microsoft accounts and work or school accounts. ただし、組織の Azure AD テナントで本日、職場または学校アカウントにサインインするように構成されているアプリの場合、ワイルドカード URI が許可されます。However, wildcard URIs are allowed for apps that are configured to sign in work or school accounts in an organization's Azure AD tenant today.

注意

新しいアプリの登録エクスペリエンスでは、開発者は UI にワイルドカード URI を追加できません。The new App registrations experience doesn't allow developers to add wildcard URIs on the UI. 職場または学校アカウントにサインインするアプリに対してワイルドカード URI を追加することは、アプリ マニフェスト エディターでのみサポートされます。Adding wilcard URI for apps that sign in work or school accounts is supported only through the app manifest editor. 今後、新しいアプリではリダイレクト URI でワイルドカードを使用できません。Going forward, new apps won't be able to use wildcards in the redirect URI. ただし、リダイレクト URI にワイルドカードを含む以前のアプリは引き続き動作します。However, older apps that contain wildcards in redirect URIs will continue to work.

シナリオ上、許可される最大制限を超えるリダイレクト URI が必要な場合、ワイルドカード リダイレクト URI を追加する代わりに、次の手法を検討してください。If your scenario requires more redirect URIs than the maximum limit allowed, instead of adding a wildcard redirect URI, consider the following approach.

状態パラメーターを使用するUse a state parameter

たくさんのサブドメインがあるとき、認証に成功したユーザーを最初のページにリダイレクトする必要がある場合、状態パラメーターの使用が便利なことがあります。If you have a number of sub-domains, and if your scenario requires you to redirect users upon successful authentication to the same page where they started, using a state parameter might be helpful.

このアプローチでは:In this approach:

  1. 認証エンドポイントから受け取ったセキュリティ トークンを処理する "共有" リダイレクト URI をアプリケーション別に作成します。Create a "shared" redirect URI per application to process the security tokens you receive from the authorization endpoint.
  2. アプリケーションでは、状態パラメーターでアプリケーション固有のパラメーター (ユーザーがセッションを始めたサブドメイン URL やブランド情報のようなもの) を送信できます。Your application can send application-specific parameters (such as sub-domain URL where the user originated or anything like branding information) in the state parameter. 状態パラメーターの使用時、CSRF 対策をしてください。仕様はセクション 10.12 of RFC 6749 にあります。When using a state parameter, guard against CSRF protection as specified in section 10.12 of RFC 6749).
  3. アプリケーション固有のパラメーターには、ユーザーにとって適切なエクスペリエンスをアプリケーションから与えるために、つまり、アプリケーションの適切な状態を構築するために必要な情報がすべて含まれます。The application-specific parameters will include all the information needed for the application to render the correct experience for the user, that is, construct the appropriate application state. Azure AD 認証エンドポイントにより状態パラメーターから HTML が取り除かれます。そのため、このパラメーターでは HTML コンテンツを渡さないようにしてください。The Azure AD authorization endpoint strips HTML from the state parameter so make sure you are not passing HTML content in this parameter.
  4. Azure AD から "共有" リダイレクト URI に応答を送信するとき、状態パラメーターがアプリケーションに返されます。When Azure AD sends a response to the "shared" redirect URI, it will send the state parameter back to the application.
  5. その後、ユーザーをさらに送信する宛先となる URL を決定する目的で、状態パラメーターの値をアプリケーションで利用できます。The application can then use the value in the state parameter to determine which URL to further send the user to. CSRF 対策の有効性を確認してください。Make sure you validate for CSRF protection.

注意

この手法では、セキュリティを侵害されたクライアントが状態パラメーターで送信された追加パラメーターを変更し、ユーザーを別の URL にリダイレクトすることを許します。これは RFC 6819 に説明があるオープン リダイレクターの脅威です。This approach allows a compromised client to modify the additional parameters sent in the state parameter, thereby redirecting the user to a different URL, which is the open redirector threat described in RFC 6819. そのため、クライアントは状態を暗号化し、他の手段で検証することでこれらのパラメーターを保護する必要があります。他の手段とは、たとえば、リダイレクト URI に含まれているドメイン名の妥当性をトークンに照らして検証します。Therefore, the client must protect these parameters by encrypting the state or verifying it by some other means such as validating domain name in the redirect URI against the token.

次のステップNext steps