Mẫu BFF (Backend for Frontend) và bảo mật OAuth trên trình duyệt

1. Tổng quan

A. Định nghĩa

BFF (Backend for Frontend) là mẫu kiến trúc bố trí một tầng backend chuyên dụng cho mỗi loại client cung cấp trải nghiệm người dùng khác nhau như web, di động hay đối tác bên ngoài, và thực hiện việc kết hợp, chuyển đổi dữ liệu, bảo mật và tối ưu hiệu năng theo nhu cầu của chính client đó.

Cốt lõi của BFF là thoát khỏi tư duy "cung cấp một API đa dụng duy nhất cho mọi bên tiêu thụ", thay vào đó thiết kế API phía máy chủ theo ranh giới của trải nghiệm người dùng. Ứng dụng di động cần tiết kiệm pin và chi phí mạng, còn ứng dụng web có thể đòi hỏi dữ liệu phong phú theo từng màn hình và tốc độ render ban đầu nhanh. Đối tác bên ngoài không cần biết cấu trúc miền (domain) của dịch vụ nội bộ và có thể phải duy trì hợp đồng cũ trong một khoảng thời gian. Nếu cùng một backend cố gắng đáp ứng tất cả các yêu cầu này, các câu lệnh điều kiện và nhánh phiên bản sẽ không ngừng gia tăng.

BFF nằm giữa frontend và các dịch vụ miền nội bộ, nhưng không phải là tầng thay thế quy tắc nghiệp vụ của dịch vụ miền. BFF gọi nhiều dịch vụ để tạo ra mô hình đọc (read model) cần cho màn hình, phản hồi theo định dạng dễ hiểu với client và áp dụng chính sách xác thực, phiên, cache riêng cho từng client. Các bất biến (invariant) của nghiệp vụ cốt lõi như phê duyệt đơn hàng, trừ tồn kho, xác nhận thanh toán phải do các miền đơn hàng, tồn kho, thanh toán chịu trách nhiệm.

Microsoft Azure Architecture Center mô tả BFF là mẫu tạo dịch vụ backend riêng cho từng giao diện thay vì để nhiều giao diện frontend dùng chung một backend đa dụng (Microsoft Azure Architecture Center). Sam Newman mô tả nó là dịch vụ biên (edge service) đơn mục đích gắn chặt với một trải nghiệm người dùng cụ thể, và cho rằng nếu nhóm UI cùng sở hữu BFF thì việc điều phối thay đổi giữa UI và API sẽ dễ dàng hơn (Sam Newman, Backends For Frontends).

B. Bối cảnh ra đời và sự cần thiết

Trong hệ thống nguyên khối (monolithic), một máy chủ đảm nhận cả việc tạo màn hình lẫn xử lý nghiệp vụ nên sự khác biệt về yêu cầu giữa các client có thể được ẩn trong mã nguồn. Tuy nhiên, khi áp dụng microservice, để vẽ một màn hình phải gọi riêng lẻ các dịch vụ danh mục, giá, tồn kho, giao hàng, thành viên. Nếu client trực tiếp biết đồ thị lời gọi này, địa chỉ và mô hình dữ liệu của dịch vụ nội bộ sẽ bị cố định thành hợp đồng bên ngoài, và mọi client phải lặp lại việc xử lý độ trễ mạng cũng như sự cố.

API đa dụng ban đầu có vẻ tái sử dụng cao. Nhưng khi web, di động, kiosk và đối tác dùng chung endpoint, yêu cầu thêm trường của một bên tiêu thụ sẽ ảnh hưởng đến kích thước phản hồi và phạm vi bảo mật của bên khác. Nếu máy chủ cố gắng đáp ứng mọi yêu cầu riêng, các tham số như includeMobileFields, legacyVersion, compact=true sẽ tích tụ và ý nghĩa của API thay đổi tùy theo bên gọi. BFF cô lập những biến thể này vào bên trong ranh giới của từng client.

Ngoài ra, ứng dụng chạy trên trình duyệt phải quyết định lưu OAuth token ở đâu và làm mới nó như thế nào. Nếu JavaScript trên trình duyệt trực tiếp quản lý token, rủi ro token bị truy cập bởi script độc hại, tiện ích mở rộng trình duyệt hay tấn công chuỗi cung ứng sẽ tăng lên. IETF RFC 10017 công bố tháng 8/2026 so sánh ba mẫu, trong đó có BFF, như là thực hành tốt nhất OAuth 2.0 cho ứng dụng trình duyệt, và khuyến nghị mạnh mẽ kiến trúc BFF cho các ứng dụng xử lý nghiệp vụ nhạy cảm hoặc dữ liệu cá nhân (IETF RFC 10017).

C. Mục tiêu và phạm vi áp dụng

Mục tiêu của BFF có thể tóm tắt như sau.

