Skip to main content
複数のカスタムドメインを使用する場合は、認証時に適切なカスタムドメインを使用するよう、Auth0 SDK を設定する必要があります。このガイドでは、さまざまなプラットフォームやシナリオにおける SDK の設定方法について説明します。

主な概念

ドメイン パラメーター

すべての Auth0 SDK では、認証に使用する Auth0 ドメインを指定する domain パラメーターが必要です。カスタムドメインを使用する場合は、このパラメーターに Auth0 の標準ドメインではなく、カスタムドメインを設定します。 カスタムドメインを使用しない場合:
カスタムドメインを使用する場合:

トークンの発行元

カスタムドメインを使用している場合、トークンの iss (発行元) クレームには、カスタムドメインが設定されます。
トークン検証で、カスタムドメインを有効な発行元として受け入れるように設定する必要があります。

認証 SDK

MCD を使用する場合、すべてのカスタムドメインの提供と検証はお客様の責任となります。SDK でドメインリゾルバー関数を使用してテナントのカスタムドメインを解決するよう設定する場合は、解決されるすべてのドメインが信頼できるものであることをお客様自身で必ず確認してください。ドメインリゾルバーの設定を誤ると、relying party で認証がバイパスされたり、アプリケーションがサーバーサイドリクエストフォージェリにさらされたりする可能性があります。ドメインおよびプロキシサーバーを適切に設定しないと、重大なセキュリティ脆弱性が生じるおそれがあり、これについて Okta は責任を負いません。

Auth0 SPA SDK (JavaScript)

Auth0 SPA SDK を使用するシングルページアプリケーションの場合は、次のように設定します。

Next.js

Auth0 Next.js SDK (v4+) を使用する Next.js アプリケーションの場合: Next.js で MCD を使用する際の主な概念:
  • 単一の Auth0 テナント、複数のドメイン: すべてのカスタムドメインは同じ Auth0 テナントに属するため、同じ clientIdclientSecret を共有します。
  • DomainResolver 関数: domain パラメータには、関数 (config: { headers: Headers; url?: URL }) => Promise<string> | string を指定できます。これにより、受信したリクエストヘッダーに基づいて、リクエストごとに動的にドメインを解決できます。
  • インスタンスキャッシュ: SDK は、パフォーマンス向上のために、制限付き LRU キャッシュ (最大 100 エントリ) を使用して、ドメインごとに Auth0Client インスタンスを自動的にキャッシュします。
  • セッションの分離: あるカスタムドメイン経由で作成されたセッションはそのドメインに限定されるため、別のドメインのセッションと相互に使用することはできません。
  • URL パラメータ: リゾルバ内の url パラメータは、Server Components と Server Actions では undefined です。使用できるのは middleware または API ルート内のみです。
  • ディスカバリキャッシュの調整: discoveryCache オプションを使用して OIDC メタデータのキャッシュを設定します。

Auth0 React SDK

React アプリケーションで Auth0 React SDK を使用する場合:
複数ドメインの構成では:

Auth0.js

Auth0.js を使用するアプリケーションの場合:

Node.js (Express)

express-openid-connect を使用する Node.js アプリケーションでは、
マルチテナントのシナリオでは:

モバイル向け SDK

iOS (Swift)

Auth0.swiftを使用する場合:
ドメインを動的に選択する場合:

Android (Kotlin)

Auth0.Android を使用する場合は:
複数ドメインをサポートするには:

React Native

react-native-auth0 を使用する場合は、次のとおりです。

Flutter

flutter_auth0 を使用する場合:

Management SDKs

Management SDK は、Auth0 の Management API と連携するために使用します。カスタムドメインを使用している場合は、auth0-custom-domain ヘッダーを含めるか、デフォルトドメインを使用する必要がある場合があります。

Node.js Management SDK

Python Management SDK

Go Management SDK

トークンの検証

カスタムドメインを使用する場合は、発行元としてカスタムドメインを許可するようにトークン検証を更新します。

Node.js (Express)

express-jwt または jose を使用する場合:
複数のカスタムドメインを使用する場合:

Python (Flask)

python-jose を使用する場合は、以下のとおりです。

Java (Spring Boot)

Spring Security を使用する場合:

環境ごとの設定

環境ごとにカスタムドメインを管理するには、環境変数を使用します。

.env ファイルの構成

設定の読み込み

トラブルシューティング

よくある問題

問題原因解決策
発行元 が無効というエラートークン検証では正規ドメインを想定していますが、実際にはカスタムドメインを受け取っています発行元 としてカスタムドメインを許可するようにトークン検証を更新します
JWKS の取得に失敗するJWKS URI が正規ドメインを指していますJWKS URI がカスタムドメインを使用するように更新します: https://custom-domain/.well-known/jwks.json
リダイレクト URI の不一致コールバック URL が設定されているリダイレクト URI と一致していませんアプリケーション設定にカスタムドメインのコールバック URL を追加します
クロスオリジン エラー (CORS) 許可されたオリジンにカスタムドメインが含まれていませんアプリケーション設定の Allowed Web Origins にカスタムドメインを追加します
Lock の読み込みに失敗するconfigurationBaseUrl が設定されていませんリージョン別 CDN URL を指定して configurationBaseUrl パラメーターを追加します

ベストプラクティス

  1. 環境変数を使用する: カスタムドメインは環境ごとの設定ファイルに保存します
  2. 複数の発行元を検証する: 複数のカスタムドメインを使用する場合は、それらすべてを有効な発行元として受け入れるようにトークン検証を設定します
  3. コールバック URL を更新する: すべてのカスタムドメインが、アプリケーション設定の Allowed Callback URLs に追加されていることを確認します
  4. 十分にテストする: 本番環境に移行する前に、各カスタムドメイン経由の認証をテストします
  5. トークンの発行元を監視する: トークン内の iss クレームを記録して監視し、正しいカスタムドメインが使用されていることを確認します
  6. ドメインマッピングを文書化する: どのアプリケーションがどのカスタムドメインを使用しているかを、明確に文書化して維持します
  7. 障害を適切に処理する: 認証の失敗に対する適切なエラーハンドリングを実装します
  8. JWKS をキャッシュする: パフォーマンスを向上させ、リクエスト数を減らすために JWKS データをキャッシュします

詳細