DPoPとは？仕組みやメリットなどをわかりやすく解説

※この記事にはプロモーション（広告）が含まれています。

DPoP（Demonstrating Proof-of-Possession）は、OAuth 2.0やOpenID Connectにおいて、アクセストークンの不正転用を防止するための拡張仕様である。公開鍵暗号を用い、トークンを発行先クライアントに固着させることで、窃取されたトークンの悪用を封じる。

DPoPの仕組み

DPoPの中核は、クライアントが自身の手元にある「秘密鍵」を保持していることを、リクエストのたびに証明する点にある。従来のBearerトークンが「持っている者なら誰でも使えるパス」だったのに対し、DPoPは「特定の持ち主しか使えない記名式のパス」へとアップグレードするものだ。

DPoP Proof（JWT）の生成

クライアントは、リクエストを送信するたびに、一回限りのJWT（JSON Web Token）を作成する。この中には、HTTPメソッドや送信先のURI、そして「jti（一意の識別子）」が含まれる。このJWTをクライアントが保持する非対称鍵（秘密鍵）で署名し、HTTPヘッダーに載せて送り出す。
公開鍵のバインディング

認可サーバーは、トークン発行時にクライアントが提示した公開鍵を、発行するアクセストークン（AccessToken）に紐付ける。具体的には、トークンの内部（イントロスペクションの結果やJWTのクレーム）に、公開鍵のハッシュ値（cnfクレーム）を書き込む仕組みだ。
リソースサーバーによる検証

APIなどのリソースサーバーは、送られてきたアクセストークンを受け取ると、そこに刻印された公開鍵情報を確認する。同時に、DPoP Proofヘッダーの署名がその公開鍵で正しく検証できるか、さらにはリクエスト内容と矛盾がないかを突き合わせる。

この一連の動作により、仮に通信路の隙を突いてアクセストークンだけを盗み出した第三者がいたとしても、その攻撃者は「対応する秘密鍵」を持っていないため、別の場所からAPIを叩くことは不可能となる。

セキュリティ強度の向上は言うまでもないが、実運用における柔軟性と「ブラウザ環境での現実解」としての立ち位置が、DPoPの真の価値である。

トークン漏洩時の被害最小化（Sender-Constrained）

最大の特徴は、アクセストークンが「送信者限定」になることだ。従来のBearerトークンは、一度盗まれれば有効期限が切れるまで攻撃者が使い放題だったが、DPoPでは秘密鍵が手元にない限り、盗んだトークンはただの無意味な文字列に成り下がる。
ブラウザやモバイルアプリでの親和性

同様の仕組みに「MTLS（Mutual TLS）」があるが、これはネットワークの低レイヤーで証明書を扱うため、ブラウザ上でのJavaScript実行環境や、複雑なインフラ構成（ロードバランサーによるTLS終端など）では導入の壁が高かった。DPoPはアプリケーションレイヤー（HTTPヘッダー）で完結するため、モダンなWebフロントエンドでも容易に組み込める。
リプレイアタックの封じ込め

DPoP Proofには「jti」クレームや「iat（発行時刻）」が含まれており、サーバー側でこれらをキャッシュしてチェックすることで、全く同じリクエストを再送する攻撃を防げる。さらに「nonce（一時的な値）」をサーバーが要求する仕組みも備わっており、鮮度の高い証明を強制できる。

DPoPの実装は、ライブラリやフレームワークの対応が進んだことで、エンジニアがゼロから署名ロジックを書く必要はなくなってきている。

oidc-client-ts / MSAL.js

ブラウザ向けの主要なOpenID Connectライブラリは、すでにDPoPのサポートを開始している。設定オプションでDPoPを有効にするだけで、内部的に鍵ペアを生成し、ストレージ（IndexedDBなど）に保持しながら、リクエスト時に自動でProofヘッダーを付与してくれる。
Auth0 / Okta / IdentityServer4

IDプロバイダー（IdP）側も対応が標準化しつつある。特にIdentityServer4やその系譜を継ぐDuende IdentityServerでは、クライアント設定でDPoPを必須にすることができ、バックエンド側でのトークン検証ロジックもミドルウェアとして提供されている。
Step-up Authenticationの実装支援

一部のAPI ゲートウェイやセキュリティプロキシでは、受信したDPoPトークンを検証し、後続のマイクロサービスには安全な形で中継するプラグインが提供されている。これにより、個別のサービスごとに複雑な検証コードを書く手間が省け、システム全体の堅牢性を底上げできる。

「DPoPかOAuthか」という対立構造ではなく、DPoPは「OAuth 2.0をより安全に運用するための追加機能」と捉えるのが正しい。

[Image comparing OAuth 2.0 Bearer Token and DPoP Token security models]

信頼モデルの差

標準的なOAuth 2.0（RFC 6749）では、アクセストークンは「Bearer（持参人）」形式だ。これはホテルのルームキーと同じで、鍵を拾った人は誰でも部屋に入れてしまう。一方、DPoPを適用したOAuthは「顔写真付きの身分証」に近い。提示されたトークンと、提示した本人の署名が一致して初めてゲートが開く。
伝送路への依存度

通常のOAuthは、TLS（HTTPS）による通信経路の暗号化に安全性の全てを依存している。しかし、ログへのトークン出力や、ブラウザのメモリからの抜き取りなど、TLSだけでは守れない死角が存在する。DPoPは、たとえ暗号化された通路の外側にトークンがはみ出しても、それ単体では機能しないように設計されている。
実装コストとオーバーヘッド

OAuth Bearerは単純にHeaderを1行足すだけで済むが、DPoPはクライアント側での鍵管理と、リクエストごとの署名計算が必要になる。CPUのリソース消費や、ヘッダーサイズが増大するデメリットはあるものの、昨今のデバイススペックや通信帯域を考えれば、セキュリティ上の利点がこれらを大きく上回る。

DPoPは、Webアプリケーション、特にSPA（Single Page Application）やモバイルアプリにおいて、これからのデファクトスタンダードとなるべき技術だ。トークンの「使い回し」という古典的かつ致命的な脆弱性に対し、アプリケーション層でシンプルに解を与えてくれる。

これまでMTLSの導入に二の足を踏んでいた開発者にとって、DPoPは現実的な選択肢となるだろう。もちろん、秘密鍵の保管場所（Web Crypto APIの利用など）には引き続き注意を払う必要があるが、Bearerトークンをそのまま放置するリスクに比べれば、その安全性は雲泥の差だ。

今後、自社のAPI基盤や認証システムを構築・更新する際には、DPoPの採用を前提に設計を進めるのが、ITリテラシーの高いエンジニアとしての賢明な判断といえる。