セッション管理

ユーザーセッションは、再認証なしで Access アプリケーションにアクセスできる期間を決めます。

Access で保護されたアプリケーションにユーザーがログインすると、Access は Access ポリシーに照らして ID を検証し、署名済みの JSON Web Token（JWT）を 2 つ発行します。

ユーザーは、アプリケーショントークンの有効期間中、アプリケーションにアクセスできます。アプリケーショントークンの期限が切れたとき、グローバルトークンがまだ有効で、ユーザーの ID が Access ポリシーを満たしていれば、Cloudflare は新しいアプリケーショントークンを自動で発行します。グローバルトークンも期限切れの場合は、IdP での再認証が求められます。

グローバルトークンの有効期限は、通常、アプリケーショントークンと同じか、それより長く設定します。グローバルトークンを長くすると、より安全に長いユーザーセッションを許可できます。グローバルトークンでは、アプリケーションへ直接アクセスできないためです。

まとめると、Access は次の順（具体的なものから一般的なもの）でセッションを確認します。

1. クライアントセッション（有効な場合）— ほかの有効期間より優先されます。期限切れになると、ユーザーは再認証します。
2. ポリシーセッション — 特定のポリシーに一致するユーザーの、特定アプリケーションへのアクセスを制御します。
3. アプリケーションセッション — そのアプリケーション内の全ポリシーに対する、デフォルトのポリシーセッション有効期間です。
4. グローバルセッション — 全アプリケーションで、ユーザーが IdP にログインし直す頻度を制御します。

フローチャートは 適用順序 を参照してください。

グローバルセッションの有効期間は、Cloudflare Access がユーザーにアイデンティティプロバイダーへのログインを求める頻度を決めます。15 分から 1 か月のあいだで設定できます。デフォルトは 24 時間です。

グローバルセッションの有効期間を設定するには:

1. Cloudflare ダッシュボード ↗ で、Zero Trust > Access controls > Access settings を開きます。
2. Set your global session duration で Edit を選択します。
3. ドロップダウンから希望のタイムアウト時間を選択します。
4. Save を選択します。

この期間が過ぎると、ユーザーは IdP で再認証する必要があります。

ポリシーセッションの有効期間は、ユーザーがセルフホストの Access アプリケーションにアクセスできる時間を決めます。セッションが期限切れになると、Access は保存済みのユーザー ID を、アプリケーションの Access ポリシーに照らして再確認します。

デフォルトでは、ポリシーセッションの有効期間は アプリケーションセッションの有効期間 と同じです。特定ユーザー向けにより細かい権限を設定するには、即時タイムアウトから 1 か月までの値に変更できます。たとえば、エンジニア向けのアプリケーションセッションを 7 日にし、契約社員向けのポリシーセッションを 24 時間にする、といった使い方ができます。

ポリシーセッションの有効期間を設定するには:

1. Cloudflare ダッシュボード ↗ で、Zero Trust > Access controls > Policies を開きます。
2. ポリシーを選び、Configure を選択します。
3. ドロップダウンから Session Duration を選択します。
4. ポリシーを保存します。

このポリシーに一致するユーザーには、この有効期限のアプリケーショントークンが発行されます。

アプリケーションセッションの有効期間は、Access アプリケーション内の全ポリシーに対するデフォルトの ポリシーセッション有効期間 です。即時タイムアウトから 1 か月まで設定できます。デフォルトは 24 時間です。

アプリケーションセッションの有効期間を設定するには:

1. Cloudflare ダッシュボード ↗ で、Zero Trust > Access controls > Applications を開きます。
2. アプリケーションを選び、Configure を選択します。
3. ドロップダウンから Session Duration を選択します。
4. アプリケーションを保存します。

Same as application session timeout の有効期間が設定されたポリシーに一致するユーザーには、この有効期限のアプリケーショントークンが発行されます。

Application session durations が制御するのは SaaS アプリの入り口だけです。Access は、ユーザーが SaaS アプリ内にどれだけ長く滞在できるかは制御しません。たとえば、ユーザーが SaaS アプリからログアウトして再度アクセスした場合、有効な Access application token があれば、もう一度ログインしなくても再認証できます。SaaS アプリは、アプリ内のユーザーセッションを管理する独自の認可 Cookie を発行します。

Cloudflare は、アクティブな SSH、VNC、RDP セッションの長さを制御しません。アプリケーションセッションの有効期間 は、ユーザーが新しい接続を開始できる、または既存の接続を更新できる時間枠を決めます。

Access アプリケーションで Authenticate with Cloudflare One Client が有効な場合、Cloudflare One Client のセッション有効期間が、ほかのすべてのセッション有効期間（アプリケーション、ポリシー、グローバル）より優先されます。Cloudflare One Client のセッションが有効で、ユーザーが Cloudflare One Client を実行しているあいだは、グローバルセッションが期限切れでも、IdP での再認証は求められません。

デフォルトでは、Cloudflare One Client の認証に失敗したリクエストは、Access のログインページへ 302 でリダイレクトされます。API クライアント、コマンドラインツール、自動化処理は、このブラウザーログインを完了できないことがよくあります。代わりに、ブラウザー以外のトラフィックへ 401 Unauthorized を返すようにできます。クライアントは認証失敗を直接検知できます。

