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 ↔ BFF | HttpOnly Cookie |
| BFF ↔ API | Authorization: Bearer |
ブラウザには HttpOnly Cookie だけを持たせます。JWTやOAuth access tokenはBFF側に保持します。
ポイント: BFF構成の肝は、ブラウザに高価値なBearer Tokenを渡さないことです。
Browser ↔ BFF は Cookie
ブラウザと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 Handlers | APIエンドポイントを作る |
| 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 を確認するための一次情報