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

​
URL の評価方法

{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 という名前の組織が登録されていなくても、有効と見なされます。これは、ワイルドカードプレースホルダーが評価されるためです。

​
ワイルドカード URL プレースホルダー

サブドメイン内のワイルドカードプレースホルダーは、本番環境のアプリケーションでは使用しないでください。該当する場合、Auth0 では {organization_name} プレースホルダーを含む URL の使用を推奨しています。
強化されたセキュリティ制御が適用されるサードパーティアプリケーションでは、ワイルドカード URL プレースホルダーはサポートされていません。コールバック URL、許可されたオリジン、Web オリジンには、正確な URL を使用する必要があります。
これらの設定は、Dashboard > Applications > Applications の以下のフィールドで管理します。
  • Allowed Callback URLs: ユーザーの認証後に Auth0 がリダイレクトできる URL の一覧。
  • Allowed Logout URLs: ユーザーが Auth0 からログアウトした後にリダイレクトできる URL の一覧。
  • Allows Web Origins: Cross-Origin Authentication、Device Flow、およびレスポンスモードとしての web_messageを使用する認可リクエストの送信元にできる 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 には一致しません。

​
組織URLのプレースホルダー

​
組織名プレースホルダー

URL 内で登録済みの組織名を動的に指定するプレースホルダーとして、{organization_name} を使用できます (https://{organization_name}.exampleco.com) 。{organization_name} プレースホルダーを含む URL は、完全に管理しているドメインでのみ使用してください。たとえば、exampleco.com ドメインを管理している場合、組織名のプレースホルダーは https://{organization_name}.exampleco.com になります。 これらの設定は、Dashboard > Applications > 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 は動作しません。

​
組織メタデータのプレースホルダー

{organization.metadata.KEY} をプレースホルダーとして使用すると、現在のリクエスト内の組織に関連付けられたメタデータに基づいて、URL を動的に指定できます。これは、各組織がそれぞれ別のバニティドメインに対応している場合など、組織ごとに異なるログイン URI が必要なときに役立ちます。 KEY は public_ または PUBLIC_ で始まる必要があります (例: {organization.metadata.public_login_host}) 。この接頭辞がないキーは、セキュリティ上の理由から実行時に無視されます。 Auth0 は、アプリケーションのログイン URI (initiate_login_uri) でこのプレースホルダーをサポートしています。詳しくは、メタデータプレースホルダーを使用した動的ログイン URI を参照してください。 カスタムドメインのプレースホルダーに適用されるものと同じ検証ルールが、組織メタデータのプレースホルダーにも適用されます (プロトコル、配置、ネスト、ワイルドカードなし、データ型) 。
組織メタデータのプレースホルダーを使用するには、リクエストが組織コンテキスト内にある必要があります。組織が存在しない場合、プレースホルダーは解決されず、Auth0 はテナントレベルの default_redirection_uri にフォールバックします。

​
カスタムドメイン URL プレースホルダー

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

​
検証ルール

URL のプレースホルダーとして使用されるメタデータ値は、認証フロー中にエンドユーザーに公開される可能性があります。プレースホルダーには機密性の高いメタデータを使用しないでください。これを明確にするため、プレースホルダーで使用するすべてのメタデータキーは public_ で始まっている必要があります。
カスタムドメインのプレースホルダーを使用する場合は、次の制限が適用されます。
  • 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 は検証時に無視されます。

​
対応しているフィールド

これらのプレースホルダーは、次の Application URLs で設定できます。 詳細は、Application Settingsを参照してください。
サードパーティアプリケーションでは、カスタムドメインのプレースホルダーはサポートされていません。

​
組織プレースホルダーと併用する

使用しているフローが対応していれば、カスタムドメインのプレースホルダーを {organization_name} プレースホルダーと組み合わせて使用できます。両方のプレースホルダーは実行時に評価され、置き換えられます。

​
詳細情報