Tối ưu phản hồi theo hình dạng dữ liệu và số lần gọi mà client cần.
Che giấu địa chỉ, topology và mô hình miền của dịch vụ nội bộ khỏi client.
Thực hiện tổng hợp và chuyển đổi theo màn hình ở phía máy chủ để giảm độ phức tạp cho client.
Nâng cao tốc độ phát hành độc lập và mức độ cô lập sự cố cho từng client.
Thực thi nhất quán chính sách phiên, token, kiểm toán và chống lạm dụng giữa trình duyệt và máy chủ tài nguyên.

Tuy nhiên, BFF không phải là tầng bắt buộc cho mọi ứng dụng. Nếu chỉ có một client và yêu cầu API đơn giản, nếu resolver và schema riêng cho frontend của GraphQL đã giải quyết đủ vấn đề, hoặc nếu chỉ API Gateway đã đáp ứng được yêu cầu định tuyến, xác thực, chuyển đổi, thì chi phí vận hành thêm của BFF có thể lớn hơn lợi ích.

2. Cấu trúc tổng thể và nguyên lý hoạt động

A. Kiến trúc logic

flowchart LR
  W[Frontend web] --> WBFF[Web BFF]
  M[Ứng dụng di động] --> MBFF[Mobile BFF]
  P[Hệ thống đối tác] --> PBFF[Partner BFF]
  WBFF --> G[API Gateway hoặc Ingress]
  MBFF --> G
  PBFF --> G
  G --> O[Dịch vụ đơn hàng]
  G --> C[Dịch vụ danh mục]
  G --> I[Dịch vụ tồn kho]
  G --> U[Dịch vụ thành viên·ID]
  WBFF --> OBS[Log·Metric·Tracing]
  MBFF --> OBS
  PBFF --> OBS

Trong cấu trúc trên, mỗi BFF được xem là một phần phía máy chủ của một trải nghiệm người dùng cụ thể. Web BFF đảm nhận tổng hợp dữ liệu và xử lý phiên cần cho màn hình trình duyệt, Mobile BFF rút gọn phản hồi hoặc gộp các lời gọi cho phù hợp với màn hình nhỏ và mạng không ổn định. Partner BFF chuyển đổi mô hình miền của dịch vụ nội bộ sang hợp đồng đối tác và áp dụng giới hạn tốc độ, chính sách phiên bản riêng cho từng đối tác.

Có thể đặt API Gateway phía sau BFF, nhưng hai tầng này không cùng một khái niệm. Gateway là tầng nền tảng đóng vai trò điểm vào của nhiều API, thực hiện định tuyến, xác thực chung, giới hạn tốc độ và kết thúc TLS. BFF là tầng gần sản phẩm hoặc miền, thiết kế API phù hợp với yêu cầu của một trải nghiệm rồi tổng hợp, chuyển đổi dữ liệu. Tùy tổ chức, một sản phẩm có thể đảm nhận cả hai vai trò, nhưng phải tách biệt trách nhiệm bằng văn bản để tránh nó trở thành middleware vạn năng trong quá trình vận hành.

B. Luồng xử lý yêu cầu màn hình

sequenceDiagram
  participant B as Browser
  participant F as Web BFF
  participant A as Authorization Server
  participant R as Resource Server
  participant O as Order Service
  participant C as Catalog Service
  participant T as Telemetry
  B->>F: Yêu cầu kiểm tra phiên
  F-->>B: Không có phiên hoặc trạng thái người dùng
  B->>F: Bắt đầu đăng nhập
  F->>A: Authorization Code + PKCE
  A-->>F: Chuyển hướng mã ủy quyền
  F->>A: Trao đổi mã, xác thực confidential client
  A-->>F: access/refresh token
  F-->>B: Cookie phiên HttpOnly·Secure·SameSite
  B->>F: Yêu cầu dữ liệu màn hình
  F->>R: Yêu cầu tài nguyên dựa trên token của phiên
  F->>O: Truy vấn tóm tắt đơn hàng
  F->>C: Truy vấn thông tin hiển thị sản phẩm
  O-->>F: Dữ liệu đơn hàng
  C-->>F: Dữ liệu sản phẩm
  F-->>B: Phản hồi riêng cho màn hình
  F-->>T: Telemetry kiểm toán·độ trễ·lỗi

Ở bước đầu tiên, trình duyệt gọi endpoint kiểm tra phiên của BFF. Nếu không có phiên hoạt động, BFF bắt đầu luồng Authorization Code với máy chủ ủy quyền. Trong mô hình BFF của RFC 10017, BFF là confidential OAuth client thay mặt trình duyệt, gắn access token và refresh token với phiên phía máy chủ mà không để lộ cho mã trình duyệt.

Sau khi đăng nhập, trình duyệt không trực tiếp gửi token cho từng API mà gửi cookie phiên tới BFF. BFF xác minh cookie rồi dùng token lưu ở phía máy chủ để gửi yêu cầu tới máy chủ tài nguyên. Cookie phải áp dụng HttpOnly, Secure, chính sách SameSite phù hợp và được vận hành cùng token chống CSRF hoặc kiểm tra cùng nguồn gốc (same-origin). Việc dùng cookie không có nghĩa CSRF tự động biến mất.

