Cookie 回帰とは何か - SPA から BFF への認証設計の変化

中級 | 12分 で読める | 2026.06.14

公式ドキュメント

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に完全に戻るという意味ではありません。

戻ったのは、ブラウザから見える認証方式です。

観点現在
ブラウザ境界CookieCookie
サーバ側単一アプリが多いBFF、API、マイクロサービス
認証基盤自前実装が多いOAuth / OIDC / IDaaS
セッション保存メモリ、DBRedis、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 ↔ BFFHttpOnly Cookieブラウザにトークンを読ませない
BFF ↔ APIJWT / OAuth access tokenサーバ間で扱いやすい
Service ↔ ServiceJWT / 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 への認証設計の変化 を確認するための一次情報

次に読む記事

← 一覧に戻る
PR
PR
PR
PR