機能にカスタムドメインの使用を構成する

Auth0の機能にカスタムドメインの使用を構成する場合、使用している機能によっては追加の手順を完了する必要があります。たとえば、ログインページでカスタムドメインを使用したり、APIを呼び出したりするには、変更が必要になるかもしれません。

Auth0をしばらく使用していて、カスタムドメインを有効化することに決めた場合には、既存のアプリを移行して、VPNやファイアウォールなどを含む以下の設定を更新しなければなりません。カスタムドメインを使い始めると、{yourDomain}で作成された既存のセッションが無効になるため、ユーザーに再ログインが求められます。

カスタムドメインの構成と検証がすでに完了している

Auth0のユニバーサルログインを使用していて、ログインページをカスタマイズした場合には、カスタムドメインを使用するようにコードを更新しなければなりません。カスタマイズすることなく、デフォルトのログインページを使用している場合には、変更の必要はありません。詳細については、「Auth0のユニバーサルログイン」をお読みください。

Web用のLockを使用している場合には、configurationBaseUrlとoverridesのオプションを以下のスクリプト例のように設定しなければなりません。

var lock = new Auth0Lock(config.clientID, config.auth0Domain, {
  //code omitted for brevity
  configurationBaseUrl: config.clientConfigurationBaseUrl,
  overrides: {
  	__tenant: config.auth0Tenant,
  	__token_issuer: config.authorizationServer.issuer
  },
  //code omitted for brevity
});

ユニバーサルログインページにAuth0.jsを使用している場合には、overridesオプションを設定する必要があります。

var webAuth = new auth0.WebAuth({
  clientID: config.clientID,
  domain: config.auth0Domain,
  //code omitted for brevity
  overrides: {
  	__tenant: config.auth0Tenant,
  	__token_issuer: config.authorizationServer.issuer
  },
  //code omitted for brevity
});

ほとんどの場合、Auth0.jsとLockライブラリーは、ドメインからテナント名（/usernamepassword/loginに必要）と発行者（id_tokenの検証に必要）を取得します。ただし、プライベートクラウドでプロキシを使用しているか、テナントや発行者と異なる名前を持つカスタムドメインを使用している場合には、__tenantや__token_issuerを使って一意の値を渡すことができます。

アプリケーションにWeb用のLockを埋め込んで使用している場合には、Lockの初期化時にカスタムドメインが使用されるようにコードを更新しなければなりません。また、configurationBaseUrlを適切なCDNのURLに設定する必要があります。

var lock = new Auth0Lock('{yourClientId}', '{yourCustomDomain}', {
  //code omitted for brevity
  configurationBaseUrl: 'https://cdn.us.auth0.com'
  //code omitted for brevity
});

CDNのURLは地域によって異なります。https://cdn.[us|eu|au|jp].auth0.com（アメリカにはus、ヨーロッパにはeu、オーストラリアにはau、日本にはjp）を使用します。

Auth0 SPA SDK、Auth0.jsまたはその他のSDKを使用している場合には、カスタムドメインの使用にSDKを初期化する必要があります。たとえば、Auth0.js SDKの使用では以下を設定します。

webAuth = new auth0.WebAuth({
  domain: '{yourCustomDomain}',
  clientID: '{yourClientId}'
});

Auth0 SPA SDKでは以下を設定します。

const auth0 = await createAuth0Client({
  domain: '{yourCustomDomain}',
  client_id: '{yourClientId}'
});

カスタムドメインを使用していて、Auth0.jsを用いたManagement APIのアクションを実行する予定の場合には、以下に記載のAPIセクションを参照してください。

Auth0のメールにカスタムドメインを使用したい場合には、この機能を有効化する必要があります。

1. ［Auth0 Dashboard］>［Branding（ブランディング）］>［Custom Domains（カスタムドメイン）］に移動します。

2. ［Use Custom Domain in Emails（メールにカスタムドメインを使用する）］トグルを有効にします。

ソーシャルIDプロバイダー（IdP）でカスタムドメインを使用したい場合には、IdPの［Authorized Redirect URIs（認可されているリダイレクトURI）］リストにカスタムドメイン（https://login.northwind.com/login/callbackなど）を含めて更新する必要があります。