Với yêu cầu dữ liệu màn hình, BFF có thể gọi song song nhiều dịch vụ con. Nó kết hợp mã đơn hàng từ dịch vụ đơn hàng với tên sản phẩm từ dịch vụ danh mục để tạo mô hình màn hình, và nếu dịch vụ tồn kho chậm, có thể thiết kế để hiển thị riêng trạng thái tồn kho hoặc dùng giá trị đã cache. Tuy nhiên, các quyết định đòi hỏi tính nhất quán mạnh như số tiền thanh toán và trừ tồn kho không phải là tổng hợp đơn thuần mà phải gọi API lệnh (command API) của dịch vụ miền.

C. Ranh giới trách nhiệm của BFF

Trách nhiệm của BFF là chuyển đổi, tổng hợp và bảo vệ trong giới hạn trải nghiệm của client. Ví dụ, điều chỉnh kích thước trang của màn hình danh sách trên di động, kết hợp dữ liệu từ nhiều dịch vụ thành một DTO và loại bỏ trường không dùng đến là trách nhiệm của BFF. Chuyển đổi mã lỗi nội bộ mà client không hiểu thành trạng thái phù hợp với trải nghiệm người dùng cũng có thể thực hiện ở BFF.

Ngược lại, quy tắc tính giá, chuyển trạng thái đơn hàng, quyết định cuối cùng về quyền và tính nguyên tử của việc giữ chỗ tồn kho phải do dịch vụ miền chịu trách nhiệm. Nếu BFF sao chép logic nghiệp vụ này, quy tắc giữa BFF web và BFF di động sẽ khác nhau, và thay đổi chính sách của dịch vụ không được lan truyền tới mọi BFF. Trong bài làm của Kỹ sư chuyên nghiệp (Professional Engineer), không nên viết nguyên tắc "giữ BFF mỏng" như một khẩu hiệu mà phải giải thích logic nào đặt ở tầng nào dựa trên bất biến và chủ thể thay đổi.

3. Thành phần chính và nguyên tắc thiết kế

A. API riêng cho client và kết hợp dữ liệu

API của BFF được thiết kế xoay quanh màn hình hoặc hành trình người dùng thay vì phơi bày nguyên trạng endpoint của dịch vụ nội bộ. Ví dụ, /mobile/home có thể kết hợp gợi ý, đơn hàng gần đây, thông báo giao hàng thành một phản hồi cho màn hình di động. Khi đó, phản hồi được thiết kế theo nhu cầu render của màn hình, nên không tuần tự hóa nguyên trạng đối tượng Catalog nội bộ mà chỉ chọn các trường cần thiết và cấp độ công khai tương ứng.

Việc tổng hợp phải phân biệt lời gọi tuần tự và lời gọi song song. Truy vấn danh mục và tồn kho độc lập với nhau có thể song song hóa, nhưng nếu yêu cầu thứ hai cần kết quả của yêu cầu thứ nhất thì luồng tuần tự là không tránh khỏi. Song song hóa có thể giảm tổng độ trễ nhưng làm tăng số lời gọi con, vì vậy cần thiết kế đồng thời connection pool, timeout và giới hạn đồng thời.

Cách biểu diễn lỗi cục bộ của dịch vụ con cũng rất quan trọng. Nếu dịch vụ gợi ý lỗi mà màn hình lịch sử đơn hàng vẫn có thể hiển thị, BFF cần phân biệt mức ưu tiên giữa dữ liệu cốt lõi và dữ liệu tùy chọn. Ngược lại, nếu ở màn hình phê duyệt thanh toán mà việc xác minh tỷ giá hoặc phương thức thanh toán thất bại, không được trả về "phản hồi một phần" mà phải cung cấp đường thử lại hoặc phương án thay thế rõ ràng.

B. Cache và tối ưu phản hồi

BFF có thể áp dụng khóa cache và yêu cầu về độ mới của dữ liệu khác nhau cho từng client. Mô tả sản phẩm công khai có thể cache ở CDN hoặc reverse proxy, nhưng trạng thái đơn hàng cá nhân phải đưa người dùng, quyền và khu vực vào khóa. Để phản hồi đã cache không lẫn thông tin cá nhân, cần kiểm tra Cache-Control: private và vị trí lưu trữ, đồng thời đặt thời hạn lưu giữ log và cache theo phân loại dữ liệu.

Phản hồi tổng hợp cho màn hình có thể chứa dữ liệu từ nhiều nguồn với độ mới khác nhau. Nếu giá được cập nhật mỗi phút còn mô tả sản phẩm thay đổi mỗi ngày một lần, thay vì tùy ý đặt một TTL chung, cần thiết kế chiến lược cache theo thuộc tính dữ liệu. Khi dùng sự kiện vô hiệu hóa cache, phải tính đến việc mất sự kiện, đảo thứ tự và độ trễ lan truyền giữa các khu vực, và không để cache trở thành căn cứ duy nhất cho tính đúng đắn nghiệp vụ.

