Access Tokenを長寿命にしない

利用者が毎回Consentをやり直さずに使えるようにする方法は、Access Tokenの寿命を無制限にすることではありません。短寿命Access Tokenと、ASだけへ提示するRefresh Tokenを分けます。

Public ClientはAuthorization Requestへoffline_accessを追加します。Better Auth ProviderはClientにRefresh Token Grantが登録され、policyを満たした場合だけRefresh Tokenを発行します。

Refresh Tokenのprotocol flow

交換requestは次です。

POST /api/auth/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&
refresh_token=...&
client_id=...

Public ClientなのでClient Secretはありません。ASはRefresh Tokenが発行されたClientと一致するか、期限、revocation、scope、resourceを検証します。

scopeを広げない

Refresh Requestでscopeを省略した場合は元のgrantの範囲を引き継ぎます。指定する場合でも狭めることしかできません。notes:readだけのRefresh Tokenへnotes:writeを付けて送っても権限昇格できません。

同じ原則がresourceにもあります。Authorization RequestがNotes APIを対象としていなければ、refresh時だけ新しいresourceを追加してはいけません。Better Auth 1.7.1は、認可済みresourceからnarrowすることだけを許します。

Browserでの所有

Public Client版ではRefresh Tokenもメモリだけに置きます。page reloadで失われるため、デモとしては不便です。しかしXSSで読める永続storageへ長期credentialを保存する危険を隠しません。

「offline_accessを選んだのにreloadで消える」のは矛盾ではありません。AS側のgrantが継続可能でも、このPublic Client実装はBrowser再起動をまたぐToken保管を選んでいないということです。永続sessionが必要ならPart 5のBFFを選びます。

DB recordを読む

oauth_refresh_tokenはclient、user、session、authorization code、scope、resource、expiry、revocation、family関係を保持します。Access Tokenと別tableであることにより、Access Tokenだけを短寿命化しつつ継続grantを管理できます。

Refresh Tokenを受け取ったClientが変わらないか、Token familyが再利用されていないかをASが判断するため、単なる署名済み自己完結文字列よりserver-side stateが重要になります。

failureを観測する

offline_accessなし → Refresh Tokenがない
別Client IDで交換 → invalid_grantまたはClient不一致
元にないscopeを追加 → invalid_scope
元にないresourceを追加 → invalid_target
revoke後に交換 → invalid_grant

次章では、Refresh Tokenを毎回置き換え、古い値の再利用を攻撃signalとして扱います。