BFF とは何か - ブラウザには Cookie、サーバ間では JWT

初級 | 11分 で読める | 2026.06.14

公式ドキュメント

BFF とは

BFF は Backend For Frontend の略です。フロントエンド専用のバックエンドという意味です。

ブラウザが多数のAPIを直接呼ぶのではなく、ブラウザとAPI群の間にBFFを置きます。

Browser -> BFF -> API群

BFFは、画面に必要なデータを集約し、API呼び出しや認証処理をサーバ側で担当します。

なぜ BFF が必要になったのか

SPAとマイクロサービスが組み合わさると、ブラウザが多数のAPIを直接呼ぶ構成になりがちです。

Browser -> User API
Browser -> Order API
Browser -> Payment API
Browser -> Notification API

この構成では、ブラウザ側に集約ロジックが増えます。また、各APIを呼ぶためのアクセストークンをブラウザが持つことになりやすいです。

BFFを置くと、ブラウザはBFFだけを呼び、BFFが裏側のAPIを呼び分けます。

Browser -> BFF -> User API
              -> Order API
              -> Payment API
              -> Notification API

認証での BFF の価値

認証設計でBFFが重要なのは、アクセストークンやJWTをブラウザから隠せるからです。

典型的な構成は次の通りです。

境界認証方式
Browser ↔ BFFHttpOnly Cookie
BFF ↔ APIAuthorization: Bearer

ブラウザには HttpOnly Cookie だけを持たせます。JWTやOAuth access tokenはBFF側に保持します。

ポイント: BFF構成の肝は、ブラウザに高価値なBearer Tokenを渡さないことです。

ブラウザとBFFの間では、Cookieセッションを使います。

GET /dashboard HTTP/1.1
Host: app.example.com
Cookie: session_id=abc123

BFFはCookieを見て、ログイン済みユーザーか確認します。

const session = await getSession(req.cookies.session_id);

if (!session) {
  return redirect("/login");
}

このとき、ブラウザのJavaScriptはセッションIDを読む必要がありません。HttpOnly を付ければ、JavaScriptからセッションIDを隠せます。

BFF ↔ API は Bearer Token

BFFが裏側のAPIを呼ぶときは、JWTやOAuth access tokenを使います。

const res = await fetch("https://api.example.com/orders", {
  headers: {
    Authorization: `Bearer ${accessToken}`,
  },
});

ここでの accessToken はサーバ側にあります。ブラウザには渡しません。

つまり、JWTやaccess tokenの利用場所をブラウザからサーバ側へ移すわけです。

Next.js は BFF と相性がよい

Next.js App Routerでは、次のような機能を使ってBFF的な構成を作れます。

機能役割
Server Componentsサーバ側でデータ取得する
Route HandlersAPIエンドポイントを作る
Server Actionsフォーム送信や更新処理をサーバ側で行う
Middleware早期リダイレクトなどを行う

ただし、Next.jsを使えば自動的にBFFになるわけではありません。use client 中心で外部APIを直接呼ぶなら、ブラウザがトークンを扱う構成に戻ります。

BFF でも XSS 対策は必要

BFF + HttpOnly Cookie にすると、トークン窃取リスクは下がります。しかし、XSSそのものを防ぐわけではありません。

XSSがあれば、攻撃者はユーザーのブラウザ上でBFFへリクエストを送れる可能性があります。

fetch("/api/delete-account", {
  method: "POST",
});

Cookieはブラウザが自動で送るため、重要操作ではCSRF対策、XSS対策、再認証などを組み合わせます。

BFF のデメリット

BFFには利点だけでなく、コストもあります。

デメリット内容
サーバが必要静的SPAより構成が重くなる
実装責務が増えるAPI集約、認証、エラー処理を持つ
運用が必要ログ、監視、スケーリングが必要
キャッシュ設計が難しいユーザーごとのレスポンスが増える

それでも、認証トークンをブラウザに露出させたくない場合、BFFは有力な選択肢です。

まとめ

BFFは、ブラウザとAPI群の間に立つフロントエンド専用バックエンドです。

  • ブラウザはBFFだけを呼ぶ
  • ブラウザ ↔ BFF は HttpOnly Cookie
  • BFF ↔ API は JWT / OAuth access token
  • JWTをブラウザに渡さずサーバ側に隔離できる
  • Next.js、Nuxt、SvelteKitなどはBFF的に使いやすい
  • ただしXSSやCSRF対策は引き続き必要

参考リソース

  • 公式ドキュメント - BFF とは何か - ブラウザには Cookie、サーバ間では JWT を確認するための一次情報

次に読む記事

← 一覧に戻る
PR
PR
PR
PR