Tối ưu cho mạng di động không chỉ dừng ở việc làm JSON nhỏ hơn. Cần chỉ trả về trường cần thiết, gộp nhiều lượt khứ hồi thành một lời gọi tổng hợp, áp dụng phân trang và nén, đồng thời phân biệt yêu cầu đọc có thể thử lại với yêu cầu lệnh không được thử lại. Loại bỏ các trường nội bộ không hiển thị trên màn hình không chỉ giúp hiệu năng mà còn hỗ trợ tối thiểu hóa dữ liệu.

C. Lỗi, timeout và thử lại

Timeout tổng của BFF phải ngắn hơn hoặc bằng tổng timeout của các lời gọi con. Nếu không lan truyền deadline của yêu cầu cấp trên xuống lời gọi con, những yêu cầu mà client đã bỏ cuộc vẫn tiếp tục chiếm dụng tài nguyên nội bộ. Ví dụ, nếu ngân sách của yêu cầu màn hình là 800ms thì không được đặt timeout 1 giây không giới hạn cho từng lời gọi đơn hàng, danh mục, tồn kho.

Thử lại chỉ giới hạn cho truy vấn đảm bảo tính lũy đẳng (idempotency) hoặc lệnh có khóa lũy đẳng tường minh. Nếu tự động thử lại yêu cầu thanh toán chỉ vì thấy lỗi mạng, trong tình huống máy chủ đã thanh toán thành công nhưng chỉ mất phản hồi, sẽ xảy ra phê duyệt trùng lặp. BFF phải xác nhận hợp đồng lũy đẳng của dịch vụ miền và thiết lập đồng thời số lần thử lại, backoff, jitter và circuit breaker.

Lỗi của dịch vụ con phải được xử lý sao cho không che giấu nguyên nhân mà vẫn giữ hợp đồng với client ổn định. Không trả về stack trace nội bộ hay giá trị bí mật, mà trả về correlation ID để người vận hành tìm log. Phân biệt mã trạng thái HTTP, mã lỗi miền và khả năng thử lại giúp client không thử lại vô hạn một cách vô nghĩa.

D. Xác thực, phân quyền và phiên

Xác thực là quá trình xác nhận người dùng là ai, còn phân quyền là quá trình xác định người dùng đó có được dùng dữ liệu và chức năng cụ thể hay không. Dù BFF thực hiện xác thực OAuth, quyền truy vấn đơn hàng và quyền chức năng quản trị không tự động được cấp. BFF phải kiểm tra người dùng, client, phạm vi (scope) và tài nguyên đích của phiên, và dịch vụ miền cũng phải xác minh lại quyền bên trong ranh giới tin cậy.

Khi cấp cookie phiên cho trình duyệt, thời hạn của cookie phải phù hợp với chính sách thời hạn của phiên phía máy chủ và refresh token. Đăng xuất không chỉ là xóa cookie trên trình duyệt mà phải bao gồm hủy phiên phía máy chủ, thu hồi refresh token khi cần và ghi nhận kiểm toán liên quan. Cách xử lý các phiên đã cấp trong lúc xoay vòng khóa và hết hạn token phải được quy định trong runbook.

BFF là ranh giới bảo mật giữa trình duyệt bên ngoài và máy chủ tài nguyên nội bộ, nên cần kiểm tra SSRF, chuyển hướng mở (open redirect), tấn công host header, bom kích thước yêu cầu, chèn header và tấn công cố định phiên (session fixation). Không để đầu vào của client trực tiếp quyết định URL đích của proxy, mà giới hạn tài nguyên và đường dẫn được phép bằng ánh xạ phía máy chủ.

E. Khả năng quan sát và kiểm toán

BFF là nơi một yêu cầu người dùng được mở rộng thành nhiều lời gọi con, nên phải duy trì trace ID và quan hệ span. Các chỉ số chính cần thu thập gồm tổng độ trễ, độ trễ theo từng dịch vụ con, tỷ lệ tổng hợp thất bại, tỷ lệ trúng cache, lỗi làm mới token, sự gia tăng 401·403 và kích thước phản hồi. Nếu chỉ nhìn tỷ lệ 200 của BFF, có thể không phát hiện được những thành công một phần mà thiếu một số dữ liệu.

Log không ghi định danh người dùng dạng nguyên bản mà chỉ ghi correlation ID đã bí danh hóa và các thuộc tính tối thiểu cần thiết. Thông tin nhạy cảm như access token, refresh token, giá trị cookie, số định danh công dân phải được loại bỏ khỏi log, trace và phản hồi lỗi. Log kiểm toán phải truy vết được ai, khi nào, qua client nào, đã truy cập tài nguyên được bảo vệ nào, nhưng không được trở thành kho lưu bản sao nguyên văn của dữ liệu đã truy cập.

4. Phương thức áp dụng và so sánh

A. BFF và API Gateway