カスタムドメインにはAuth0の開発者キーは使用できません。

Google Workspace接続でカスタムドメインを使用したい場合には、［OAuth Client Settings（OAuthクライアント設定）］の［Authorized Redirect URIs（認可されているリダイレクトURI）］リストを更新する必要があります。Google Developer Consoleで［Credentials（資格情報）］に移動し、使用しているOAuthクライアントをリストから選択すると、クライアントIDやシークレットなどのフィールドを含む設定ページが表示されます。［Authorized redirect URIs（認可されているリダイレクトURI）］フィールドにURLを追加します。URLにはhttps://<YOUR-CUSTOM-DOMAIN>/login/callbackの形式でカスタムドメイン（https://login.northwind.com/login/callbackなど）を含めます。

API識別子（audience）は変更されません。これはそれぞれのAPIに一定の値で、URIが標準的に使用されているにもかかわらず、トークンの取得に使用されるドメインとは完全に無関係です。

Auth0はトークンを発行するのに、トークンの取得に使用したドメインのissクレームを使用します。

audienceを指定する際には、カスタムドメインではなく、使用しているデフォルトのテナントドメイン名（https://{yourDomain}/userinfo、https://{yourDomain}/api/v2/など）を使用します。ここが、デフォルトのテナントドメインを使用する唯一の場所です。

すべての要求（トークン取得や実際のAPI呼び出し）には同じドメインを使用する必要があります。カスタムドメインを通して取得したトークンは、その同じカスタムドメインでAuth0 APIに使用されなければなりません。

また、カスタムドメインを用いた認証フローを使って、Management APIへのアクセスにアクセストークンを要求する場合には、そのカスタムドメインでManagement APIを呼び出す必要があります。

POST https://mycustomdomain.com/oauth/token
... // other parameters 
...
audience:https://defaulttenant.eu.auth0.com/api/v2/

アクセストークン要求は以下のようになるはずです。

GET https://mycustomdomain.com/api/v2/clients

Headers:
Authorization: Bearer <access_token>

Auth0でカスタムドメインを使ってAPIにアクセストークンを発行する場合には、JWTの発行者をカスタムドメインに照らし合わせて検証しなければなりません。たとえば、express-jwtミドルウェアの使用では、以下の変更を行う必要があります。

app.use(jwt({
  issuer: 'https://<YOUR-CUSTOM-DOMAIN>/',
  //code omitted for brevity
}));

SAML IDプロバイダー（IdP）でカスタムドメインを使用する場合には、IDプロバイダーでAssertion Consumer Service（ACS）のURLを更新する必要があります。これは、IdPでの対応に合わせて、以下のいずれかの方法で実行できます。

1. サービスプロバイダーのメタデータをAuth0からhttps://<YOUR-CUSTOM-DOMAIN>/samlp/metadata?connection=<YOUR-CONNECTION-NAME>を使って取得します。これには、更新済みのACS URLが含まれています。そして、IdPの設定でこの値を手動で更新します。IdPに対するこの変更は、アプリケーションでカスタムドメインの使用を始めるのと同時に行わなければなりません。構成するべきIdPが複数ある場合には、これが問題となる可能性があります。

2. IdPに対応があれば、この要件を満たすのに、署名付きの要求を使用することができます。

• 署名証明書をhttps://<TENANT>.auth0.com/pemからダウンロードします。同じ証明書がhttps://<YOUR-CUSTOM-DOMAIN>.com/pemからも返されることに注意してください。

• 証明書をIdPにアップロードして提供します。これで、Auth0がIdPに送信するAuthnRequestメッセージの署名を、IdPが検証できるようになります。

• IdPが証明書をインポートして、必要であれば、署名の検証を有効化します（実際の手順はIdPによって異なります）。

• Dashboardの［Sign Request（要求を署名する）］トグルをオンにします。これは［Connections（接続）］>［Enterprise（エンタープライズ）］>［SAML］>［CONNECTION（接続）］にあります。これで、Auth0がIdPに送信するAuthnRequestのSAMLメッセージが署名されるようになります。

