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

​
URL 評価の仕組み

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

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

サブドメイン内のワイルドカードプレースホルダーは、本番環境のアプリケーションでは使用しないでください。該当する場合、Auth0 では {organization_name} プレースホルダーを含む URL の使用を推奨しています。
ワイルドカード URL プレースホルダーは、強化されたセキュリティ制御が適用されたサードパーティアプリケーションではサポートされていません。コールバック URL、許可するオリジン、Web Origins には正確な URL を使用する必要があります。
これらの設定は、Auth0 Dashboard > アプリケーション > アプリケーション の以下の項目で管理します。
  • 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 のプロトコルは必ず 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のプレースホルダー

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

{organization_name} は、URL (https://{organization_name}.exampleco.com) 内で登録済みの組織名を動的に指定するためのプレースホルダーとして使用できます。{organization_name} プレースホルダーを含む URL は、必ず完全に管理下にあるドメインでのみ使用してください。たとえば、exampleco.com ドメインを管理している場合、組織名を含むプレースホルダーは https://{organization_name}.exampleco.com です。 これらの設定は、Auth0 Dashboard > アプリケーション > アプリケーション の以下の項目で管理します。
  • 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}) 。この接頭辞のないキーは、セキュリティ上の理由により、runtime では無視されます。 Auth0 では、このプレースホルダーをアプリケーションのログイン URI (initiate_login_uri) でサポートしています。詳しくは、メタデータプレースホルダーを使用した動的ログイン URIを参照してください。 カスタムドメインプレースホルダーに適用されるものと同じ検証ルールが、組織メタデータのプレースホルダーにも適用されます (プロトコル、場所、ネスト、ワイルドカード不可、データ型) 。
組織メタデータのプレースホルダーを使用するには、リクエストが organization のコンテキスト内にある必要があります。organization が存在しない場合、プレースホルダーは解決されず、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 は検証時に無視されます。

​
対応フィールド

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

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

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

​
詳細はこちら