Cookie 回帰とは
Cookie 回帰とは、ブラウザとサーバの認証境界で、再びCookieセッションが評価されている流れを指します。
昔のWebアプリは、ブラウザがCookieを持ち、サーバがセッションを管理していました。
Browser -> Cookie -> Server
SPA時代には、ブラウザがJWTやアクセストークンを持ち、APIを直接呼ぶ構成が広まりました。
Browser -> Authorization: Bearer JWT -> API
現在は、BFFを挟み、ブラウザにはCookieだけを持たせ、JWTやOAuth tokenはサーバ側に閉じ込める構成が増えています。
Browser -> Cookie -> BFF -> JWT / OAuth token -> API
これが「Cookie 回帰」と呼ばれる流れです。
昔に戻ったわけではない
Cookie 回帰は、2005年頃のWebに完全に戻るという意味ではありません。
戻ったのは、ブラウザから見える認証方式です。
| 観点 | 昔 | 現在 |
|---|---|---|
| ブラウザ境界 | Cookie | Cookie |
| サーバ側 | 単一アプリが多い | BFF、API、マイクロサービス |
| 認証基盤 | 自前実装が多い | OAuth / OIDC / IDaaS |
| セッション保存 | メモリ、DB | Redis、KV、分散ストア |
| サーバ間認証 | あまり問題化しない | JWT、mTLS、Service Mesh |
つまり、ブラウザ境界ではCookieが再評価され、裏側は現代的に進化しています。
なぜ SPA 時代に JWT が広まったのか
React、Vue、Angular などのSPAでは、ブラウザがAPIを直接呼びます。
fetch("https://api.example.com/me", {
headers: {
Authorization: `Bearer ${token}`,
},
});
この構成では、ブラウザが認証情報を持つ必要が出ます。その保存先として localStorage が使われることがありました。
また、マイクロサービス化により、サーバ側セッションストアを共有せずに署名検証だけで認証したいという要求もありました。JWTはこの要求に合っていました。
何が問題になったのか
問題は、ブラウザに高価値なBearer Tokenを置くことです。
localStorage にJWTを置くと、XSS時に盗まれる可能性があります。
const token = localStorage.getItem("access_token");
盗まれたJWTは、攻撃者の環境からAPIへ送れます。
さらにJWTは、ステートレスに使うほど即時失効が難しくなります。ログアウトや管理者による強制停止を厳密にしたい場合、ブラックリストやトークンバージョンなどの状態管理が必要になります。
BFF が間に入る
BFFを置くと、ブラウザはBFFだけを呼びます。
Browser -> BFF -> API
ブラウザとBFFの間はCookieセッションにします。
Cookie: session_id=abc123
BFFとAPIの間は、JWTやOAuth access tokenを使います。
Authorization: Bearer access_token
この構成では、ブラウザにJWTを渡す必要がありません。
ポイント: Cookie 回帰の本質は、JWT を捨てることではありません。JWT をブラウザからサーバ側へ移すことです。
レイヤーごとの役割分担
現在の整理は、次のように考えると分かりやすいです。
| レイヤー | 認証方式 | 理由 |
|---|---|---|
| Browser ↔ BFF | HttpOnly Cookie | ブラウザにトークンを読ませない |
| BFF ↔ API | JWT / OAuth access token | サーバ間で扱いやすい |
| Service ↔ Service | JWT / mTLS | サービス間の認証を明示する |
「JWTが悪い」のではなく、「ブラウザのセッション管理にJWTを直接使う必然性が薄くなった」という整理です。
Server Components の影響
Next.js App Router の Server Components や Server Actions は、この流れと相性がよいです。
データ取得や更新処理をサーバ側で実行できるため、ブラウザがAPIトークンを直接扱う場面が減ります。
// サーバ側で実行される処理のイメージ
const session = await auth();
const orders = await fetchOrders(session.userId);
ただし、Server ComponentsがCookie回帰を生んだわけではありません。先に「ブラウザにトークンを置かない」というセキュリティ上の流れがあり、Server ComponentsやBFFが実装面でそれをやりやすくしました。
まとめ
Cookie 回帰とは、ブラウザ境界の認証をCookieセッションへ戻す流れです。
- 昔は Browser ↔ Server がCookieだった
- SPA時代に Browser ↔ API でJWTを直接持つ構成が広まった
- localStorage JWT はXSS時の窃取リスクがある
- JWTは即時失効も難しい
- BFFによりJWTをサーバ側へ隔離できる
- 現在は Browser ↔ BFF はCookie、BFF ↔ API はJWTという分担が現実的
実践メモ: Cookie 回帰は古い設計への退化ではなく、ブラウザに見せる認証面を小さくするための再整理です。
参考リソース
- 公式ドキュメント - Cookie 回帰とは何か - SPA から BFF への認証設計の変化 を確認するための一次情報