これが完了して、アプリケーションで認証要求を開始したときにカスタムドメインが使用され始めると、IdPが署名付き要求でカスタムドメインを受け取ります。アプリケーションの署名付き要求は信頼されているため、IdPはACS URLとして構成されているものをすべて自動的にオーバーライドし、署名付き要求に含めて送られた値に置き換えます。ただし、署名付き要求内のACS URLを受け付けないIdPもあるため、まず、これが対応されているかを確認する必要があります。

対応されている場合には、1つ以上のIdPで設定が同時に変更できないため、署名付き要求の受け付けを事前に準備できるようになっています。また、後の時点で、静的に構成されたACS URLをIdPの設定で変更することもできます。

SAML IDプロバイダーでカスタムドメインの使用が構成されている場合、Dashboardの［Try（試す）］ボタンは動作しません。Auth0からメタデータをダウンロードするデフォルトのリンクとして、カスタムドメインではなく、デフォルトのドメインが表示されます。

IdP起点の認証フローがある場合には、カスタムドメインの使用について、IdPとアプリケーションを同時に更新する必要があります。

SAMLアプリケーションでカスタムドメインを使用したい（Auth0がIdPである）場合には、Auth0からの新しいIDプロバイダーメタデータでサービスプロバイダーを更新する必要があります。カスタムドメインが更新されたメタデータは、https://<YOUR-CUSTOM-DOMAIN>/samlp/metadata/<YOUR-CLIENT-ID>から取得することができます。Auth0から返されるアサーションの発行者エンティティIDが、カスタムドメインを使用すると変わることに注意してください（例：urn:northwind.auth0.comはカスタムドメインを使用するとurn:login.northwind.comになります）。

IdP起点の認証フローがある場合には、その実行に使用されるURLをカスタムドメインで更新する必要があります。必ず、https://<TENANT>.auth0.com/samlp/<YOUR-CLIENT-ID>ではなく、https://<YOUR-CUSTOM-DOMAIN>/samlp/<YOUR-CLIENT-ID>を使用します。

WS-Fedでカスタムドメインを使用したい（Auth0がIdPである）場合には、Auth0からの新しいIDプロバイダーメタデータでサービスプロバイダーを更新する必要があります。カスタムドメインが更新されたメタデータは、https://<YOUR-CUSTOM-DOMAIN>/wsfed/FederationMetadata/2007-06/FederationMetadata.xmlから取得することができます。

Azure AD接続でカスタムドメインを使用したい場合には、Azure ADの設定で［Allowed Reply URL（許可されている応答URL）］を更新する必要があります。Azure Active Directoryで［Apps registrations（アプリの登録）］に移動して、アプリを選択します。それから、［Settings（設定）］>［Reply URLs（応答URL）］を選択して、カスタムドメインのURLを追加します。URLにはhttps://<YOUR-CUSTOM-DOMAIN>/login/callbackの形式でカスタムドメイン（https://login.northwind.com/login/callbackなど）を含めます。

ADFS接続でカスタムドメインを使用したい場合には、ADFSの設定でエンドポイントを更新する必要があります。これには、コールバックURLがカスタムドメインを使用するように更新しなければなりません。URLにはhttps://<YOUR-CUSTOM-DOMAIN>/login/callbackの形式でカスタムドメイン（https://login.northwind.com/login/callbackなど）を含めます。

Kerberosへの対応が不必要な場合には、AD/LDAP接続をそれ以上構成する必要はありません。

Kerberosに対応したAD/LDAP接続を使用するには、カスタムドメインと動作するようにチケットエンドポイントを更新しなければなりません。Auth0 AD/LDAPコネクターのドキュメントでも説明したように、config.jsonファイルを編集し、カスタムドメインを使用するように、PROVISIONING_TICKET値をhttps://<YOUR-CUSTOM-DOMAIN>/p/ad/jUG0dN0R形式の値に変更します。

この変更を保存したら、AD/LDAPコネクターサービスを再起動して、変更内容を適用する必要があります。

• Auth0管理証明書を使ってカスタムドメインを構成する
• 自己管理証明書を使ってカスタムドメインを構成する
• カスタムドメインのトラブルシューティング
• APIの呼び出しをチェックする
• SAML構成のトラブルシューティング