同じ人でもroleは別物

OAuth 2.0はRFC 6749で4つのroleを定義しています。

Resource Owner: ノートへの権限を持つ利用者
Client: 利用者の代わりにノートへアクセスしたいアプリ
Authorization Server（AS）: 利用者を確認し、委譲を記録してTokenを発行するサーバー
Resource Server（RS）: Access Tokenを検証し、ノートを返すAPI

Clientは利用者本人ではありません。Resource Ownerがログイン済みでも、Clientが自動的にnotes:writeを得ることはありません。逆にClient Credentials GrantではResource Ownerが登場せず、Client自身が主体になります。「誰のためのTokenか」を曖昧にしないことが最初の設計条件です。

OAuthラボのroleと信頼境界

credentialを所有者で分類する

ラボには似た文字列が複数登場します。

credential	所有者	送信先	Browserから読めるか
Better Auth session cookie	Resource OwnerとAS	ASのみ	HttpOnlyなので不可
Authorization Code	Clientの一時transaction	AS Token endpoint	callbackでは可、即時交換
Access Token	Public ClientまたはBFF	RS	Public Client版だけメモリ上で可
Refresh Token	Tokenを得たClient	AS Token endpoint	BFF版では不可
Client Secret	Confidential Client	AS	不可

ここで重要なのは、CookieとAccess Tokenを同じ「ログイン情報」と呼ばないことです。CookieはASに対する利用者sessionです。Access TokenはRSに提示する委譲credentialです。用途も受取人も違います。

PortはCookie境界ではない

Cookieのhost-only属性はportを見ません。http://localhost:4100のCookieを、同じlocalhostの別portから完全に分離できると考えてはいけません。

ラボはBrowserから見えるhostを次のように分けます。

AS      http://localhost:4100
Client  http://127.0.0.1:4200
RS      http://127.0.0.3:4300
BFF     http://[::1]:4400

ASの内部Hono listenerは127.0.0.1:4110ですが、Browserは直接アクセスしません。Viteが/api/authと/.well-knownだけをproxyします。この二重adapterにより、開発時はReact UIとHono APIを一つのissuer originとして見せ、本番ではWorkerと静的assetを同じoriginへ統合できます。

CORSはTokenの権限を決めない

RSはPublic ClientとBFFのoriginだけをCORS allowlistへ入れます。しかしCORSはBrowserの読取り制御であり、Access Tokenの認可判定ではありません。curlや別サーバーはCORSに拘束されないため、RSは必ずTokenの署名またはintrospection結果、audience、scopeを検証します。

この区別は攻撃テストで確認できます。Originが正しくてもTokenがなければ401です。逆に正しいTokenをサーバー間で送る処理はOrigin headerがなくても成立します。

不変条件

この章で固定する不変条件は次のとおりです。

AS session cookieをClientやRSの認可に使わない
Client SecretをBrowser bundleへ入れない
ID TokenをRSへ送らない
Access TokenをASへのログインsessionとして使わない
CORSをscope検証の代わりにしない

次章では、この境界を壊さずに各processとdatabaseを起動する方法を作ります。