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 はパフォーマンス向上のため、Auth0Client インスタンスをドメインごとに上限付きの LRU キャッシュ (最大 100 エントリ) で自動的にキャッシュします。
  • セッションの分離: あるカスタムドメイン経由で作成されたセッションはそのドメインに限定され、別のドメインのセッションと相互に使い回すことはできません。
  • URL パラメータ: リゾルバー内の url パラメータは、Server Components と Server Actions では undefined です。利用できるのは middleware または API ルート内のみです。
  • Discovery キャッシュの調整: 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 SDKs は、Auth0 Management API を操作するために使用されます。カスタムドメインを使用する場合は、auth0-custom-domain ヘッダーを含めるか、デフォルトドメイン を使用する必要があることがあります。

Node.js 管理用 SDK

Python向け管理SDK

Go向け管理SDK

トークンの検証

カスタムドメインを使用する場合は、トークンの検証で発行者としてカスタムドメインを受け入れるよう更新してください。

Node.js (Express)

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

Python (Flask)

python-jose を使用する場合:

Java (Spring Boot)

Spring Security を使用する場合:

環境ごとの設定

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

.env ファイルの構造

設定の読み込み

トラブルシューティング

よくある問題

問題原因解決策
発行者 が無効というエラーtoken の検証では正規ドメインを想定しているが、カスタムドメインを受け取っている発行者 としてカスタムドメインを受け入れるよう、token の検証を更新する
JWKS の取得に失敗するJWKS URI が正規ドメインを指しているJWKS URI がカスタムドメインを使用するように更新する: https://custom-domain/.well-known/jwks.json
リダイレクト URI の不一致callback URL が設定済みのリダイレクト URI と一致していないカスタムドメインの callback 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データをキャッシュします

詳細はこちら