Cloudflare をリバースプロキシとして構成する

Auth0 のカスタムドメイン用プロキシとして使用するための Cloudflare の設定方法について説明します。

利用可否は Auth0 プランによって異なります

この機能を利用できるかどうかは、Auth0 プランまたはカスタム契約によって異なります。詳しくは、Auth0 の料金ページを参照してください。

推奨される方法で Cloudflare をリバースプロキシとして設定するには、以下の機能を備えた Cloudflare Enterprise Plan が必要です。

機能	説明
Host Header Override	Cloudflare の各種ルールを使用して Host ヘッダーを書き換えます。詳しくは、Cloudflare Docs の Rewrite Host headersを参照してください。
True-Client-IP Header	True-Client-IP Header を有効にすると、オリジンサーバーへのすべてのリクエストに、エンドユーザーの IP アドレスを含む True-Client-IP ヘッダーが追加されます。詳しくは、Cloudflare の Understanding the True-Client-IP Headerを参照してください。

​

Cloudflare を設定する

前提条件として、選択したカスタムドメインの親ドメインを Cloudflare ダッシュボードで追加して有効化しておく必要があります。また、使用するカスタムドメインが Cloudflare ゾーン内にまだ存在していないことも確認してください。すでに存在する場合、Cloudflare の検証は失敗します。

Cloudflare をリバースプロキシとして設定するには、Cloudflare で CNAME レコード、Page Rule、Transform Rule を作成する必要があります。

1. まだ設定していない場合は、自己管理証明書を使用して カスタムドメイン を設定および検証します。後で必要になるため、Origin Domain Name と cname-api-key の値を控えておいてください。

2. 対象ゾーンの Cloudflare ダッシュボードで、次の設定を使用して CNAME レコードを作成します。

   Setting	Value
   名前	カスタムドメイン名
   Target	先ほど控えた Origin Domain Name の値
   Proxy Status	Proxied

3. 選択したカスタムドメイン配下のすべての URL を対象として、次の設定で Page Rule を作成します。

   Setting	Value
   Host Header Override	先ほど控えた Origin Domain Name の値
   True-Client-IP	Enable

4. Transform Rule を作成します。

   Page Rule と Transform Rule の代わりに Cloudflare Workers を使用して、自己管理証明書のカスタムドメイン要件を満たすリバースプロキシを設定することもできますが、カスタムコードが不要になるため、ルールベースの方法を推奨します。

   1. Modify Request Header ビューに切り替えます。

   2. Create Rule を選択し、任意の名前を指定します。

   3. When incoming requests match で Custom filter expression を選択し、選択したカスタムドメインに関連するリクエストだけを対象にする式を設定します。たとえば、Hostname フィールドの完全一致を使用します。

   4. Modify request header で Set static を選択し、次のフィールドを設定します。

      Field	Value
      Header name	cname-api-key
      Value	先ほど控えた cname-api-key の値

5. 選択したカスタムドメインで Always Use HTTPS が有効になっており、encryption mode が少なくとも Full に設定されていることを確認します。

​

Managed Challenges を使用する

Cloudflare の Managed Challenges を使用すると、リクエストが Auth0 Universal Login に到達する前に、ボットによるトラフィックをフィルタリングできます。リクエストがルールに一致すると、Cloudflare がそのリクエストを横取りし、検証チャレンジを表示します。チャレンジページは HTML を返すため、Managed Challenges と互換性があるのはブラウザベースのフローのみです。これを API エンドポイントやヘッドレスフローに適用すると、クライアントは想定されたレスポンスではなく HTML のチャレンジページを受け取ることになるため、それらのフローは動作しなくなります。

​

Universal Login のブラウザベースのエンドポイント

次のエンドポイントはブラウザに HTML ページを返し、Managed Challenges に対応しています。