API Gateway có thế mạnh trong việc chuẩn hóa điểm vào chung của tổ chức như định tuyến, kết thúc TLS, chính sách chứng chỉ, giới hạn tốc độ, liên kết WAF, API key và đo lường mức sử dụng. Ngược lại, BFF mạnh ở việc kết hợp dữ liệu và hợp đồng API cho một trải nghiệm người dùng cụ thể. Nếu gateway đảm nhận mọi tổ hợp màn hình, thay đổi sẽ dồn về nhóm trung tâm; nếu mỗi BFF tự cài đặt lại mọi chức năng bảo mật chung, chính sách sẽ bị lệch nhau.

Hai thành phần này có thể kết hợp theo tầng thay vì thay thế nhau. Yêu cầu bên ngoài được kiểm soát mạng và nền tảng cơ bản tại API Gateway, BFF của từng client thực hiện phiên và kết hợp dữ liệu màn hình, sau đó dịch vụ nội bộ xác minh quyền miền và bất biến nghiệp vụ. Tuy nhiên, cần lập bảng trách nhiệm để các chức năng xác thực, giới hạn tốc độ, quan sát giống nhau không bị trùng lặp ở nhiều tầng khiến không rõ chính sách nào được áp dụng cuối cùng.

B. BFF và GraphQL

GraphQL cho phép client truy vấn đúng trường cần thiết và kết hợp nhiều nguồn bằng resolver, nên giải quyết được một phần vấn đề của BFF. Nếu vận hành tốt một schema cùng hệ thống resolver riêng cho frontend, có thể giảm số dịch vụ BFF riêng biệt. Tuy nhiên, GraphQL cũng phải giải quyết xác thực, phân quyền, giới hạn độ phức tạp truy vấn, lời gọi N+1, cache, thay đổi schema và khả năng quan sát, và máy chủ GraphQL trên thực tế có thể đóng vai trò BFF.

Lựa chọn giữa BFF và GraphQL không phải là sở thích giao thức mà là vấn đề tổ chức và ranh giới. Nếu nhiều client khám phá một đồ thị miền chung và tính chọn lọc trường là quan trọng, GraphQL có thể có lợi. Nếu ranh giới bảo mật và chu kỳ triển khai của từng client khác biệt lớn hoặc phải duy trì hợp đồng đối tác độc lập, tách BFF có thể rõ ràng hơn. Tài liệu của Microsoft cũng hướng dẫn rằng nếu resolver riêng cho frontend của GraphQL đã đủ, BFF có thể không mang lại giá trị bổ sung (Microsoft BFF pattern guidance).

C. BFF so với gọi trực tiếp và backend đa dụng

Khi client gọi trực tiếp microservice nội bộ, lợi ích là giảm một bước trung gian, nhưng việc phơi bày topology nội bộ, trùng lặp đồ thị lời gọi, cài đặt xác thực theo từng dịch vụ và sự chênh lệch trong xử lý sự cố sẽ tăng lên. Đặc biệt, nếu để lộ địa chỉ dịch vụ nội bộ và OAuth token trên trình duyệt, bề mặt tấn công có thể mở rộng. Ngược lại, một backend đa dụng đơn giản và dễ vận hành ở hệ thống giai đoạn đầu có ít dịch vụ, nhưng khi yêu cầu riêng của từng bên tiêu thụ tăng, nút thắt cổ chai và độ ghép nối có thể lớn dần.

BFF cung cấp ranh giới máy chủ theo trải nghiệm người dùng nằm giữa hai thái cực này. Nhưng khi thêm BFF, số bước mạng và đơn vị triển khai tăng lên. Do đó, cần lấy số lượng client, mức khác biệt yêu cầu, độ phức tạp lời gọi nội bộ, cấp độ bảo mật, quyền sở hữu của nhóm và mức tự động hóa vận hành làm tiêu chí đánh giá.

Hạng mục so sánh	Gọi trực tiếp	Backend API đa dụng	BFF	Lấy GraphQL làm trung tâm
Đơn vị tối ưu API	Mã client	Chung cho mọi bên tiêu thụ	Theo trải nghiệm người dùng	Theo truy vấn·resolver
Che giấu topology nội bộ	Thấp	Trung bình	Cao	Cao
Tổng hợp màn hình	Trùng lặp ở client	Tập trung	Tổng hợp theo trải nghiệm	Kết hợp resolver
Số dịch vụ vận hành	Ít	Ít~trung bình	Tỷ lệ với số client	Lấy nền tảng làm trung tâm
Triển khai độc lập theo client	Cao	Thấp	Cao	Cần chính sách schema
Rủi ro chính	Bảo mật·gọi trùng lặp	Nút thắt·đa dụng hóa	Chi phí vận hành·trùng lặp	Bùng nổ truy vấn·độ phức tạp

Sự khác biệt trong bảng xuất phát từ hướng của thay đổi hơn là số lượng chức năng. Với gọi trực tiếp, trách nhiệm thay đổi bị phân tán về từng client; với backend đa dụng, trách nhiệm thay đổi dồn về một nhóm. BFF đặt trách nhiệm vào nhóm gần client, đổi lại phải chấp nhận số lượng BFF và chi phí vận hành. GraphQL có được sự linh hoạt về hình dạng lời gọi nhưng phải tăng cường quản trị schema và resolver.