この動作を有効にするには:

1. Cloudflare ダッシュボード ↗ で、Zero Trust > Access controls > Access settings を開きます。
2. Cloudflare One Client authentication で、Enable authentication using the Cloudflare One Client session がオンになっていることを確認します。
3. Return 401 response for non-browser traffic をオンにします。

Update your Zero Trust organization API で warp_auth_non_browser_401 を true に設定することもできます。

このアカウント設定は、Cloudflare One Client の認証失敗にだけ適用されます。個別の Access アプリケーションの Service Auth 動作を制御する service_auth_401_redirect とは別です。

独立した多要素認証（MFA） を使う場合、MFA セッションの有効期間は、MFA を求められずに Cloudflare Access へログインできる時間を決めます。MFA セッションは、グローバル、ポリシー、アプリケーションの各セッション有効期間とは独立しています。MFA が有効 な Access アプリへログインするとき、前回の MFA 認証が設定した有効期間の外であれば、ユーザーは MFA チャレンジを完了する必要があります。アイデンティティプロバイダーでの認証のあと、MFA が求められます。CF_Device cookie により、両方の認証ステップが同じデバイスで行われます。MFA セッションの有効期間は、ユーザーがアプリケーションへアクセスできる時間には影響しません（アクセス時間は アプリケーショントークン が制御します）。

次のフローチャートは、セルフホストアプリケーションに対して Access がユーザーセッションを適用する流れです。

flowchart TB
    %% Accessibility
    accTitle: Access のセッション有効期間
    accDescr: Access セッションの適用順序を示すフローチャート

    %% In with user traffic
    start["ユーザーが Access アプリケーションへアクセス"]
    start--"このアプリケーションで有効" -->warpsession[Cloudflare One Client セッションの期限切れ?]
    start-- "このアプリケーションで無効" --> policysession[ポリシーセッションの期限切れ?]

		warpsession--"はい"-->idp[IdP へのログインを求める]
		warpsession--"いいえ"-->accessgranted[アクセスを許可]

		policysession--"はい"-->globalsession[グローバルセッションの期限切れ?]
		policysession--"いいえ"-->accessgranted

		globalsession--"はい"-->idp
		globalsession--"いいえ"-->refreshtoken[Access ポリシーで ID を再確認]
		refreshtoken-->accessgranted
		idp-->refreshtoken

Access には、ユーザーセッションを取り消す方法が 2 つあります。アプリケーション単位とユーザー単位です。

特定アプリケーションのアクティブなセッションをすぐに終了するには:

1. Cloudflare ダッシュボード ↗ で、Zero Trust > Access controls > Applications を開きます。
2. アクティブセッションを取り消したいアプリケーションを探し、Configure を選択します。
3. Revoke existing tokens を選択します。

ポリシーのルールに変更がなければ、アイデンティティプロバイダー上のプロファイルがまだ有効なユーザーは、新しいセッションを開始できます。

Access は、アカウント内の全アプリケーションにわたって、1 人のユーザーセッションをすぐに取り消せます。ただし、ユーザーの ID プロファイルがまだ有効なら、新しいセッションを発行できます。

ユーザーのアクセスを永続的に取り消すには:

1. アイデンティティプロバイダーでアカウントを無効にし、認証できないようにします。
2. Cloudflare ダッシュボード ↗ で、Zero Trust > Team & Resources > Users を開きます。
3. 取り消すユーザーのチェックボックスをオンにします。
4. Action > Revoke を選択します。

そのユーザーは、Access で保護されたどのアプリケーションにもログインできなくなります。アカウントから ユーザーを削除 するまで、シート課金の対象には含まれます。

管理者がユーザーの Cloudflare Access トークンを取り消したあと、そのユーザーは最大 1 分間ログインできません。ログインを試みると、Cloudflare Access はエラーを表示します。

Access からログアウトするには、エンドユーザーは次のいずれかの URL を開きます。

• <your-application-domain>/cdn-cgi/access/logout
• <your-team-name>.cloudflareaccess.com/cdn-cgi/access/logout

この操作は、全アプリケーションにわたって ユーザーのセッションを取り消します。Access はユーザーのブラウザーから認可 cookie をすぐに削除し、すでに発行済みのトークンは 20〜30 秒後に受け付けられなくなります。2 つの URL の違いは、認可 cookie を削除するドメインだけです。たとえば <your-application-domain>/cdn-cgi/access/logout を開くと、アプリケーション cookie が削除され、ログアウトがより即座に感じられます。

これらの URL を使い、アプリケーション内にカスタムのログアウトボタンやリンクを作れます。

AJAX やシングルページアプリケーションに大きく依存するページでは、Access トークンの期限切れによってサブリクエストがブロックされ、ユーザーに再認証が求められないことがあります。

期限切れのセッショントークンを持つサブリクエストに対して、Access が 401 を返すように設定できます。このレスポンスコードでページを再読み込みするか、セッション期限切れのメッセージをユーザーに表示することをおすすめします。

期限切れセッションで 401 を受け取るには、すべての AJAX リクエストに次のヘッダーを追加します。

X-Requested-With: XMLHttpRequest