> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> アプリケーション構成で、ワイルドカードや organization プレースホルダーを含むプレースホルダーがサブドメインでどのように機能するかを説明します。

# サブドメイン URL プレースホルダー

URL 内で動的なテキストとして機能する、さまざまなプレースホルダーを使用できます。

<div id="how-url-evaluation-works">
  ## URL 評価の仕組み
</div>

`{organization_name}` プレースホルダーを含む URL は、次の条件がすべて満たされる場合にのみ評価されます。

* アプリケーションの `organization_usage` が `allow` または `require` に設定されている
* organization のコンテキストで transaction が実行された (たとえば、organization パラメーターを指定して認可 transaction を開始した場合: `/authorize?organization=org_bVss9Do3994SIbiH&…`)

`{organization_name}` プレースホルダーを含む URL は、完全一致 URL (`https://app.exampleco.com`) およびワイルドカードを含む URL (`https://*.exampleco.com`) に加えて評価されます。URL がどの順序で評価されるかについては、特定の順序を前提にしないでください。

同じアプリケーションの同じ設定フィールドに、ワイルドカードと Organization プレースホルダーを含む URL を登録することは避けてください。意図しない動作を招き、トラブルシューティングが難しくなるおそれがあります。例として、**Allowed Callback URLs** が 2 つ設定されたアプリケーションを考えてみましょう: `https://*.exampleco.com` と `https://{organization_name}.exampleco.com` です。値が `https://company-a.exampleco.com` の `redirect_uri` は、テナントに `company-a` という名前の Organizations が登録されていなくても、有効と見なされます。これは、ワイルドカード プレースホルダーが評価されるためです。

<div id="wildcard-url-placeholders">
  ## ワイルドカード URL プレースホルダー
</div>

サブドメイン内のワイルドカードプレースホルダーは、本番環境のアプリケーションでは**使用しないでください**。該当する場合、Auth0 では `{organization_name}` プレースホルダーを含む URL の使用を推奨しています。

<Warning>
  ワイルドカード URL プレースホルダーは、強化されたセキュリティ制御が適用された[サードパーティアプリケーション](/docs/ja-jp/get-started/applications/third-party-applications)ではサポートされていません。コールバック URL、許可するオリジン、Web Origins には正確な URL を使用する必要があります。
</Warning>

