トークン失効はエンドポイントではない — DPoPが解決しない「失効ラグ」の話

この記事は英語の原文エッセイ「Token Revocation Is Not an Endpoint」(Michał Piszczek, CTO @ Archdesk) の要約・日本語版です。

トークンは「有効」なのに、すでに「死んでいる」べきだった

DPoP (RFC 9449) の普及で、アクセストークンの盗難はかなり難しくなりました。送信者制約 (sender-constraining) により、トークンはクライアントの鍵にバインドされ、盗まれたトークン単体ではほぼ使えません。

しかし、ここに罠があります。盗難と失効遅れ(stale authority)は、まったく別のセキュリティ軸です。

暗号学的には完璧、運用的には未認可

クライアントを失効させた瞬間を考えてみてください。

$ auth revoke client_7f3a9c
ok — revoked at t+0ms

edge-cache-03   ACCEPT  stale  t+420ms
worker-pool-11  ACCEPT  stale  t+1.2s
api-gw-eu-1     ACCEPT  stale  t+2.8s
batch-runner    ACCEPT  stale  t+9.4s

署名は正しい。有効期限も切れていない。つまり暗号学的には有効です。しかし権限はすでに取り消されている — 運用的には未認可。エッジキャッシュ、ワーカープール、ゲートウェイ、バッチランナーは、失効の事実をまだ知りません。

失効はエンドポイントではなく、分散システム全体を横断する伝搬レースです。

Revocation Exposure(失効エクスポージャー)を測る

問うべき質問は「失効エンドポイントはあるか?」ではなく:

• 失効ラグ: revoke してから、システム全体が古い権限を拒否し始めるまでの時間は?
• • カバレッジ: どの検証ポイントが失効を即座に見るか? キャッシュ TTL に隠れているのはどこか?
• • AIエージェント時代の増幅: エージェントがトークンを持って自律的に動く場合、9.4 秒の失効ラグは 9.4 秒分の未認可アクションを意味します。

この「失効までの露出時間」を著者は Revocation Exposure と定義しています。SLO として測定し、カオステストで検証する枠組みは原文にあります。

まとめ

• DPoP は盗難対策。失効ラグには効かない
• • トークンは「暗号学的に有効」かつ「運用的に未認可」になり得る
• • 失効はエンドポイントではなく伝搬レース。ラグを測れ

原文(英語・詳細版): https://piszczek.pl/blog/token-revocation-is-not-an-endpoint
30秒の動画版: https://youtube.com/shorts/rF7HCQHZEqE