protocol coreとruntime adapterを分ける

local labでHonoを選んだ理由の一つは、app.fetchを中心にruntime adapterを交換できることです。Nodeでは次のlistenerを使いました。

import { serve } from '@hono/node-server'

serve({ fetch: app.fetch, hostname, port })

Cloudflare WorkersではHono appをそのままdefault exportします。

export default app

Authorization endpointやToken検証をruntimeごとに書き直すのではなく、DB connection、environment binding、静的asset配信、background workだけをadapter境界へ寄せます。

production topology

本書の移行先は次です。

auth.example.com   Cloudflare Worker + React assets + Better Auth/Hono
app.example.com    Cloudflare Worker + React public client assets
api.example.com    Cloudflare Worker + Hono Resource API
bff.example.com    Next.js Node runtime + Hono route + BFF database

BFFはNode runtimeに残します。Next.jsのserver機能とserver-side Token storageを、AS/RSのWorker移行へ無理に巻き込みません。移行単位をrole境界と合わせます。

database adapter

local schemaはPostgreSQL/Drizzleです。productionでもPostgreSQLを維持する場合、WorkerからHyperdriveなどの接続層を介し、requestごとに無制限connectionを作らないようにします。

D1へ変える場合は単なるconnection string差替えではありません。dialect、timestamp、transaction、index、migration、Better Auth adapter互換性を再検証します。本書は「CloudflareだからD1へ変換」を暗黙に行いません。

AS DBとNotes DBはcredentialもbindingも分けます。Resource WorkerへAuth DBのwrite credentialを渡さず、JWT local verificationか限定されたintrospection credentialを使います。

originとClient metadataを更新する

productionではすべてHTTPSです。

advanced: {
  useSecureCookies: true,
  crossSubDomainCookies: { enabled: false }
}

local HTTPのためapplication_type: nativeにしたReact/BFF registrationをそのまま持ち込みません。HTTPS Redirect URIを登録し、Browser SPAはpublic web Client、BFFはconfidential web Clientとしてmetadataを作り直します。

issuerはhttps://auth.example.com/api/authのように一度決めたら安易に変えません。JWT、OIDC subject namespace、discovery cache、Client設定がissuerへ結び付きます。

secretとkeyの移行

BETTER_AUTH_SECRETをdeployment secretとして設定
Client SecretとBFF暗号鍵をsecret managerへ置く
JWT signing keyは永続DBでrotation可能にする
.local/clients.jsonをuploadしない
previewとproductionでissuer・DB・Client IDを分離

build-time public variableへClient Secretを入れないようにします。Public Client IDやpublic originはbundleに含めても構いません。

Worker固有の確認

crypto.subtleとEd25519/ES256がtarget compatibility dateで動く
Honoがrequest URLをproxy後のpublic originとして認識する
Set-Cookie、redirect Location、CORSがcacheされない
OAuth/Token responseへCache-Control: no-storeが付く
rate limitとDPoP replay storeが複数isolateで共有される
log samplingでもcredentialを記録しない

deploy成功だけではprotocol成功を示しません。production-like previewでdiscovery、JWKS、Code + PKCE、introspection/JWT、logoutを再実行します。

次章で、これらを継続的な適合性証拠として整理します。