5. Tình huống áp dụng và quy trình triển khai

A. Tình huống thương mại điện tử trên di động và web

Giả sử dịch vụ thương mại điện tử có các kênh web, di động và đối tác. Màn hình chi tiết sản phẩm trên web yêu cầu ảnh độ phân giải cao, danh sách gợi ý, tóm tắt đánh giá và ngày giao dự kiến, còn di động do giới hạn dung lượng dữ liệu và màn hình nhỏ có thể chỉ cần ảnh đại diện và giá chính. Đối tác không được xem thuật toán gợi ý nội bộ hay thuộc tính thành viên mà chỉ dùng các trường sản phẩm, tồn kho theo hợp đồng.

Web BFF gọi các dịch vụ sản phẩm, đánh giá, gợi ý, giao hàng để tạo mô hình màn hình. Mobile BFF giảm kích thước ảnh và số trường, gộp nhiều yêu cầu đọc thành một. Partner BFF áp dụng API key hoặc OAuth client và hạn ngạch theo từng đối tác, đồng thời chuyển trạng thái sản phẩm nội bộ thành trạng thái công khai theo hợp đồng đối tác. Nhờ vậy, dù dịch vụ nội bộ thay đổi, vẫn duy trì được hợp đồng ổn định theo trải nghiệm cho từng bên tiêu thụ.

Ví dụ, giả sử mục tiêu của màn hình đầu tiên trên web là p95 700ms, BFF có thể song song hóa các lời gọi con và có đường thay thế chỉ trả về thông tin sản phẩm khi gợi ý lỗi. Đây là mục tiêu giả định để minh họa; SLO thực tế phải được xác định dựa trên hành vi người dùng và đường cơ sở đo được. Với luồng không được phép thất bại như phê duyệt thanh toán, không được áp dụng chính sách thành công một phần như màn hình gợi ý.

B. Tình huống OAuth trong hệ thống nghiệp vụ trên trình duyệt

Giả sử trong hệ thống nghiệp vụ khu vực công hoặc tài chính, một SPA trên trình duyệt gọi API dữ liệu cá nhân. Nếu mã trình duyệt trực tiếp lưu access token và refresh token, token có thể bị lộ qua XSS hoặc phụ thuộc độc hại. BFF giao tiếp với authorization server với tư cách confidential client và quản lý phiên, token ở phía máy chủ. Trình duyệt gọi BFF bằng cookie phiên HttpOnly, còn BFF chuyển access token tới máy chủ tài nguyên được bảo vệ.

RFC 10017 phân biệt BFF, token-mediating backend và OAuth client chạy trên trình duyệt. BFF là cấu trúc trong đó backend chuyển tiếp mọi tương tác API và không để lộ token cho trình duyệt, còn token-mediating backend khác ở chỗ chuyển token cho mã trình duyệt sử dụng. Cần so sánh mức độ bảo vệ và độ phức tạp cài đặt để lựa chọn phù hợp với mức nhạy cảm của nghiệp vụ.

Dù áp dụng BFF, XSS và CSRF không biến mất. XSS có thể lợi dụng phiên để tạo yêu cầu thay mặt người dùng, còn CSRF có thể lạm dụng yêu cầu xác thực dựa trên cookie. Cần áp dụng nhiều lớp gồm chính sách bảo mật nội dung (CSP), mã hóa đầu ra, kiểm tra phụ thuộc, thiết lập SameSite, token CSRF, xác minh Origin, xác thực lại và phát hiện bất thường.

C. Quy trình triển khai theo từng giai đoạn

Khảo sát bên tiêu thụ và lịch sử thay đổi: Lập danh mục lời gọi API, yêu cầu dữ liệu, chu kỳ phát hành và các sự cố theo web, di động, đối tác.
Xác định ranh giới và chủ sở hữu: Quyết định trải nghiệm mà BFF đảm nhận, trách nhiệm của dịch vụ miền và các chức năng chung của API Gateway.
Chọn thí điểm thiên về đọc: Bắt đầu từ dashboard, truy vấn sản phẩm là những nơi dễ cô lập lỗi hơn các lệnh thanh toán hay tồn kho.
Thiết kế hợp đồng: Định nghĩa DTO riêng cho client, chính sách phiên bản, mô hình lỗi, phân trang, mức nhạy cảm của trường và chính sách loại bỏ.
Đo đường cơ sở hiệu năng: So sánh với gọi trực tiếp và API đa dụng hiện có để đo p50·p95·p99, số lời gọi, payload, CPU·bộ nhớ.
Thiết kế bảo mật: Phản ánh loại OAuth client, PKCE, cookie phiên, CSRF, lưu trữ token, che log và xác minh quyền vào mô hình mối đe dọa.
Xây dựng khả năng quan sát: Tạo trước việc lan truyền trace context, span theo từng lời gọi con, phân loại lỗi và thành công một phần, chỉ số ảnh hưởng người dùng.
Chuyển đổi dần dần: Chuyển từ một nhóm người dùng bằng feature flag hoặc trọng số định tuyến, và rollback dựa trên lỗi, độ trễ, sự kiện bảo mật.
Chuyển giao quyền sở hữu và tự động hóa vận hành: Văn bản hóa trách nhiệm triển khai, trực sự cố, vá lỗ hổng và chi phí giữa nhóm UI và nhóm BFF.
Đánh giá lại việc mở rộng: Kiểm tra sự khác biệt yêu cầu giữa các client có thực sự được duy trì hay không, và không tăng số BFF tương tự một cách gượng ép.

