Google、OAuth（オーオース）のリフレッシュトークンにDPoP（ディーポップ）対応盗まれても秘密鍵がなければ使えない、アクセストークンは従来のまま

Googleは2026年10月15日（現地の掲載日付。時刻の記載はありません）、Google Developers Blogで、OAuth 2.0のリフレッシュトークンをクライアントが生成した鍵ペアに暗号で結びつけるDPoP（ディーポップ、Demonstrating Proof-of-Possession）への対応を発表しました。仕様はIETFのRFC 9449です。Googleは、トークンが盗まれても対応する秘密鍵がなければ再利用できない、と説明しています。結びつけるのはリフレッシュトークンだけで、短命のアクセストークンは従来のBearerトークンのままです。

3行まとめ

1. GoogleのOAuthが、RFC 9449のDPoPでリフレッシュトークンを鍵ペアに結びつける方式に対応（2026年10月15日・開発者ブログ）
2. 対象はリフレッシュトークンのみ。有効期間が通常1時間以下のアクセストークンはBearerのままで、Googleの説明ではAPI呼び出しごとの署名検証は発生しない
3. 純粋なSPAは直接使えずBFFが必要。マルチエージェントでは、中継するエージェントが元の秘密鍵なしに署名できないため、GoogleはGoogle Cloud STSの検討を勧めている

本記事の内容は、日本時間2026年10月16日3時台に公式ページで確認したものです。

何が変わったのか

Googleの説明では、従来のOAuthのBearerトークンは「finders-keepers（拾った者が持ち主）」型です。RedLineやNodeStealerといった情報窃取マルウェアや、AiTM（中間者）攻撃で盗まれると、そのまま使われてしまいます。

DPoPでは、クライアントが非対称鍵ペアを自分で作り、Googleのトークンエンドポイント（https://oauth2.googleapis.com/token）へのリクエストごとに「この鍵を持っている」ことを示す署名付きの証明（DPoP proof、JWT形式）を DPoP ヘッダーに付けます。Googleは、リフレッシュトークンをこの鍵に結びつけることで、永続的に他人になりすませる主な経路をふさぐ、と説明しています。

導入ガイドによる実装上の要点は次のとおりです。

認可コード交換でリフレッシュトークンを受け取る段階（ガイドの図1の5・6番）と、リフレッシュトークンで新しいトークンを受け取る段階（図2の2〜5番）の2か所で、DPoP proofを付ける必要があります。

ガイドは、期限切れ・誤り・再利用の nonce を使った時や、認可コード交換から更新へ移る時には、サーバーが無条件に use_dpop_nonce のHTTP 400を返して新しい nonce を渡すと書いています。これは「RFC準拠の通常の動作でサーバー障害ではない」ため、クライアント側にはこの400を拾って新しい nonce で証明を作り直し、再試行する処理が必要だとしています。GitHubのSKILL.mdでは、再試行は1回だけとし、再度失敗したら即座にエラーで終わらせるよう指示しています。

なぜアクセストークンは対象外なのか

ブログは、読者が抱きそうな疑問に答える形で理由を書いています。DPoPの署名検証（ES256など）は多くのCPU時間を使うため、Gmail・Calendar・Driveのような大量のリクエストを受けるAPIで毎回検証すると、ゲートウェイ層の負荷が大きくなり、遅延とスケールのコストが増えるという説明です。

そこでGoogleは、次の分担にしました。

• リフレッシュトークン: 長期間有効で、新しいアクセストークンを出し続けられる。鍵ペアに結びつけ、持ち出されても使えないようにする
• アクセストークン: 通常1時間以下。Bearerのままなので、ほとんどのAPIリクエストに暗号検証のオーバーヘッドは出ない

SKILL.mdにも、Googleのトークンエンドポイントは "token_type": "Bearer" を返し、Google APIへのリクエストは従来どおり Authorization: Bearer ヘッダーで送り、DPoPヘッダーは付けない、とあります。つまり、アクセストークンが盗まれた場合は、その有効期間のあいだ使われうる設計です。この点はGoogleの説明から読み取れる範囲の整理で、ブログ自身も「実用的なエンジニアリング上のトレードオフ」と呼んでいます。

誰が何をする必要があるのか

ブログは、DPoPには鍵の生成、タイムスタンプとnonceの厳密な扱い、htm・htu・iat・jti の計算、ヘッダーの組み立て、proof JWTの構築が必要で、安全な計算・取り扱い・保管のためのシステム上の制約が増えうる、と注意しています。

SKILL.mdはさらに踏み込み、秘密鍵は extractable: false（取り出し不可）で作るよう求めています。理由は、XSSや依存パッケージ経由のトークン窃取を防ぐためだと説明されています。

ブラウザだけのSPAは直接使えません。 導入ガイドによると、client_secret が必要なことと、DPoP-Nonce ヘッダーにCORS上の制限があることが理由です。SPAで使うには、機密クライアントとして働くBackend-for-Frontend（BFF）を挟み、access_type=offline を有効にして、サーバー側でリフレッシュトークンを結びつけます。ブログは、IETFのブラウザ向けOAuthドラフトにある3つのモデル（BFF、Token-Mediating Backend、Browser-based OAuth Client）でも、リフレッシュトークンのDPoPによる結びつけを勧めています。

なお、導入ガイドの例は calendar.readonly スコープを使っています。どのAPI・どのスコープ・どのクライアント種別が対象かの一覧は、今回確認したページには見当たりませんでした。

