Accessのサービス認証：毎回の要求で機械の主体を確かめる

ログイン画面は機械にとって曖昧な応答になる

保護されたアプリから架空のレポートを読む、1つの定期処理を考える。必要なのは機械の主体と、小さなJSON応答である。ところが、ブラウザのログイン画面、残っていた利用者のCookie、別のアプリからの成功応答でも、弱い疎通確認は合格してしまう。確かめたいのは、今回の要求をどの資格情報が認可し、その後アプリがどの操作を許可したかだ。

Cloudflareの10月2日の発表は、サービス用ヘッダーを伴う要求に適用する組織設定を定めている。strict認証では、認証・認可の拒否はログイン画面への転送ではなく401または403になる。認可に使うのはService Authポリシーであり、利用者のAllowポリシーやCF_Authorization Cookieは認可を補えない。成功してもこのCookieは発行されず、各要求でサービス資格情報を使う。同発表には、2026年10月5日以降に作成される組織の初期設定もある。10月4日の今回の確認時点では将来の作成日ルールであり、既存組織が変更された証拠ではない。

1. 11つのサービス呼び出し元
2. 2明示した機械の資格情報
3. 3AccessのService Auth判定

1. 1エッジの拒否・予想外の転送
2. 2境界を記録して停止
3. 3別の主体へ切り替えない

1. 1エッジの通過
2. 2アプリが対象と操作の権限を検査
3. 3限定したレポート応答

1. 1認証記録とアプリの結果
2. 2秘密を残さず対応付ける
3. 31回の要求を診断する

これはエッジ製品の役割を学ぶ章に、具体的な要求契約を加える。明確なHTTP拒否なら処理を早く停止できる。ただし、通過した要求があらゆるデータの読取りや書込みを許可されたことにはならない。

管理操作の資格情報とアプリ利用の資格情報を分ける

2024年11月14日のAccount Owned Tokens発表は、個人の利用者に結び付けずにCloudflare APIを操作する資格情報を扱った。機械の主体を分ける系譜として有用だが、Accessで保護されたアプリへ到達するサービス・トークンとは、資格情報の役割が異なる。一方を持つことから、もう一方の権限まで推定してはいけない。

今回の1つの読取り処理には、棚卸しの行を2つ用意する。組織のAccess設定を管理できる主体と、レポートを読める処理である。どちらの秘密値も確認表へ書かない。組織更新APIのスキーマにはbooleanのstrict_service_token_authと組織の書込み権限がある。きっかけが1本のスクリプトでも、設定変更の影響範囲は組織全体として検討する必要がある。

現在の資料にはHTTPメソッドの不一致もある。changelogの例はPATCH、リンク先の更新APIリファレンスはPUTである。この記事ではこの不一致を解決したとせず、実行できる変更コマンドも示さない。実変更には、現行メソッドの確認、既存設定を完全に保つ方法、影響する全サービス呼び出し元についての管理者の判断が必要になる。この教材のために実設定は変更していない。

クライアントを動かす前に要求の確認表を作る

以下は独自の未実行オフライン演習である。架空のアプリreport-a、トークンreader-a、JSON応答契約だけを使う。Cloudflareアカウントの試験結果ではない。演習の前提としてstrict認証を明記し、実アカウントの状態は別に確認するまでunknownとしておく。

ケース	架空の入力	確かめる境界
A	許可されたサービス資格情報と読取り可能なレポート	通過と、期待したアプリの応答
B	既知の資格情報と誤ったSecret	認証拒否。ブラウザのログイン経路へ進まない
C	既知の無効・期限切れ資格情報	認証拒否
D	有効な資格情報だが、このアプリのService Authでは許可されない	認可拒否
E	無効なサービス資格情報と有効な利用者Cookie	Cookieが機械の要求を救済しない
F	不正なヘッダー、または未知のClient ID	拒否。認証ログが無いことだけでは結論を出せない
G	有効な機械の主体が他の所有者のレポートを要求	アプリの対象データの権限検査で拒否する
H	サービス資格情報が無い	今回のサービス・ヘッダー契約の範囲外。アプリのポリシーを別に確認する

B〜Eでは原因ごとのステータスを推測せず、公式仕様の集合{401, 403}で確認する。AもAccessの成功ステータスを決めつけない。応答の契約はアプリが定める。Hを埋めるためにstrictヘッダーのルールを全トラフィックへ拡張してはいけない。エッジとアプリのどちらが失敗したか証拠で区別できなければ、unknownを残す。

ホスト、パス、メソッド、呼び出し元、応答スキーマをそれぞれ1つに固定する。将来、別途許可を得た非本番の確認では、自動リダイレクトを無効にし、空のCookie jarから始める。ステータス、秘密を除去した転送先、Content-Type、応答スキーマの検査結果、秘密ではない対応付けIDを記録する。ログインHTMLを含む200ならレポート契約は不合格である。302は予想外のプロトコル結果として停止し、ブラウザのセッション、匿名要求、別のトークンやホストを試してはいけない。

認証ログにも観測できる範囲がある

現行のサービス・トークンガイドは、記録できる既知のトークンの失敗と、その認証ログには記録しない不正ヘッダー・未知のClient IDを区別している。そのため「失敗したログインイベントが無い」だけでは、拒否された要求が存在しなかったと証明できない。認証ログガイドも、認証の試みと、アプリのセッション内で行う個々の操作を分けている。

演習の証拠表には、クライアントの応答、認証記録、アプリの判定という独立した3列を設ける。Gでは、エッジの通過とアプリの拒否が両方とも正しい場合がある。Fでは、クライアントが失敗し、Access認証記録が無い状態も公式仕様の範囲に入る。また、意図した制御を通らずに到達できるオリジン経路があれば、エッジを関門とする仮説全体が崩れる。ホスト名の設定が全経路を守ると推定せず、別の境界として確認する。

Client Secret、利用者Cookie、完全な要求ヘッダー、非公開レポートの本文を診断メモに保存しない。架空の演習ならケースIDだけを残せる。実試験ではローカルの秘密除去ルールと保存期間が必要だ。対応するイベントを探す所要時間は診断の測定であり、資格情報の安全性の証明ではない。

性能、費用、停止条件を決める

この独自の確認表は、主体を切り替える仕組みや再試行層を追加せず、1つの連携を診断するためのものだ。今回の費用は読解・確認の時間であり、API料金、応答速度の改善、ログの利用条件、アカウントの契約上の利用資格は測定していない。将来測る場合はホストとレポートサイズを固定し、成功と拒否の要求数を分けて、wall timeと実アカウントの課金根拠を記録する。発表文や未測定のリダイレクト経路から高速化率を作らない。

予想外の主体の経路を使った応答、Gの許可、トレースへの秘密混入、結果の主体を特定できない状態があれば停止する。失敗した行を保存し、具体的な境界を直した後、新しい設定revisionで同じ行を再確認する。実際のポリシーのactionとselectorはAccessポリシーの公式資料で確認する。確認表そのものは認可を実施する仕組みでも、認可の成功結果でもない。

調査窓は2026年9月4日15:28:50 JST〜10月4日15:28:50 JST。日付付き更新は10月2日の発表であり、現行docsとAPIスキーマの公開日は今回独立して確認できていない。組織、トークン、アプリのポリシー、資格情報、本番の保護設定は変更しておらず、この要求表も実行していない。