Bearer Tokenの弱点

Bearer Tokenは「持っている者」が使えます。TLSで通信中の盗聴は防げても、Client storage、log、extension、proxyから漏れたTokenを別processがreplayできます。

RFC 9449のDPoPはAccess TokenをClientのpublic key thumbprintへ結び付け、requestごとにprivate keyでproof JWTを作ります。

DPoP-bound Tokenの発行とAPI request

proofのclaim

new SignJWT({
  htm: request.method,
  htu: new URL(request.url).href,
  iat: Math.floor(Date.now() / 1000),
  jti: crypto.randomUUID(),
  ath: base64url(sha256(accessToken)),
  nonce
}).setProtectedHeader({
  typ: 'dpop+jwt',
  alg: 'ES256',
  jwk: publicJwk
})

Token endpointでのproofには通常athがなく、発行されたTokenにはcnf.jktが入ります。RS requestではathがAccess Tokenをproofへ結び付けます。

Authorization: DPoP <access-token>
DPoP: <proof-jwt>

RSが検証する順序

typと許可algorithm
embedded public JWKとcnf.jkt
signature
htmが実request methodと一致
htuがfragmentなしの実request URLと一致
iatが許容時間内
jtiが未使用
athがAccess Token hashと一致
serverが要求したnonce

Better Auth verifyAccessTokenRequestのDPoP検証境界

Better Auth 1.7.1のverifyAccessTokenRequestはBearer/DPoPをrequest単位で検証します。DPoP-bound Tokenを生Token verifierへ渡してBearerとして通さないことが重要です。

replay storeはdatabase-backedにする

jti replayをprocess memoryだけで記録すると、複数instanceの別nodeへ同じproofを送れます。Providerはverification storeをDB-backedにし、instance間でone-timeを共有します。secondary-storageだけで安全性を満たせない構成では、DPoPを黙って弱めずrequestを拒否します。

nonce retry

ASやRSがDPoP-Nonceを返した場合、Clientは同じproofを再送せず、新しいjti・iatと受け取ったnonceでproofを作り直します。Access Tokenは同じでもproofはrequestごとに新しいものです。

限界

DPoPはClient process内でprivate keyを使えるXSSまで防ぎません。keyをnon-extractableにしても、悪意あるscriptが署名operationを呼べる場合があります。BFFやOS key storeと組み合わせる方が境界を強くできます。

次章ではAuthorization Request自体をBrowser front-channelへ露出しすぎないPARの境界を整理します。