ラボは固定Clientから始める

本書のClientはseed scriptからBetter Authのserver-only admin APIで作ります。

await auth.api.adminCreateOAuthClient({
  headers: operatorSession,
  body: {
    client_name: 'Cloud Notes React Public Client',
    token_endpoint_auth_method: 'none',
    grant_types: ['authorization_code', 'refresh_token'],
    response_types: ['code'],
    redirect_uris: ['http://127.0.0.1:4200/callback'],
    require_pkce: true
  }
})

SQL insertではなくProvider APIを使うため、Redirect URI、application type、auth method、grantのvalidationを通ります。実際に127.0.0.2をRedirect URIへ使った最初の試行はinvalid_redirect_uriで拒否され、loopback policyを設計へ反映できました。

Dynamic Client Registrationとは

RFC 7591は、Clientがregistration endpointへmetadataを送り、Client IDなどを受け取るprotocolを定義します。ecosystemで第三者Clientを受け入れる場合に有用ですが、endpointを公開するだけで安全になる機能ではありません。

ラボは次を明示して無効にします。

allowDynamicClientRegistration: false

DCRを有効にする前のpolicy

Initial Access Tokenやsoftware statementを要求するか
誰がRedirect URI domainを所有しているか確認するか
Public/Confidentialとauth methodの組合せをどう制限するか
許可grant、scope、resourceを誰が承認するか
Logo/Policy URIをSSRFやtracking inputとして扱うか
Client作成rate limit、quota、abuse対応をどうするか
Client Secretを一度だけ安全に返すか

anonymous DCRをそのまま有効にすると、攻撃者が大量Clientを作ったり、phishing用metadataを登録したりできます。

Redirect URI validation

完全一致だけでなく、registration時点でscheme、credential、fragment、loopback表記を検証します。Better Auth 1.7.1はweb clientにHTTPS non-loopbackを要求し、native HTTP loopbackをlocalhost、127.0.0.1、[::1]へ限定します。

この制約はAuthorization RequestごとではなくClient metadataの入口で適用されます。危険なRedirect URIを一度登録してから後段で補正する設計にしません。

管理面を分離する

Client登録、secret rotation、resource linkはResource Owner向けConsent UIへ出しません。operator権限を持つseed userだけがserver-only endpointを呼べます。本番では個人email比較ではなく、管理role、audit log、step-up authenticationを使います。

次章ではTokenが盗まれてもkeyなしでは使えないDPoPを追加します。