Google OAuth：更新トークンのクライアント鍵への紐付け、アクセストークンのBearer方式維持

1. 長期間使う認証情報から保護する

更新トークン（refresh token）は、新しいアクセストークンの発行に使う長期的な認証情報だ。アクセストークン（access token）は、サービスにリクエストする際に使う認証情報で、Googleは一般的な有効期間を1時間以下と説明している。

追加されたDPoPは、RFC 9449で定義されたアプリケーション層のセキュリティ方式だ。クライアントが生成した公開鍵と秘密鍵のペアにトークンを紐付ける。トークンが入場券なら、対応する秘密鍵は所有者であることを証明する別の鍵に当たる。トークンだけが流出しても再利用できなくする。

Googleはこの紐付けを更新トークンにのみ適用する。新しいアクセス権限を継続して得る経路を保護し、攻撃者が盗んだ認証情報で長期間ユーザーになりすますリスクを減らすための選択だ。

2. 呼び出しごとの検証コストは避ける

アクセストークンは、持っている人が使えるBearer方式を維持する。Googleは、リクエストが多いAPIで毎回非対称署名を検証すると、計算負荷や遅延、拡張コストが増すと説明している。これは設計上の根拠であり、性能を数値で比較した測定結果は示されていない。

利点とコストは別の場所に生じる。長期的な認証情報を保護しつつ、サービス呼び出しごとに所有証明を検証する負担は避けるが、クライアントには鍵の安全な生成・保管と証明生成の責任が加わる。従来のトークン管理に加え、暗号演算や保存上の制約も考慮する必要があるということだ。

3. 導入には証明を生成する経路が必要だ

クライアントは鍵の生成に加え、時刻情報とnonceという一度限りの値を厳密に扱う必要がある。リクエスト情報を含むクレームとヘッダーを正確に構成し、所有証明を含むJWTも生成しなければならない。単にトークンを送信する従来のフローに、この処理が加わる。

発表文には実装コードの例は示されていない。Googleは、別途導入ガイドと実装を支援するSKILL.md文書を案内している。そのため、発表だけで具体的なリクエスト形式やライブラリの使い方まで確定することはできない。

4. 中間サーバーを経由しても紐付けを維持する

Googleは、RFC 9700の更新トークン保護に関する議論と、ブラウザーアプリ関連の標準草案を根拠に挙げている。ブラウザー専用バックエンド、トークン中継バックエンド、ブラウザーベースのクライアントという三つのモデルで、更新トークンに所有者の制約を適用するよう推奨している。

トランスポート層でトークンを紐付けるmTLSは、クラウドプロキシやロードバランサーで接続が終端されたり切断されたりする場合がある。一方、DPoPはリクエストヘッダーのレベルで動作する。Googleは、この特性が複数の中間サーバーを経由するエージェント構成にも有用だと説明している。

5. Cookieの保護とエージェントへの委任は別の課題だ

一般的なWebアプリのセッションCookieは、今回の機能の保護対象ではない。GoogleとWeb Incubator Community Groupは、Cookieをデバイスのハードウェアに紐付けるDBSCを開発している。APIトークンとブラウザーセッションには、互いを補完する別々の保護が必要だという説明だ。

エージェント間の業務委任にも注意が必要だ。業務を引き継いだエージェントは、前のエージェントの秘密鍵なしには、そのエージェントの代わりに所有証明へ署名できない。秘密鍵を共有することは、このセキュリティ方式の原則に反する。

コンシューマー向け認証エンドポイントのoauth2.googleapis.comは、トークン交換に対応していない。Googleは、マルチエージェントや連携クラウドの処理ではGoogle Cloud Secure Token Serviceの検討を推奨している。中間エージェントが上位のトークンを、自分の鍵に紐付いた短期の連携トークンに交換する経路だ。

今回の変更は、サービスの呼び出し方式を維持しつつ長期的な認証情報を強化する選択であり、導入判断の要点は、鍵管理と委任経路に対応できるかどうかだ。