テナントの mTLS 認証を設定する方法を説明します。
以下の例では、$management_access_token または Management API アクセストークン を指定しています。これらは、少なくとも次のスコープを含むアクセストークンに置き換える必要があります。
create:custom_domains
read:custom_domains
create:clients
update:clients
update:client_credentials
update:client_keys
update:tenant_settings
必要なスコープを持つアクセストークンを取得する方法について詳しくは、Get Access Tokens を参照してください。
まず、カスタムドメイン を設定して検証する必要があります。
テナント レベルで mTLS ヘッダーを Management API で受け入れるには、カスタムドメイン を設定する必要があります。カスタマーエッジ がクライアント証明書の検証を担当するため、POST リクエストでは type を self_managed_certs に設定します。
curl --location --request POST 'https://$tenant/api/v2/custom-domains' \
--header 'Authorization: Bearer $management_access_token' \
--header 'Content-Type: application/json' \
--data-raw '{
"domain":"string",
"type":"self_managed_certs",
"verification_method":"txt",
"tls_policy":"recommended",
"custom_client_ip_header":"true-client-ip"
}'
リクエストが成功すると、の検証に使用する識別子が返されます。詳細については、新しいカスタムドメインを設定する API ドキュメントを参照してください。
Management API を使用すると、既存のカスタムドメインが mTLS ヘッダーを受け入れるように設定できます。ただし、既存のカスタムドメインの type は更新できません。
mTLS に使用できるのは、self_managed_certs タイプのカスタムドメインのみです。Auth0 は現在、mTLS で auth0_managed_certs タイプをサポートしていません。
次の POST リクエストは、既存のカスタムドメインが mTLS ヘッダーを受け入れるように設定します。
curl --location --request POST 'https://$tenant/api/v2/custom-domains/:id' \
--header 'Authorization: Bearer $management_access_token' \
--header 'Content-Type: application/json' \
--data-raw '{
"tls_policy":"recommended",
"custom_client_ip_header":"true-client-ip"
}'
詳細については、カスタムドメイン設定を更新する API ドキュメントを参照してください。
Auth0 がカスタムドメインの作成および更新リクエストを受け付けるには、まずそのドメインを検証する必要があります。カスタムドメインを検証するには、Management API を使用して次の POST リクエストを送信します。
curl --location --request POST 'https://$tenant/api/v2/custom-domains/:id/verify'
検証状態を確認するには、status フィールドを確認します。検証が完了しても、カスタムドメインがリクエストを受け付けられるようになるまでに最大 10 分かかる場合があります。
Auth0 がカスタムドメインを初めて検証すると、レスポンスに cname_api_key が含まれます。これは、エッジ/リバースプロキシの設定に必要です。このキーは秘密として保持する必要があり、転送されたリクエストの検証に使用されます。
詳細については、Verify a custom domain API ドキュメントを参照してください。
mTLS ハンドシェイクでクライアント証明書の提示が求められると、Web ブラウザーはユーザーに証明書を選択するためのモーダルダイアログを表示します。これはユーザー体験の妨げになるため、/authorize エンドポイントのように mTLS が不要なエンドポイントでは避けるべきです。そのため、mTLS トラフィックと非 mTLS トラフィックを異なるドメインでサポートする場合は、mTLS エンドポイントエイリアスを有効にする必要があります。
mTLS エンドポイントエイリアスは、クライアントが OIDC ディスカバリードキュメントの mtls_endpoint_aliases プロパティで指定されたエンドポイントに mTLS トラフィックを送信する必要があることを示します。非 mTLS トラフィックは通常のエンドポイントに送信されます。mtls_endpoint_aliases プロパティの詳細については、リソースサーバーを呼び出すを参照してください。
mTLS エンドポイントエイリアスは、 と で有効にできます。
Auth0 Dashboard
Management API
Auth0 Dashboard を使用して mTLS エンドポイントエイリアスを有効にするには、次の手順に従います。
- Auth0 Dashboard に移動し、サイドメニューから Settings を選択します。
- Tenant Settings で Advanced タブを選択します。
- Allow mTLS Endpoint Aliases を見つけてオンにします。これにより、mTLS トラフィックは
mtls.<your custom domain>. というエンドポイントにルーティングされます。
Management API を使用して mTLS エンドポイントエイリアスを有効にするには、テナントの enable_endpoint_aliases プロパティを true に設定します。curl --location --request PATCH 'https://$tenant/api/v2/tenants/settings' \
--header 'Authorization: Bearer $management_access_token' \
--header 'Content-Type: application/json' \
--data-raw '{
"mtls": {
"enable_endpoint_aliases": true
}
}'
mTLS エンドポイントエイリアスでは、設定済みのカスタムドメインに mtls. プレフィックスが追加されます。たとえば、設定済みのカスタムドメインが auth.saasapp.com の場合、mTLS エンドポイントエイリアスでは mtls.auth.saasapp.com が使用されます。今後は、寄せられたフィードバックに応じて、mTLS エンドポイントエイリアスを設定できるようになる可能性があります。mTLS サブドメインは Auth0 の管理範囲外です。管理者はサブドメインに伴うリスクを理解し、適切に対処する必要があります。これには以下が含まれますが、これらに限定されません。
- mTLS で使用するトップレベルドメインとサブドメインについて、所有権と管理権限を確保すること。これを怠ると、ログインハンドラーと mTLS サブドメインの両方を失う可能性があります。これは特に カスタムドメイン を使用する場合に重要です。
- mTLS サブドメイン、つまり
mtls.auth.saasapp.com 用の SSL 証明書を用意すること。*.saasapp.com のワイルドカード証明書には mTLS サブドメインは含まれません。
IP が使用されなくなった場合に、宙づりの DNS エントリによるサブドメイン乗っ取りを防止すること。詳細については、Mozilla Developer Network (MDN) の Subdomain takeovers ドキュメントを参照してください。 mTLS エンドポイントエイリアスを無効にするには、enable_endpoint_aliases の値を false に設定します。詳細については、テナント設定を更新する API ドキュメントを参照してください。