decodeとverifyを分ける

JWTのheaderとpayloadは誰でもdecodeできます。subやemailが読めたことは、ASが発行した証拠ではありません。ClientはJWKSを使ってJWS signatureを検証します。

ID Token validation pipeline

ラボの検証順は次です。

algをallowlistと比較する
kidに対応する公開鍵をJWKSから得る
signatureを検証する
issを期待issuerと完全一致させる
audに自分のClient IDがあることを確認する
exp、iatなど時刻claimを検証する
nonceをtransaction保存値と比較する
at_hashをAccess Tokenから再計算する

Better Auth 1.7.1の既定algorithm

discoveryのid_token_signing_alg_values_supportedを観測すると、既定はEdDSAです。RS256だと決め打ちしません。

const { payload } = await jwtVerify(idToken, jwks, {
  issuer: AUTH_ISSUER,
  audience: clientId,
  algorithms: ['EdDSA']
})

本番でalgorithmを変更する場合、AS設定、discovery、Client allowlistを一緒に更新します。headerのalgをそのまま信頼して任意algorithmを許す実装にはしません。

at_hashを計算する

ID Tokenと同じToken ResponseでAccess Tokenを受け取った場合、at_hashが両者を結び付けます。Better Auth 1.7.1はEd25519のEdDSAに対してSHA-512を使い、digest左半分をbase64url encodeします。

const digest = await crypto.subtle.digest(
  'SHA-512',
  new TextEncoder().encode(accessToken)
)
const expected = base64url(new Uint8Array(digest).slice(0, 32))

RS256/ES256ならSHA-256、*384ならSHA-384、*512ならSHA-512です。base64url文字列を半分に切るのではなく、digest byte列を半分にしてからencodeします。

verified表示の条件

Inspectorは検証前JWTをverified: falseと表示します。上の全処理を通過した後だけverified: trueへし、claimをUIに渡します。例外時は未検証claimをfallback表示しません。

negative test

payloadのsubを編集 → signature failure
別Client向けID Token → audience failure
別issuerの鍵で署名 → issuerまたはsignature failure
nonceを変更 → nonce mismatch
別Access Tokenと組み合わせる → at_hash mismatch
expired Token → expiration failure

次章ではClientがendpointやalgorithmを固定文字列で抱えず、DiscoveryとUserInfoを正しく使う方法を見ます。