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

中級 | 8分 で読める | 2026.06.14

公式ドキュメント
JWTAuth

「Cookie回帰」は標準規格の用語ではなく、ブラウザにBearer Tokenを直接持たせず、Cookieを使ってBFFやサーバーとのセッションを管理する設計を再評価する動きを表す通称です。

昔のWebアプリは、ブラウザがCookieを持ち、サーバがセッションを管理していました。

Browser -> Cookie -> Server

SPA時代には、ブラウザがJWTやアクセストークンを持ち、APIを直接呼ぶ構成が広まりました。

Browser -> Authorization: Bearer JWT -> API

BFFを挟み、ブラウザにはCookieだけを持たせ、OAuth access tokenなどをサーバー側で管理する構成も選択できます。

Browser -> Cookie -> BFF -> OAuth access tokenなど -> API

この記事では、この構成を「Cookie回帰」の例として扱います。すべてのSPAにBFFが必要という意味ではありません。

昔に戻ったわけではない

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はその選択肢の一つです。ただし、署名が正しいだけでは信用できず、発行者、受信者、有効期限、用途などの検証が必要です。

何が問題になったのか

問題になりやすいのは、JavaScriptから読める場所に高価値なBearer Tokenを長期間置くことです。

localStorage にJWTを置くと、XSS時に盗まれる可能性があります。

const token = localStorage.getItem("access_token");

盗まれたBearer Tokenは、攻撃者の環境からAPIへ送れる可能性があります。

さらに、自己完結型JWTを状態を持たずに検証する設計では、期限前の即時失効が難しくなります。ログアウトや管理者による強制停止を厳密にしたい場合、短い有効期限や失効確認などを設計します。

BFF が間に入る

ブラウザとBFFの境界ではHttpOnly Cookie、BFFとbackend APIの境界ではserver管理tokenを使い分け、tokenをbrowserへ露出しない構成図

BFFを置くと、ブラウザはBFFだけを呼びます。

Browser -> BFF -> API

ブラウザとBFFの間はCookieセッションにします。

Cookie: session_id=abc123

BFFとAPIの間は、OAuth access tokenなど、API側が受け入れる認証情報を使います。トークンはJWT形式とは限りません。

Authorization: Bearer access_token

この構成では、ブラウザにJWTを渡す必要がありません。

ポイント: Cookieは保存・送信の仕組み、JWTはトークンの形式です。対立する技術ではありません。判断軸は、どの認証情報をどの境界に置き、誰が読めるようにするかです。

レイヤーごとの役割分担

現在の整理は、次のように考えると分かりやすいです。

レイヤー認証方式理由
Browser ↔ BFFHttpOnly Cookieの例JavaScriptからセッション値を読ませない
BFF ↔ APIOAuth access tokenなどAPIの契約に従ってサーバー側で管理
Service ↔ ServiceJWT、mTLSなどサービス間の認証を明示する

HttpOnlyはJavaScriptによる値の読み取りを防ぎますが、XSSそのものや、被害者のブラウザから不正操作を送られることまでは防ぎません。Cookieは自動送信されるため、SameSite、CSRFトークン、Originの確認、安全でないHTTPメソッドの扱いなどを組み合わせます。

Server Componentsとの関係

Next.js App Router の Server Components や Server Actions は、この流れと相性がよいです。

データ取得や更新処理をサーバ側で実行できるため、ブラウザがAPIトークンを直接扱う場面が減ります。

// サーバ側で実行される処理のイメージ
const session = await auth();
const orders = await fetchOrders(session.userId);

これはNext.jsでの実装例であり、CookieセッションやBFFに必須の技術ではありません。

まとめ

Cookie回帰は標準用語ではなく、ブラウザへ直接Bearer Tokenを露出しない設計を説明する通称です。

  • 昔は Browser ↔ Server がCookieだった
  • SPA時代に Browser ↔ API でJWTを直接持つ構成が広まった
  • localStorage JWT はXSS時の窃取リスクがある
  • 自己完結型JWTは、状態を持たずに検証すると期限前の失効が難しい
  • BFFによりaccess tokenをサーバー側で管理できる
  • Browser ↔ BFFをCookie、BFF ↔ APIをaccess tokenにする構成は選択肢の一つ
  • HttpOnly CookieでもXSSとCSRFへの別の対策が必要

実践メモ: CookieかJWTかという二択ではなく、認証情報の価値、保存場所、送信先、失効方法、XSS・CSRF対策を境界ごとに決めます。

参考リソース

次に読む記事

おすすめ記事

← 一覧に戻る
PR
PR
PR
PR