Public Clientから何を変えるか

React SPAは構造が見えやすい一方、実行中のJavaScriptはmemory上のTokenへ到達できます。XSS耐性や継続sessionを重視する場合、BrowserをOAuth Clientにせず、Backend for Frontend（BFF）をConfidential Clientにします。

Public ClientからBFFへToken ownershipを移す

ラボのBFFはNext.js App RouterをUI shellにし、/api/bff/*をHonoへ渡します。

import { handle } from 'hono/vercel'
import { app } from '../../../../src/app'

const handler = handle(app)
export const GET = handler
export const POST = handler

Honoを別サーバーにせずNext routeへmountするため、Browserから見えるoriginは一つです。

Browserが持つもの

BFF callbackはToken SetをBrowserへ返しません。32 byteのランダムsession IDを作り、BrowserへHttpOnly cookieとして渡します。DBにはsession IDそのものではなくSHA-256 hashを保存します。

Browser cookie: random session ID
BFF database:  SHA-256(session ID) -> encrypted Token Set

DB leakだけでBrowser sessionを再現しにくくし、cookie leakだけでは暗号化Tokenを直接読めないようにします。cookieはHttpOnly、SameSite=Lax、productionではSecureです。

Token Setを暗号化する

Access Token、Refresh Token、ID Token、取得時刻を一つのJSON envelopeとしてAES-256-GCMで暗号化します。12 byteのrandom IVを毎回生成し、version・IV・ciphertextを保存します。

暗号鍵はBFF_TOKEN_ENCRYPTION_KEYとしてprocessへ注入し、DBへ置きません。AES-GCMのauthentication tagにより、ciphertext改変はdecrypt時に失敗します。

BFFのAuthorization transaction

BFFもstate、PKCE、nonceが必要です。さらにloginを開始したBrowserとcallbackを結び付けるrandom binding cookieを作ります。

DB transactionには次を保存します。

hash(state)
hash(browser binding)
PKCE verifier
nonce
作成時刻

callbackではstateとbindingが両方一致し、10分以内であることを確認します。recordはToken交換前に削除してone-timeにします。

BFF callbackとserver-side Token storage

Resource APIをproxyする

Browserは/api/bff/notesをcookie付きで呼びます。BFFがDBからToken Setを復号し、RSへAuthorization headerを付けます。RSはBFFだから信頼するのではなく、Public Clientの場合と同じToken検証を行います。

BFFはCSRF対策も必要です。SameSite cookieだけへ依存せず、state-changing endpointではOrigin/CSRF tokenを検証するproduction hardeningを加えます。

何が解決し、何が残るか

BFFによりBrowser JavaScriptからOAuth Tokenを隠せます。しかしXSSがあれば、利用者のBrowserを使ってBFF endpointを呼ぶことはできます。Content Security Policy、output encoding、CSRF、session fixation対策は引き続き必要です。

次章では、BFFやIndexerがToken endpointで自分を認証する方式を比較します。