JWTへ変える目的

JWTはTokenをBrowserで読めるようにするための形式ではありません。RSがASの署名鍵を使ってlocal verificationできるようにする選択です。認可decisionを自己完結claimとして運ぶ代わりに、即時revocationやkey rotationの設計が必要になります。

Authorization RequestへRFC 8707のresourceを追加します。

resource=http://127.0.0.3:4300

Resource IndicatorからJWT Access Tokenまで

Better Authは登録済みresource policyを見て、そのresource向けJWTを発行します。OIDC scopeも同時に要求したラボのaudは、Notes APIとUserInfo endpointの配列です。Notes RSは配列に自分のidentifierが含まれることを検証します。他のAPIへ同じTokenを送ってもaudience checkで拒否できます。

resourceのallowedScopesは有効scope全体を絞ります。Notes用scopeだけを登録した状態でopenidも要求すると、Better Auth 1.7.1はopenidを有効scopeから落とし、ID Tokenを発行しません。本書の設定がOIDC scopeとoffline_accessもallowlistするのはこのためです。RSがそれらをAPI権限として解釈するという意味ではなく、route authorizationでは引き続きnotes:readやnotes:writeだけを評価します。

RSで検証するclaim

最低限、次を検証します。

JWS signatureと許可algorithm
issがAS issuerと完全一致
audがこのRS identifierを含む
expと必要ならnbf
routeに必要なscope
subまたはservice principal
DPoP時はcnf.jkt

payloadをbase64url decodeしただけでは検証になりません。Inspectorは未検証JWTをverified: falseと表示し、RSのauthorization inputには使いません。

JWKSとkey rotation

ASはjwks_uriをdiscoveryで公開します。RSはkidとalgに合う公開鍵を取得してsignatureを検証します。鍵を永続cacheし続けるのではなく、未知のkidが来たときのrefresh、HTTP cache header、古いTokenの有効期間を考えます。

Better AuthのJWT pluginは鍵をjwks tableへ保存します。process再起動のたびに新しいephemeral keyを作る構成では、まだ有効なTokenを検証できなくなります。

JWT Access Tokenの発行とlocal verification

Opaque Tokenとの比較

観点	Opaque + introspection	JWT local verify
network	requestごとにAS依存	JWKS取得後はlocal
revocation反映	ほぼ即時	`exp`まで残り得る
claim露出	Clientから読めない	Token所持者は読める
AS負荷	高い	低い
RS実装	introspection認証が必要	JWT policyが必要

どちらが常に優れているわけではありません。Token寿命、RS数、revocation要求、claim sensitivityで選びます。

audience移行を締める

JWT phaseではallowMissingAudienceをfalseへします。Part 2の互換設定を残したままにすると、resourceを指定しないTokenもRSが受け入れ続けます。移行完了条件をtestで表し、missing audを拒否させます。

次章ではResource OwnerのいないClient Credentials Grantを追加します。