6. Chuyên sâu — RFC 10017 và BFF hướng bảo mật

IETF RFC 10017 là RFC 10017 (BCP 212) được phát hành dưới dạng Best Current Practice vào tháng 8/2026. Tài liệu tổng hợp các mối đe dọa và khuyến nghị bảo mật cho ứng dụng OAuth trên trình duyệt, đồng thời mô tả BFF không chỉ là mẫu tổng hợp dữ liệu đơn thuần mà là ranh giới OAuth client giữa trình duyệt và tài nguyên được bảo vệ (IETF Datatracker, RFC 10017).

Ba trách nhiệm cốt lõi của BFF do RFC 10017 đưa ra rất rõ ràng. Thứ nhất, BFF tương tác với authorization server với tư cách confidential OAuth client. Thứ hai, BFF lưu access token và refresh token trong ngữ cảnh phía máy chủ của phiên dựa trên cookie, không để lộ trực tiếp cho ứng dụng trình duyệt. Thứ ba, BFF chuyển yêu cầu của trình duyệt tới máy chủ tài nguyên được bảo vệ đồng thời gắn access token đúng.

Khuyến nghị này mở rộng cách hiểu BFF trước đây là "API tổng hợp cho màn hình di động" thành một kiến trúc bảo mật. Trong bài làm của Kỹ sư chuyên nghiệp, thay vì viết BFF là một proxy đơn thuần, nên mô tả nó là ranh giới đồng thời thực hiện hợp đồng API theo client và bảo vệ token, phiên phía máy chủ. Tuy nhiên, hiệu quả bảo mật của BFF phụ thuộc vào chất lượng cài đặt, nên phải kèm theo các biện pháp kiểm soát chiếm đoạt phiên, CSRF, SSRF, chuyển hướng mở và rò rỉ log.

Ngay cả khi ứng dụng trình duyệt phải trực tiếp thực hiện OAuth với tư cách public client, việc áp dụng Authorization Code + PKCE, tối thiểu hóa lưu trữ token và phòng thủ trước tấn công trên trình duyệt vẫn quan trọng. BFF không phải lúc nào cũng khả thi, nên cần so sánh các ràng buộc thực tế như cấu hình mạng, mô hình triển khai, tác động tới dữ liệu cá nhân, trải nghiệm người dùng và thời hạn token. Không nên hiểu nhầm khuyến nghị của RFC là mệnh lệnh áp dụng sản phẩm mà cần gắn nó với mô hình mối đe dọa và rủi ro nghiệp vụ.

7. Lưu ý và hàm ý

A. Cân bằng giữa hiệu năng và chi phí

BFF có thể giảm số lượt khứ hồi nhờ tổng hợp nhưng lại tạo ra lời gọi con phía máy chủ và thêm bước mạng. Cần kiểm tra bằng thử tải xem khi số lời gọi tăng, connection pool và thread có bị cạn kiệt không, và fan-out tới dịch vụ con có khuếch đại sự cố không. Không chỉ nhìn độ trễ trung bình mà phải đánh giá cả p95·p99 và tỷ lệ hoàn thành hành trình người dùng.

Mỗi BFF cần runtime, pipeline triển khai, vá bảo mật, giám sát và vận hành trực sự cố riêng. Khi số client tăng, việc tăng số dịch vụ tuyến tính không phải lúc nào cũng là đáp án. Các client có yêu cầu tương tự có thể dùng chung một BFF, nhưng gượng ép gộp các yêu cầu khác nhau sẽ lại tạo nút thắt của backend đa dụng, vì vậy cần văn bản hóa tiêu chí dùng chung.

B. Trùng lặp và ranh giới trách nhiệm

Mỗi BFF có thể phát sinh mã gọi dịch vụ con tương tự nhau. Nếu tạo thư viện chung và BFF trung tâm để loại bỏ hoàn toàn trùng lặp, lợi thế triển khai độc lập sẽ giảm. Nên chia ranh giới theo cách dùng chung các thư viện xác thực, truy vết, xử lý lỗi ổn định, còn quy tắc kết hợp trải nghiệm client và hợp đồng UI thì do từng BFF sở hữu.

Nếu logic nghiệp vụ miền lọt vào BFF, rủi ro kết quả khác nhau giữa web và di động sẽ tăng. Cần ghi lại bằng ADR và hợp đồng API các bất biến mà dịch vụ miền phải đảm bảo, các chuyển đổi biểu diễn mà BFF được phép thực hiện và logic hiển thị mà client chịu trách nhiệm. Khi rà soát thay đổi, cũng phải đánh giá dựa trên chủ sở hữu của quy tắc nghiệp vụ thay vì vị trí của mã.

