コンテンツにスキップ

認証クッキー

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

Access JWTs

CF_Authorizationクッキーには、ユーザーのアイデンティティがJSON Web Token（JWT）の形式で含まれています。Cloudflareは、Cloudflare Accessと設定されたアイデンティティプロバイダーとの間のOAUTHまたはSAML統合を通じて、これらのトークンを安全に作成します。

2つのトークンが生成されます：

  • グローバルセッショントークン: ユーザーがAccessにログインしたときに生成されるトークン。このトークンは、あなたのチームドメイン（例: https://<your-team-name>.cloudflareaccess.com）にクッキーとして保存され、ユーザーが各アプリケーションにログインする必要がなくなります。

  • アプリケーショントークン: ユーザーがアクセスする各アプリケーションのために生成されるトークン。このトークンは、保護されたドメイン（例: https://jira.site.com）にクッキーとして保存され、あなたのオリジンでリクエストを検証するために使用されることがあります。

マルチドメインアプリケーション

Cloudflare Accessは、単一のセルフホストアプリケーションで複数のドメインを保護および管理することを可能にします。ユーザーが1つのドメインに正常に認証されると、Accessは同じAccessアプリケーション内の別のドメインに移動する際に自動的にCF_Authorizationクッキーを発行します。これにより、ユーザーはマルチドメインアプリケーションに対して一度だけ認証すればよくなります。

5つ以下のドメインを持つAccessアプリケーションの場合、Accessは一連のリダイレクトを通じてすべてのドメインに対してクッキーを事前に設定します。これにより、シングルページアプリケーション（SPA）が、ユーザーが明示的に訪れていないサブドメインからデータを取得できるようになります。ただし、ワイルドカードサブドメインに対しては事前にクッキーを設定できません。なぜなら、どの具体的なサブドメインにリダイレクトするかがわからないからです（ワイルドカードパスは許可されています）。

Accessアプリケーションが5つ以上のドメインを持つ場合、Accessは事前にクッキーを設定しません。クッキーは、ユーザーが各ドメインを訪れるときにのみ発行されます。この制限は、ユーザーエクスペリエンスに影響を与える可能性のあるレイテンシの問題を避けるためです。

クッキー設定

Cloudflare Accessは、認証されたユーザーのためにAccessによって生成されたブラウザクッキーに追加できるオプションのセキュリティ設定を提供します。

これらの設定を有効にするには：

  1. Zero Trust ↗に移動し、Access > Applicationsを選択します。

  2. 設定したいアプリケーションを見つけてEditを選択します。

  3. Settingsを選択し、Cookie settingsまでスクロールします。

  4. 希望するクッキー設定を構成します。

  5. Save applicationを選択します。

SameSite属性

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

セレクタのオプションは次のとおりです：

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

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

SameSiteを使用しない場合

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

HttpOnly

HttpOnlyフラグは、クッキーがクライアント側のスクリプトによってアクセスされるのを防ぎ、クロスサイトスクリプティング（XSS）攻撃の可能性を減らすクッキー属性です。このフラグはデフォルトで有効になっています。

HttpOnlyを使用しない場合

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

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

バインディングクッキー

バインディングクッキーは、ユーザーが正常に認証されたときに作成され、Cloudflareと共有されてアイデンティティを確認し、オリジンサーバーに到達する前に削除される追加のクッキーです。バインディングクッキーは、ブラウザをAccessトークンに関連付けます。この関連付けは、オリジンのWebアプリがこのバインディングクッキーを決して見ることがないため、権限トークンが侵害されるのを防ぎます。これにより、セッションハイジャックスタイルの攻撃から保護されます。

バインディングクッキーを使用しない場合

次の場合はバインディングクッキーを有効にしないでください：

クッキーパス属性

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

ブラウザでのサードパーティクッキーの許可

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

Accessアプリケーションのためにサードパーティクッキーを有効にするには：

Chrome
  1. Settings > Privacy and security > Cookies and other site dataに移動します。
  2. Sites that can always use cookiesの下に、次のURLを追加します：
    • Accessアプリケーションのホスト名（例: https://jira.site.com）
    • https://<your-team-name>.cloudflareaccess.com

Safari
  1. Safari > Settings > Privacyに移動します。
  2. Block all cookiesのチェックを外します。

Firefox
  1. Settings > Privacy & Securityに移動します。
  2. Cookies and Site Dataまでスクロールします。
  3. Manage Exceptionsを選択します。
  4. AccessアプリケーションのURL（例: https://jira.site.com）を入力し、Allowを選択します。
  5. https://<your-team-name>.cloudflareaccess.comを入力し、Allowを選択します。
  6. Save Changesを選択します。

Brave
  1. brave://settings/cookiesに移動します。
  2. Sites that can always use cookiesの下に、次のURLを追加します：
    • Accessアプリケーションのホスト名（例: https://jira.site.com）
    • https://<your-team-name>.cloudflareaccess.com
Cloudflare DashboardDiscordCommunityLearning CenterSupport Portal
Cookie Settings