testの目的

OAuthのtestを「login buttonを押してノートが表示された」で終えると、重要な分岐が検証されません。守る不変条件ごとに、一つだけ値を壊したrequestを用意します。

攻撃・誤操作	期待結果	守る不変条件
callbackの`state`を改変	Clientが交換前に拒否	responseは開始transactionに属する
`iss`を別ASへ変更	Clientが拒否	response issuerが一致する
PKCE verifierを改変	ASが`invalid_grant`	Codeは開始instanceだけが交換可能
Codeを再利用	ASが`invalid_grant`	Codeは一回限り
Redirect URIを変更	ASが拒否	認可時と交換時が完全一致
write scopeなしでPOST	RSが403	routeごとのscope check
TokenなしでGET	RSが401 + challenge	Bearer credentialが必須

Browser testで秘密値を記録しない

Playwright traceやscreenshotは便利ですが、Token endpoint responseをそのままartifactへ残すと秘密値がrepositoryやCIへ流れます。ラボのE2Eはpage上のredacted Inspectorとnetwork statusをassertし、response bodyをattachmentへ保存しません。

Inspectorのfingerprintは、値を露出せずrotationを観測するために使います。

{
  "kind": "opaque-access-token",
  "length": 96,
  "prefix": "ab12cd34",
  "sha256": "..."
}

prefix単体は秘密の一部なので、本番telemetryへ出す設計ではありません。loopback labのallowlistされた画面に限定します。

DB testで確認すること

HTTP errorだけでなく、DB side effectも確認します。

成功したCode交換後、同じCodeが利用不能になっている
notes:read Consentにnotes:writeが勝手に増えていない
scope不足のrequestがnotes tableを変更していない
inactive Tokenのintrospectionでuser dataが返らない

error responseが正しくても、失敗したtransactionが途中までcommitされていれば次のrequestに影響します。

errorを詳しくしすぎない

Clientには標準のinvalid_request、invalid_client、invalid_grant、invalid_scopeなどを返します。攻撃者が「Client IDは正しいがsecretだけ違う」と区別できる説明を付けません。

一方、server logにはtrace IDと内部分類を残せます。ただしAuthorization header、Cookie、Code、verifier、Tokenはredactします。利用者へ返す情報量とoperatorが必要な情報量を同一にしないことが大切です。

Part 2のcheckpoint

ここまででAuthorization Code + PKCEを一周しました。確認できる状態は次です。

Public ClientにClient Secretがない
TokenはBrowser memoryだけにある
state、issuer、PKCE、Redirect URI、Code one-timeが独立に検証される
Opaque TokenはRSからASへintrospectionされる
GETとPOSTが異なるscopeを要求する

次のPartでは、この一回の認可を長期利用、JWT、machine、deviceへ広げます。