Authorization Requestを先に押し込む

RFC 9126のPushed Authorization Requests（PAR）では、Clientが認可parameterをASのback-channel endpointへ先にPOSTします。ASは短寿命のrequest_uriを返し、Browser front-channelにはその参照だけを載せます。

POST /par  -- authenticated client + authorization parameters --> AS
          <-- request_uri=urn:ietf:params:oauth:request_uri:... --

GET /authorize?client_id=...&request_uri=...

長いclaim requestをURLへ出さず、Client認証後にparameterを固定できる利点があります。

Better Auth 1.7.1が提供する境界

OAuth ProviderにはrequestUriResolver optionがあります。

requestUriResolver: async ({ requestUri, clientId, ctx }) => {
  const stored = await parStore.consume(requestUri)
  if (!stored || stored.clientId !== clientId || stored.expiresAt < new Date()) {
    return null
  }
  return stored.parameters
}

Authorize endpointがrequest_uriを受けると、まずURL上のclient_idを要求し、resolverへ渡します。resolverが返した保存済みparameterでquery全体を置き換え、URL上の他parameterを混ぜません。RFC 9126のparameter integrityを守る重要な実装です。

本書でendpointを自作しない理由

Providerはresolver boundaryを提供しますが、完全なPAR endpoint、Client認証、request保存、one-time consume、expiry、metadata公開を自動で構築するわけではありません。

学習用に不完全な/parを数行で足すと、次を落としやすくなります。

Client認証方式の統一
Redirect URIとscope/resource validation
Request Objectとの競合
推測不能なrequest_uri
一回限りのconsume
短いexpiryとcleanup
rate limitとaudit
pushed_authorization_request_endpoint metadata

そのためラボではPAR endpointを提供せず、discoveryもrequest_uri_parameter_supported: falseのままです。章ではresolverの接続点と、実装に必要なcontractを示すところまでに限定します。

errorの境界

resolver未設定でrequest_uri → request_uri_not_supported
client_idなし → invalid_request
unknown/expired/consumed URI → invalid_request_uri
requestとrequest_uriを同時送信 → invalid_request

「未実装」を正常系fallbackにせず、明示的errorにすることが相互運用性を守ります。

Part 5のcheckpoint

BrowserへOAuth Tokenを渡さないBFFを説明できる
Client認証方式をClient能力とrotation要件から選べる
DCRを有効化する前のabuse policyを列挙できる
DPoP proofとAccess Tokenの結合を検証できる
PAR resolverと完全なPAR AS実装を区別できる

最後のPartでは、Node local labをCloudflareへ移す境界と、適合性の証拠を残す方法を扱います。