主な概念
ドメイン パラメーター
domain パラメーターが必要です。カスタムドメインを使用する場合は、このパラメーターに Auth0 の標準ドメインではなく、カスタムドメインを設定します。
カスタムドメインを使用しない場合:
トークンの発行元
iss (発行元) クレームには、カスタムドメインが設定されます。
認証 SDK
MCD を使用する場合、すべてのカスタムドメインの提供と検証はお客様の責任となります。SDK でドメインリゾルバー関数を使用してテナントのカスタムドメインを解決するよう設定する場合は、解決されるすべてのドメインが信頼できるものであることをお客様自身で必ず確認してください。ドメインリゾルバーの設定を誤ると、relying party で認証がバイパスされたり、アプリケーションがサーバーサイドリクエストフォージェリにさらされたりする可能性があります。ドメインおよびプロキシサーバーを適切に設定しないと、重大なセキュリティ脆弱性が生じるおそれがあり、これについて Okta は責任を負いません。
Auth0 SPA SDK (JavaScript)
Next.js
- 単一の Auth0 テナント、複数のドメイン: すべてのカスタムドメインは同じ Auth0 テナントに属するため、同じ
clientIdとclientSecretを共有します。 - 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
Auth0.js
Node.js (Express)
モバイル向け SDK
iOS (Swift)
Android (Kotlin)
React Native
Flutter
Management SDKs
auth0-custom-domain ヘッダーを含めるか、デフォルトドメインを使用する必要がある場合があります。
Node.js Management SDK
Python Management SDK
Go Management SDK
トークンの検証
Node.js (Express)
Python (Flask)
Java (Spring Boot)
環境ごとの設定
.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 パラメーターを追加します |
ベストプラクティス
- 環境変数を使用する: カスタムドメインは環境ごとの設定ファイルに保存します
- 複数の発行元を検証する: 複数のカスタムドメインを使用する場合は、それらすべてを有効な発行元として受け入れるようにトークン検証を設定します
- コールバック URL を更新する: すべてのカスタムドメインが、アプリケーション設定の Allowed Callback URLs に追加されていることを確認します
- 十分にテストする: 本番環境に移行する前に、各カスタムドメイン経由の認証をテストします
- トークンの発行元を監視する: トークン内の
issクレームを記録して監視し、正しいカスタムドメインが使用されていることを確認します - ドメインマッピングを文書化する: どのアプリケーションがどのカスタムドメインを使用しているかを、明確に文書化して維持します
- 障害を適切に処理する: 認証の失敗に対する適切なエラーハンドリングを実装します
- JWKS をキャッシュする: パフォーマンスを向上させ、リクエスト数を減らすために JWKS データをキャッシュします