> ## 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.

> アプリケーション設定におけるサブドメイン機能で使用する、ワイルドカードおよび組織のプレースホルダーを含むプレースホルダーについて説明します。

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

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

<div id="how-url-evaluation-works">
  ## URL の評価方法
</div>

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

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

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

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

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

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

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

これらの設定は、[Dashboard > Applications > Applications](https://manage.auth0.com/#/applications) の以下のフィールドで管理します。

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

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

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

* 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>

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

これらの設定は、[Dashboard > Applications > Applications](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}`) 。この接頭辞がないキーは、セキュリティ上の理由から実行時に無視されます。

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

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

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

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

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

この機能の詳細については、[複数のカスタムドメイン](/ja/docs/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>

これらのプレースホルダーは、次の Application URLs で設定できます。

* Allowed Callback URLs
  * Allowed Logout URLs
  * Allowed Web Origins
  * Allowed Origins (CORS)
  * Application Login URI (`initiate_login_uri`)。詳しくは、[メタデータプレースホルダーを使用した動的ログイン URI](/ja/docs/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>

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