C. Bảo mật và bảo vệ dữ liệu cá nhân

BFF là điểm tập trung mà token nhạy cảm và dữ liệu cá nhân đi qua. Cần vận hành đồng thời mã hóa kho lưu phiên, xoay vòng khóa, tách quyền truy cập, quản lý bí mật, log kiểm toán, vá lỗ hổng, WAF và rate limit. Cần kiểm tra định kỳ xem cache phản hồi theo người dùng có bị cấp cho người dùng khác không và dữ liệu lỗi, truy vết có chứa dữ liệu cá nhân nguyên bản không.

Phiên dựa trên cookie trình duyệt cần phòng chống CSRF và ngăn cố định phiên. Không nên giả định chỉ SameSite đã giải quyết được mọi trình duyệt và kịch bản liên kết, mà phải kết hợp xác minh Origin·Referer và token CSRF tương ứng với mức rủi ro. OAuth redirect URI chỉ chấp nhận giá trị chính xác đã đăng ký trước, từ chối khi xác minh state và PKCE thất bại, và chặn chuyển hướng mở tại các endpoint đăng nhập, đăng xuất.

D. Tính sẵn sàng và cô lập sự cố

Nếu BFF trở thành backend chung duy nhất của web và di động, nó ngược lại có thể trở thành điểm lỗi tập trung. Nếu lý do tách BFF theo client là cô lập sự cố, thì triển khai, cache, kho lưu phiên, auto scaling và trực sự cố cũng phải thực sự được tách riêng. Cần kiểm tra xem có một cơ sở dữ liệu dùng chung hay message bus chung nào đang ràng buộc đồng thời toàn bộ các BFF hay không.

Cần phân biệt màn hình được phép thành công một phần với nghiệp vụ phải thất bại toàn bộ. Gợi ý, quảng cáo, đánh giá có thể chấp nhận phản hồi thay thế, nhưng số tiền thanh toán, quyền và giữ chỗ tồn kho không được thay bằng cache tùy ý hay giá trị rỗng. Cần thiết kế fallback theo chức năng dựa trên ngân sách lỗi (error budget) và cấp độ ảnh hưởng người dùng, và kiểm chứng bằng chaos test và diễn tập khôi phục.

E. Khả năng quan sát và kiểm thử hợp đồng

Kiểm thử hợp đồng của BFF phải xác minh cấu trúc phản hồi và ý nghĩa lỗi mà client mong đợi có được duy trì hay không. Đưa consumer-driven contract của dịch vụ con, kiểm tra tương thích schema và kiểm thử hồi quy dựa trên phản hồi mẫu vào CI. Nếu không kiểm thử các kịch bản bao gồm thứ tự tổng hợp và lỗi cục bộ, đó chỉ là kiểm thử nông chỉ xác nhận phản hồi bình thường.

Khả năng quan sát phải cho thấy đồ thị lời gọi được mở rộng thông qua BFF. Gắn trace ID với phản hồi lỗi của client nhưng không để lộ token hay dữ liệu cá nhân, và truy vết đường đi mà độ trễ của dịch vụ con dẫn đến độ trễ màn hình. SLO không chỉ được định nghĩa theo đơn vị BFF mà còn theo hành trình người dùng và chức năng cốt lõi.

F. Quyết định áp dụng từ góc độ Kỹ sư chuyên nghiệp

Quyết định áp dụng BFF không phải là công thức "cứ microservice là BFF" mà là hàm của sự khác biệt giữa các bên tiêu thụ và năng lực vận hành của tổ chức. Nếu hình dạng dữ liệu, bảo mật, chu kỳ phát hành của từng client khác nhau lớn, cần tổng hợp màn hình và bảo vệ token, và các nhóm theo trải nghiệm có thể tự chủ vận hành triển khai, thì giá trị của BFF cao.

Ngược lại, nếu chỉ có một client hoặc yêu cầu gần như giống nhau, và API Gateway cùng API miền hiện có đã đủ đơn giản, BFF có thể trở thành bước trung gian và chi phí vận hành không cần thiết. Trước khi áp dụng, cần xác định đường cơ sở, SLO mục tiêu, quyền sở hữu của nhóm, mô hình mối đe dọa bảo mật, trần chi phí và điều kiện rút lui. Sau khi áp dụng, cần đo lường kết quả như thời gian dẫn thay đổi (lead time) của bên tiêu thụ, cô lập sự cố, giảm lộ token, cải thiện độ trễ người dùng thay vì số lượng BFF.

Tài liệu tham khảo

Tóm tắt một câu: BFF là mẫu thực hiện tổng hợp, chuyển đổi, tối ưu hiệu năng và bảo vệ phiên, token OAuth tại backend chuyên dụng cho từng trải nghiệm client, trong khi để lại bất biến miền cho dịch vụ nội bộ và phải đánh giá đồng thời chi phí vận hành, bảo mật, tính sẵn sàng và quyền sở hữu của nhóm.