Endpoint	Description
/u/email-verification	メールアドレスの確認
/u/login	識別子プロンプトおよび identifier-first プロンプト
Organization endpoints: u/organization /u/organization-picker /u/pre-organization-picker	組織選択プロンプト
/u/login/password	パスワードプロンプト
/u/login-email-verification	メールアドレス確認プロンプト
/u/signup	識別子プロンプト
/u/signup/password	パスワードプロンプト
/u/consent	同意プロンプト
/u/customized-consent	カスタマイズされた同意プロンプト
/u/reset-password	パスワードリセットプロンプト
/u/reset-password/request	パスワードリセット用のメールアドレスまたはusernameプロンプト
/u/reset-password/change	新しいパスワードのプロンプト
/u/reset-verify	パスワードリセットの確認
/u/mfa-begin-enroll-options	MFA登録の認証要素選択
/u/mfa-enroll-options	MFA登録オプション
/u/mfa-otp	OTP プロンプト
/u/mfa-push	プッシュ通知プロンプト
/u/mfa-webauthn	WebAuthn およびパスキープロンプト
/u/mfa-recovery-code	リカバリーコードプロンプト
/u/mfa-sms	SMS プロンプト
/u/mfa-email	MFA メールアドレスプロンプト
/u/mfa-voice	MFA 音声プロンプト
/u/passkey-enrollment	パスキー登録

Classic Universal Login を使用している場合は、Managed Challenge ルールに /login も含めてください。

​

除外するエンドポイント

次のエンドポイントには Managed Challenge を適用しないでください。これらはサーバー、SDK、またはリソースサーバーから呼び出されるため、インタラクティブなチャレンジには対応できません。

エンドポイント	説明
/oauth/token	トークンエンドポイント
/oauth/revoke	トークン失効エンドポイント
/userinfo	UserInfo エンドポイント
/.well-known/openid-configuration	OIDC ディスカバリドキュメント
/.well-known/jwks.json	JSON Web Key Set。リソースサーバーがトークンを検証するために取得します
/api/v2/*	Management API
/co/authenticate	クロスオリジン認証
/dbconnections/signup	データベース接続: サインアップ
/dbconnections/change_password	データベース接続: パスワード変更
/usernamepassword/login	Classic Universal Login のフォーム送信
/mfa/challenge	チャレンジリクエスト
/mfa/associate	認証器の関連付け
/passwordless/start	パスワードレス: 開始リクエスト
/samlp/*	SAML プロトコルエンドポイント
/wsfed/*	WS-Federation エンドポイント
/v2/logout	バックチャネルログアウトフローではサーバー側から呼び出される場合があります

​

ルールの例

Managed Challenge をブラウザベースの Universal Login フローにのみ適用するには、Cloudflare で WAF Custom Rule を作成します。ルールのアクションを Managed Challenge に設定し、次の式を使用します。YOUR_CUSTOM_DOMAIN はカスタムドメイン (たとえば login.example.com) に置き換えてください。

(http.host eq "YOUR_CUSTOM_DOMAIN" and (
  http.request.uri.path eq "/authorize" or
  starts_with(http.request.uri.path, "/u/") or
  http.request.uri.path eq "/login"
))

これにより、チャレンジの適用対象はブラウザ表示を伴う Universal Login エンドポイントのみに限定され、API トラフィックやマシン間通信への影響を防げます。

いくつかのユースケースでは、動作が異なる場合があります。

• クリアランス Cookie の維持: ブラウザーが Managed Challenge を通過すると、Cloudflare は通常、セッション中有効なクリアランス Cookie を発行します。設定によっては、ルールの適用対象を /authorize のみに限定するだけで、すべての /u/* パスに適用しなくても Universal Login フロー全体をカバーできる場合があります。
• OAuth 以外のエントリポイント: SAML の SP 開始型または WS-Federation のエントリポイントから始まるフローでは、/authorize ではなく /samlp/* または /wsfed/* が使用されます。これらのパスは除外リストに含まれているため、Managed Challenge を適用しないでください。

​

Auth0 を設定する

リクエストボディに次のペイロードを指定して、Auth0 の Management API の カスタムドメイン設定を更新 エンドポイントを呼び出します。

{
  "custom_client_ip_header": "true-client-ip"
}

​

詳しくはこちら

• カスタムドメインで使用する機能を設定する
• カスタムドメインのトラブルシューティング
• TLS (SSL) のバージョンと暗号スイート