認可クッキー

Cloudflare Access でサイトを保護すると、Cloudflare はそのサイト宛てのすべての HTTP リクエストを確認し、有効な CF_Authorization クッキーがあることを確かめます。リクエストにクッキーが含まれない場合、Access はそのリクエストをブロックします。

CF_Authorization クッキーには、JSON Web Token (JWT) ↗ としてユーザーの身元が含まれます。Cloudflare は、Cloudflare Access と設定済みアイデンティティプロバイダーの OAUTH または SAML 連携を通じて、これらのトークンを安全に作成します。

Access は、ドメインに応じて 2 種類の CF_Authorization トークンを生成します。

• グローバルセッショントークン: ユーザーが Access にログインしたときに生成されます。このトークンは チームドメイン（例: https://<your-team-name>.cloudflareaccess.com）のクッキーとして保存され、アプリケーションごとにログインし直す必要がなくなります。
• アプリケーショントークン: ユーザーが到達するアプリケーションごとに生成されます。このトークンは保護対象ドメイン（例: https://jira.site.com）のクッキーとして保存され、オリジンで リクエストを検証 するときに使えます。

Cloudflare Access では、1 つの セルフホストアプリケーション で複数ドメインを保護・管理できます。1 つのドメインで認証に成功したあと、同じ Access アプリケーション内の別ドメインへ移動すると、Access は自動で CF_Authorization クッキーを発行します。マルチドメインアプリケーションでは、ユーザーは 1 回認証すれば十分です。

Access は、初回認証時の一連のリダイレクトで、すべてのドメインに事前にクッキーを設定できます。これにより、シングルページアプリケーション（SPA）は、ユーザーが各サブドメインを訪れる前に、他のサブドメインからデータを取得できます。ワイルドカードのサブドメイン（例: *.example.com）には事前クッキーを渡せません。Access がリダイレクト先の具体的なサブドメインを特定できないためです。ワイルドカードのパスはサポートされます。

この動作は Eager redirect cookie 設定で制御します。

次の Access クッキーは、Access の動作に不可欠です。必須と記したクッキーはオプトアウトできません。これらのクッキーはトラッキングや分析には使いません。

Cloudflare Access は、認証済みユーザー向けに Access が生成するブラウザークッキーへ追加できる、任意のセキュリティ設定を提供します。

• SameSite
• HttpOnly フラグ
• Binding cookie
• Cookie path
• Eager redirect cookie

これらの設定を有効にする手順は次のとおりです。

1. Cloudflare ダッシュボード ↗ で、Zero Trust > Access controls > Applications を開きます。
2. 設定するアプリケーションを探し、Configure を選択します。
3. Advanced settings を選択し、Cookie settings までスクロールします。
4. 目的のクッキー設定を構成します。
5. Save を選択します。

SameSite ↗ 属性セレクターは、クッキーの定義サイトとブラウザーでリクエストされているサイトが一致する場合にだけクッキーを送るよう制限します。クロスサイトリクエストフォージェリ（CSRF） ↗ への対策になります。

選択肢は次のとおりです。

• None - クロスオリジンリクエストを含め、すべてのコンテキストでクッキーを送信します。
• Lax - トップレベルのナビゲーションではクッキーの送信を許可し、サードパーティサイトが開始した GET リクエストでも送信します。
• Strict - ファーストパーティのコンテキストでのみクッキーを送信し、サードパーティサイトが開始したリクエストでは送信しません。

詳細は Mozilla のドキュメント ↗ を参照してください。

特定のアプリケーションの認可クッキーに依存する追加サイトやアプリケーションがある場合は、SameSite 制限を有効にしないでください。

HttpOnly フラグは、クライアントサイドスクリプトからのクッキーアクセスを防ぎ、クロスサイトスクリプティング（XSS）攻撃の可能性を下げるクッキー属性です。このフラグはデフォルトで有効です。

次の場合は HttpOnly を有効にしないでください。

• SSH や RDP など、ブラウザー以外のツール向けに Access アプリケーションを使っている場合。
• Access が生成したユーザーのクッキーへアクセスする必要があるソフトウェアがある場合。

Binding cookie（CF_Binding）は、ユーザーの認証成功時に発行される任意のクッキーです。ユーザーのブラウザーが送信し、特定アプリケーションの CF_Authorization クッキーに紐づきます。このクッキーは Cloudflare のネットワークで取り除かれ、オリジンサーバーへは転送されません。

CF_Authorization クッキーは、対応する Binding cookie なしでは使えません。盗まれた CF_Authorization クッキーの再利用を防ぎます。有効な CF_Authorization クッキーがあっても、想定される Binding cookie がないリクエストは、Cloudflare のネットワークで拒否されます。

次の場合は Binding Cookie を有効にしないでください。

• SSH や RDP など、ブラウザー以外のツール向けに Access アプリケーションを使っている場合。
• アプリケーションドメインで 互換性のない Cloudflare プロダクト（Zaraz や Google tag gateway など）を有効にしている場合。これらのプロダクトと Binding Cookie を同時に有効にすると、認証のリダイレクトループ（ERR_TOO_MANY_REDIRECTS）が起きることがあります。
• アプリケーションで Authenticate with Cloudflare One Client をオンにしている場合。

Cookie Path 属性は、アプリケーションのパス URL を CF_Authorization クッキーに追加します。有効にすると、example.com/path1 にログインしたユーザーは、example.com/path2 にアクセスするために再認証が必要です。無効の場合、CF_Authorization クッキーはドメインとサブドメインにのみスコープされます。

Eager redirect cookie 設定をオンにすると、マルチドメインアプリケーション内のすべての具体的なドメインに、事前に CF_Authorization クッキーを設定します。ユーザーの初回認証後、Access はブラウザーを各ドメイン経由でリダイレクトします。新しいアプリケーションでは、この設定はデフォルトでオンです。

一部のブラウザーは、プライベートブラウジングモードですべてのサードパーティクッキー（CF_Authorization クッキーを含む）をデフォルトでブロックします。プライベートウィンドウで XHR リクエストを動かすには、アプリケーションと チームドメイン を、ブラウザーのトラッキング防止から除外する必要があります。

Access アプリケーションでサードパーティクッキーを有効にする手順は次のとおりです。