夜間のバッチやCIのジョブ、外部のSaaSからのWebhookが、Cloudflare Accessで保護した社内のAPIや管理画面を呼んでいる。人のログインの代わりに「サービストークン」（Client IDとClient Secretの組）をヘッダーに付けて通している構成では、10月に加わった設定によって、失敗したときの返り方と、通るリクエストの条件が変わります。
Cloudflareは2026年10月2日、Accessに「Strict service token authentication」（サービストークン認証の厳格化）という組織単位の設定を追加しました。2026年10月5日以降に作られたZero Trustの組織では最初からオンで、オフにできません。それより前に作られた組織では、オン・オフを選べます。Cloudflareは既存の組織にもオンにするよう勧めています。
Zero Trust organizations created on or after October 5, 2026 have strict service token authentication turned on by default and cannot turn it off. Cloudflare recommends that existing organizations turn it on as well.
オンにすると変わる4つのこと
変更履歴とサービストークンのドキュメントによると、設定がオンのとき、サービストークンのヘッダーが付いたリクエストを、Accessは次のように扱います。
| 項目 | オンにしたとき |
|---|---|
| 認証・認可に失敗したとき | ログイン画面への 302 のリダイレクトではなく、常に 401 か 403 を返す |
| 通すポリシー | Service Authのポリシーだけで判定する。Allowのポリシーと、送られてきた CF_Authorization クッキーは無視する |
| 成功したとき | CF_Authorization クッキーを返さない。以後のリクエストもサービストークンのヘッダーで送る |
| ログ | 認識できたサービストークンでの失敗を、Accessの認証ログに残す（期限切れ・無効のトークン、Client Secretの誤り、そのアプリに許可されていないトークン）。形式の崩れたヘッダーや未知のClient IDは残さない |
1つ目は、自動処理には分かりやすくなる変更です。これまでは失敗すると 302 でログイン画面に転送されるため、HTTPクライアントがリダイレクトを追いかけ、ログイン画面のHTMLを「200で成功した応答」として受け取ってしまうことがありえました。オンにすると、失敗は 401・403 として返ります。
止まりうる自動処理の書き方
ここからは、公式資料の挙動から編集部が整理したものです。次のような作りの処理は、オンにした時点で動かなくなる可能性があります。
1. 1回目だけトークンを送り、以後はクッキーで通している
最初のリクエストでサービストークンを送り、返ってきた CF_Authorization クッキーを保存して2回目以降に使う作りです。オンにするとクッキーが返らず、送っても無視されます。すべてのリクエストにヘッダーを付ける作りに直します。
2. Service Auth以外のポリシーで通している
ドキュメントは以前から、サービストークンを受け付けるポリシーのアクションを「Service Auth」にするよう求めており、そうしないとログインを求められると書いています。オンにするとAllowのポリシーは無視されるため、サービストークンを通すためのポリシーがService Authになっているかを、アプリケーションごとに確認します。
3. 失敗をリダイレクトで判定している
「302 が返ったらトークンの期限切れとみなして通知する」のように、リダイレクトを失敗の目印にしている監視やスクリプトは、401・403 を見るように変えます。
4. 1つのヘッダーでトークンを送っている
Authorization など1つのヘッダーにClient IDとSecretを入れて送る方式（read_service_tokens_from_header）が厳格化の対象に入るかは、公式資料に明記されていません。対象になる前提で、この方式を受け付けるアプリケーションのポリシーのアクションも確認しておきます。
オンにする手順
既存の組織では、ダッシュボードの Zero Trust > Access controls > Access settings の Manage service tokens で Strict service token authentication をオンにし、確認の画面で Enable を選びます。APIでは、変更履歴とドキュメントが、Zero Trustの組織を更新するエンドポイントに PATCH で strict_service_token_auth: true を送る例を示しています。
curl -X PATCH "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/organizations" \
-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{"strict_service_token_auth": true}'ただし、APIリファレンス（Update your Zero Trust organization）には、このエンドポイントの更新の方法として PUT だけが載っていて、PATCH は載っていません。編集部では呼び出していないため、どちらで動くかは確かめていません。APIで切り替える場合は、先に今の組織の設定を取得して控え、検証用の組織で結果を確かめてから使います。迷う場合は、ダッシュボードから切り替えます。
この設定は組織全体にかかり、アプリケーションごとには選べません。どの処理が影響を受けるかを先に洗い出してから切り替えるのが安全です。編集部の提案としては、次の順に進めます。
- Accessで保護したアプリケーションのうち、サービストークンを受け付けているものと、そのポリシーのアクションを一覧にする
- そのトークンを使っている処理（CI、バッチ、外部サービスのWebhook、監視）と、HTTPクライアントのリダイレクトやクッキーの扱いを確かめる
- 処理の少ない時間帯にオンにし、Accessの認証ログで失敗が出ていないかを見る。問題があれば、10月5日より前の組織はオフに戻せる
あわせて見直したいサービストークンの設定
8月から9月にかけて、サービストークンの管理に関する変更が続いています。厳格化に合わせて見直すと、トークンの棚卸しがしやすくなります。
- Client Secretの形式（2026年8月26日）：新しく作るSecretは
cfast_で始まる形式になり、末尾にチェックサムが付きます。秘密情報のスキャンツールで見つけやすくするためです。既存の64文字の16進数のSecretはそのまま使え、作り直しは不要です - Secretの入れ替えの猶予期間（2026年8月25日）：Secretを入れ替えるとき、古いSecretを使える期間を1時間から30日の間で選べます
- 使われていないトークンの自動整理（2026年9月22日）：30〜365日の間で決めた期間に使われていないトークンを、自動で無効化または削除できます。Accessのポリシーのルールで直接指定しているトークンは対象外です。削除したトークンは元に戻せません
社内の処理にどの権限を渡すかの考え方は、AIにgcloudを任せる前にでも扱いました。Accessで社内のMCPサーバーを保護し、エージェントをサービストークンでつなぐ構成は、社内MCPサーバーの入口を1つにで整理しています。Cloudflare Tunnelでパスを分けてAccessの検証をかけている場合は、Cloudflare TunnelのURL正規化もあわせて確認してください。
確認した範囲
2026年10月23日に、Cloudflareの変更履歴「New strict service token authentication setting for Access」（2026年10月2日）、サービストークンのドキュメント（Strict service token authentication、Connect your service to Access、Manage inactive service tokens など）、2026年8月25日・26日と9月22日のサービストークンに関する変更履歴を、公式ドキュメントのソースリポジトリ（cloudflare/cloudflare-docs）で確認しました（資料調査）。Cloudflare Zero Trustの環境がないため、設定の切り替え、実際の応答コード、認証ログの表示、各HTTPクライアントでの挙動は確認していません。「止まりうる自動処理の書き方」は、公式の挙動の説明から編集部が整理したものです。公開前の2026年10月27日に、変更履歴とドキュメントの公開ページ、APIリファレンスを見直し、APIの更新の方法が資料によって
PATCHとPUTで異なる点と、1つのヘッダーの方式の扱いが明記されていない点を追記しました。
Accessで保護した社内システムと自動処理の連携の設計・見直しは、開発・AI・自動化のご相談からお問い合わせください。
参考資料
- New strict service token authentication setting for Access（Cloudflare changelog, 2026-10-02）
- Service tokens — Strict service token authentication（Cloudflare One docs）
- Update your Zero Trust organization（Cloudflare API reference）
- Access service token secrets use a scannable format（Cloudflare changelog, 2026-08-26）
- Grace periods for service token rotation（Cloudflare changelog, 2026-08-25）
- Automatically manage inactive Access service tokens（Cloudflare changelog, 2026-09-22）