これらの設定は、[Auth0 Dashboard > アプリケーション > アプリケーション](https://manage.auth0.com/#/applications) の以下の項目で管理します。

* **Allowed Callback URLs**: ユーザーの認証後に Auth0 がユーザーをリダイレクトできる URL の一覧。
* **Allowed Logout URLs**: ユーザーが Auth0 からログアウトした後にリダイレクトできる URL の一覧。
* **Allows Web Origins**: [Cross-Origin Authentication](/docs/ja-jp/authenticate/login/cross-origin-authentication)、[Device Flow](/docs/ja-jp/get-started/authentication-and-authorization-flow/device-authorization-flow)、および[レスポンスモードとしての web\_message](/docs/ja-jp/authenticate/protocols/oauth)を使用する認可リクエストの送信元として使用できる URL の一覧。
* **Allowed Origins (CORS)**: JavaScript から Auth0 API へのリクエストを許可する URL の一覧 (通常は CORS で使用) 。

本番環境のアプリケーションのコールバックや許可するオリジンでは、サブドメインにワイルドカードプレースホルダーを使用しないでください。アプリケーションが攻撃に対して脆弱になる可能性があります。

サブドメインのワイルドカードとしてアスタリスク (`*`) を使用できますが、正しく機能させるには次のルールに従う必要があります。

* URL のプロトコルは**必ず** `http` または `https` でなければなりません。`com.example.app` や `service:jmx:rmi` などのプロトコルは機能しません。
* ワイルドカードは**必ず**ホスト名コンポーネント内のサブドメインに配置する必要があります。`https://*.com` は機能しません。
* ワイルドカードは**必ず**ルートドメインから最も遠いサブドメインに配置する必要があります。`https://sub.*.example.com` は機能しません。
* URL に含められるワイルドカードは **1 つまで**です。`https://*.*.example.com` は機能しません。
* ワイルドカードの前後には、有効なホスト名文字を追加**できます**。`https://prefix-*-suffix.example.com` は機能します。
* 有効なワイルドカードを含む URL は、ワイルドカードの位置に 2 階層以上のサブドメインが入る URL には**一致しません**。`https://*.example.com` は `https://sub1.sub2.example.com` では機能しません。

<div id="organization-url-placeholders">
  ## 組織URLのプレースホルダー
</div>

<div id="organization-name-placeholder">
  ### 組織名プレースホルダー
</div>

`{organization_name}` は、URL (`https://{organization_name}.exampleco.com`) 内で登録済みの組織名を動的に指定するためのプレースホルダーとして使用できます。`{organization_name}` プレースホルダーを含む URL は、必ず完全に管理下にあるドメインでのみ使用してください。たとえば、`exampleco.com` ドメインを管理している場合、組織名を含むプレースホルダーは `https://{organization_name}.exampleco.com` です。

これらの設定は、[Auth0 Dashboard > アプリケーション > アプリケーション](https://manage.auth0.com/#/applications) の以下の項目で管理します。

* **Allowed Callback URLs**: ユーザーの認証後に Auth0 がリダイレクトできる URL の一覧。
* **Allowed Origins (CORS)**: JavaScript から Auth0 API へのリクエストを許可する URL の一覧 (通常は CORS で使用) 。

`{organization_name}` プレースホルダーを使用する場合、以下の制限が適用されます。

* URL のプロトコルは `http:` または `https:` である必要があります。`com.example.app://{organization_name}.exampleco.com` は使用できません。
* プレースホルダーは、ホスト名内のサブドメインに配置する必要があります。`https://{organization_name}` と `https://exampleco.com/{organization_name}` はどちらも使用できません。
* プレースホルダーは、ルートドメインから最も遠いサブドメインに配置する必要があります。`https://sub.{organization_name}.exampleco.com` は使用できません。
* URL に複数のプレースホルダーを含めることはできません。`https://{organization_name}.{organization_name}.exampleco.com` は使用できません。
* プレースホルダーの前後に、有効なホスト名文字を付けることはできません。`https://prefix-{organization_name}-suffix.exampleco.com` は使用できません。
* URL 内でプレースホルダーをワイルドカードと併用しては**なりません**。`https://{organization_name}.*.exampleco.com` は使用できません。

<div id="organization-metadata-placeholder">
  ### 組織メタデータのプレースホルダー
</div>

`{organization.metadata.KEY}` は、現在のリクエスト内の組織に関連付けられたメタデータに基づいて URL を動的に指定するためのプレースホルダーとして使用できます。これは、各組織がそれぞれ別のバニティドメインに対応している場合など、組織ごとに異なるログイン URI が必要なときに便利です。

`KEY` は `public_` または `PUBLIC_` で始まる必要があります (例: `{organization.metadata.public_login_host}`) 。この接頭辞のないキーは、セキュリティ上の理由により、runtime では無視されます。

Auth0 では、このプレースホルダーをアプリケーションのログイン URI (`initiate_login_uri`) でサポートしています。詳しくは、[メタデータプレースホルダーを使用した動的ログイン URI](/docs/ja-jp/authenticate/login/auth0-universal-login/configure-default-login-routes)を参照してください。

カスタムドメインプレースホルダーに適用されるものと同じ[検証ルール](#validation-rules)が、組織メタデータのプレースホルダーにも適用されます (プロトコル、場所、ネスト、ワイルドカード不可、データ型) 。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  組織メタデータのプレースホルダーを使用するには、リクエストが organization のコンテキスト内にある必要があります。organization が存在しない場合、プレースホルダーは解決されず、Auth0 はテナントレベルの `default_redirection_uri` にフォールバックします。
</Callout>

<div id="custom-domain-url-placeholders">
  ## カスタムドメイン URL のプレースホルダー
</div>

`{custom_domain.metadata.KEY}` をプレースホルダーとして使用すると、リクエストで使われるカスタムドメインに関連付けられたメタデータに基づいて、URL を動的に指定できます。これにより、同じテナント内でアプリケーション URL が異なる複数のカスタムドメインをサポートできます。

この機能の詳細な概要については、[複数のカスタムドメイン](/docs/ja-jp/customize/custom-domains/multiple-custom-domains) を参照してください。

<div id="validation-rules">
  ### 検証ルール
</div>

<Warning>
  URL のプレースホルダーとして使用されるメタデータ値は、認証フロー中にエンドユーザーに公開される可能性があります。プレースホルダーに機密性の高いメタデータを使用しないでください。これを明確にするため、プレースホルダーで使用するすべてのメタデータキーは `public_` で始まっている必要があります。
</Warning>

カスタムドメインのプレースホルダーを使用する場合は、次の制限が適用されます。

* **Public プレフィックスが必要**: プレースホルダーで使用するメタデータキーは、`public_` または `PUBLIC_` で始まっている必要があります (例: `{custom_domain.metadata.public_callback_subdomain}`) 。このプレフィックスがないキーは、セキュリティ上の理由により実行時に無視されます。
  * **プロトコル**: URL のプロトコルは `http` または `https` である必要があります。
  * **場所**: プレースホルダーはドメイン名またはサブドメイン名の部分に配置する必要があります。URL パスでは使用できません。
    * 有効: `https://{custom_domain.metadata.public_app_url}.example.com/login`
    * 無効: `https://example.com/{custom_domain.metadata.public_path}`
  * **ネスト**: ネストされたメタデータプロパティにはアクセスできません。サポートされるのは最上位レベルのキーのみです。
  * **ワイルドカード不可**: カスタムドメインのプレースホルダーは、同じ URL 内でワイルドカード (`*`) と併用してはいけません。
  * **データ型**: カスタムドメインのメタデータ内の値は String である必要があります。キーが存在しない場合、または値が String でない場合、その URL は検証時に無視されます。

<div id="supported-fields">
  ### 対応フィールド
</div>

これらのプレースホルダーは、次のアプリケーションURLに設定できます。

* Allowed Callback URLs
  * Allowed Logout URLs
  * Allowed Web Origins
  * Allowed Origins (CORS)
  * Application Login URI (`initiate_login_uri`)。詳しくは、[メタデータプレースホルダーを使用した動的ログイン URI](/docs/ja-jp/authenticate/login/auth0-universal-login/configure-default-login-routes#dynamic-login-uris-with-metadata-placeholders)を参照してください。

詳細については、[Application Settings](https://auth0.com/docs/get-started/applications/application-settings#application-uris)を参照してください。

<Note>
  カスタムドメインのプレースホルダーは、サードパーティアプリケーションでは使用できません。
</Note>

<div id="using-with-organization-placeholders">
  ### 組織プレースホルダーと併用する
</div>

フローでサポートされていれば、カスタムドメインのプレースホルダーと `{organization_name}` プレースホルダーを組み合わせて使用できます。どちらのプレースホルダーも実行時に評価されて置き換えられます。

<div id="learn-more">
  ## 詳細はこちら
</div>

* [機密アプリケーションとパブリックアプリケーション](/docs/ja-jp/get-started/applications/confidential-and-public-applications)
* [ファーストパーティアプリケーションとサードパーティアプリケーション](/docs/ja-jp/get-started/applications/first-party-and-third-party-applications)
* [サードパーティアプリケーションを有効にする](/docs/ja-jp/get-started/applications/third-party-applications/configure-third-party-applications)