MCPとマルチエージェントでの注意点

ブログは、mTLS（RFC 8705）のようなトランスポート層のトークン結びつけは、現代のクラウドプロキシやロードバランサーで途切れたり終端されたりしやすいと書きます。DPoPはHTTPヘッダーのレベルで動くため、複数の中継点を通る環境、たとえばMCP（Model Context Protocol）や自律エージェントの構成にも強い、という説明です。

一方で、委譲には課題があるとも明記しています。エージェントAがエージェントBに仕事を任せ、BがリソースCを呼ぶ構成では、BはAの秘密鍵なしにAの代わりに署名できません。鍵を共有するのはDPoPの原則に反します。

Googleは、消費者向けのOAuthエンドポイント（oauth2.googleapis.com）がOAuth 2.0 Token Exchange（RFC 8693）に対応していないことを挙げ、マルチエージェントやフェデレーションの構成では**Google Cloud Secure Token Service（STS）**を検討するよう勧めています。STSを通せば、中継エージェントが上流のトークンを、自分の鍵ペアに結びついた短命のトークンに交換でき、鍵を渡さずに結びつけを保てるという説明です。

Google Cloud側のエージェント基盤でもDPoPが使われている

ブログは、Google Workspace Context-Aware Access（CAA）が、Gemini Enterprise Agent Platform上のAI処理を守るためにDPoPを使うとも書いています。Agent Gatewayでエージェントの身元を暗号で検証するという位置づけです。

Google Cloudのドキュメント（最終更新2026年10月13日）によると、Agent Gatewayを通るエージェントにはCAAが既定で次を強制します。

• Agent Gatewayへのアクセス: mTLS（証明書に結びついたトークンの検証）
• Agent Gatewayより先のサービスへのアクセス: DPoP

Agent Gatewayを有効にするとmTLSがそこで終端されるため、その先ではDPoPで再認証する、という流れです。Agent Gatewayには「Preview」の表記があります。環境変数 GOOGLE_API_PREVENT_AGENT_TOKEN_SHARING_FOR_GCP_SERVICES を False にするとCAAの強制を外せるとも書かれており、例としてエージェント間でトークンを共有したい場合が挙がっています。

これはOAuthのリフレッシュトークンの話とは別の仕組みですが、同じブログ記事の中で並べて紹介されています。

DPoPで守れないもの

ブログは、DPoPの限界も書いています。DPoPは通常のWebアプリのセッションCookieを保護しません。 Cookieは情報窃取マルウェアの主な標的のままです。そのためGoogleとWICGは、Cookieをデバイスのハードウェア（TPMなど）に結びつけるDBSC（Device Bound Session Credentials）を開発中で、DPoP（アプリケーション層でAPIトークンを守る）とDBSC（ブラウザ・ネットワーク層でセッションCookieを守る）を合わせて多層防御にする、という説明です。

観測：公式ページで確認できたこと、できなかったこと

日本時間10月16日3時台に、ブログ・導入ガイド・SKILL.md・Cloudドキュメントの4ページを取得して読みました。その時点で気づいた点を3つ書きます。

• 導入ガイドのページの末尾は「Last updated 2026-07-31 UTC」でした。ブログの発表日（10月15日）より2か月以上前の日付です。ガイド自体は発表より前から公開されていた可能性がありますが、公開の経緯までは今回のページからは分かりません。
• ブログの本文は、導入ガイドとSKILL.mdへのリンクで締めくくられています。実装の詳細はガイド側、コードを書くエージェント向けの指示はSKILL.md側、と役割が分かれていました。
• 導入ガイドのページには言語選択に日本語がありますが、私が取得したのは英語版で、日本語版の内容までは確認していません。

今回のページから分からないこと

次の点は、今回取得した4ページを検索した範囲では記載を確認できませんでした。確認したのは、料金、一般提供（GA）や段階的な展開の時期、日本を含む提供地域、DPoPの利用を義務にする計画、対象となるAPIやクライアント種別の一覧です。

• 既存のアプリがすぐ影響を受けるのか: DPoPを使うかどうかは、ガイドの文面では開発者が実装を足す形に読めます。ただし、既存のトークンの扱いが将来変わるかどうかは書かれていません。
• 効果の数字: 盗難の減少率や性能への影響を示す数値は、ブログにありません。「オーバーヘッドが出ない」はGoogleの設計上の説明です。
• 筆者は試していません: 本記事は公式ページの読解に基づくもので、実際にDPoPのリクエストを送って動作を確かめたわけではありません。ガイドのサンプルのトークン値や iat は例示用の値です。

SKILL.mdには、WebCrypto の crypto.subtle.sign はECDSA署名を最初からIEEE P1363形式（64バイト）で返すため、DER形式からの変換をしてはいけない、という実装上の落とし穴も書かれています。Java/AndroidやNodeのCommonJSで古いAPIを使う場合に限り、DERから変換するという区別です。実装する人は、ここを先に読むと詰まりにくいはずです。

出典と確認時刻

• Announcing DPoP Support for Google OAuth: Securing Refresh Tokens（Google Developers Blog、2026年10月15日）
• DPoP Adoption Guide（Google for Developers）
• dpop-adoption SKILL.md（google/skills、GitHub）
• Context-Aware Access agent security（Google Cloud Documentation）

確認時刻は、いずれも日本時間2026年10月16日3時12分台です。本記事は続報があり次第更新します。