Open Banking và Open API Spec: Giao tiếp bảo mật giữa ngân hàng và TPP
Hướng dẫn kiến trúc Open Banking và Open API Spec: FAPI 2.0, OAuth 2.0/OIDC, PAR, PKCE, mTLS/DPoP, consent management, TPP onboarding, API security và vận hành.
ShanverseCập nhật 11 phút đọc— lượt xemĐang tải lượt xem
Open Banking
API Security
Payment Systems
Không có một Open Banking Spec duy nhất cho toàn thế giới
Các thị trường áp dụng profile khác nhau:
UK Open Banking có API specifications, security profile và conformance suite riêng.
Berlin Group NextGenPSD2 chuẩn hóa XS2A cho Account Information, Payment Initiation và các use case liên quan tại châu Âu.
OpenID Foundation FAPI cung cấp security profile dựa trên OAuth 2.0/OIDC cho API rủi ro cao.
Việt Nam có Thông tư 64/2024/TT-NHNN về triển khai giao diện lập trình ứng dụng mở trong ngành Ngân hàng.
Vì vậy cần tách ba lớp:
Business API specification: account, balance, transaction, consent, payment.
Regulatory and trust framework: ai được làm TPP, onboarding, certificate, consent, audit, liability và conformance.
OpenAPI YAML chỉ mô tả contract HTTP; nó không tự biến API thành Open Banking an toàn.
Các vai trò chính
ASPSP/Bank: ngân hàng hoặc đơn vị quản lý tài khoản.
PSU/Customer: chủ tài khoản cho phép truy cập dữ liệu hoặc khởi tạo thanh toán.
TPP: bên thứ ba được đăng ký/ủy quyền, có thể cung cấp dịch vụ thông tin tài khoản hoặc khởi tạo thanh toán.
Authorization Server: xác thực khách hàng, quản lý consent và phát token.
Resource Server: cung cấp Open API được bảo vệ.
Directory/Trust Service: xác nhận danh tính, vai trò, certificate và trạng thái của TPP.
Đăng nhập khách hàng và xác thực TPP là hai việc khác nhau. Một access token hợp lệ không đủ nếu client certificate, TPP role hoặc consent đã bị thu hồi.
Kiến trúc tham khảo
Mermaid
Loading diagram…
FAPI 2.0 mang lại điều gì?
FAPI 2.0 Security Profile là profile OAuth cho môi trường tài chính/rủi ro cao. Nó thu hẹp các lựa chọn OAuth, yêu cầu các flow và kiểm soát chặt hơn nhằm giảm authorization-code injection, token replay, mix-up và client impersonation.
Một baseline hiện đại thường gồm:
Authorization Code Flow; không dùng Implicit Flow.
PKCE với phương thức mạnh cho mọi authorization request phù hợp profile.
PAR — Pushed Authorization Requests — để TPP gửi request trực tiếp đến authorization server trước khi redirect browser.
Client authentication bằng private_key_jwt hoặc cơ chế chứng thư phù hợp profile.
Sender-constrained access token bằng mTLS hoặc DPoP theo profile đã chọn.
Redirect URI được đăng ký chính xác; không wildcard tùy tiện.
state, nonce, issuer validation và chống replay.
Access token ngắn hạn; refresh token rotation hoặc cơ chế profile quy định.
Signed authorization requests/responses khi profile Message Signing hoặc chuẩn khu vực yêu cầu.
Không tự “trộn” mTLS, DPoP, JAR/JARM và các thuật toán theo sở thích. Chọn một conformance profile được hỗ trợ end-to-end và kiểm thử bằng suite chính thức.
mTLS và DPoP: chống token bị đánh cắp tái sử dụng
Bearer token thông thường có thể bị dùng bởi bất kỳ ai sở hữu nó. Sender-constrained token ràng buộc token với client:
Mutual TLS
TPP trình client certificate khi kết nối TLS. Authorization server đưa certificate thumbprint vào token; resource server chỉ chấp nhận token trên kết nối dùng đúng certificate.
Ưu điểm: mô hình PKI mạnh, phổ biến trong tài chính. Thách thức: certificate lifecycle, proxy/LB termination, trust store, rotation và quan sát lỗi mTLS.
DPoP
Client ký proof JWT bằng private key riêng cho từng request. Proof thường ràng buộc HTTP method, URI, thời điểm và token hash. Resource server kiểm tra chữ ký, freshness và replay.
Ưu điểm: sender constraint ở application layer, phù hợp một số kiến trúc không tiện end-to-end mTLS. Thách thức: nonce/replay cache, canonical URI, clock skew và bảo vệ key.
Đừng dùng cùng lúc hai cơ chế nếu profile không yêu cầu. Complexity không tự tạo thêm an toàn.
Consent là tài nguyên nghiệp vụ, không chỉ là OAuth scope
OAuth scope như accounts.read quá thô để mô tả đầy đủ consent tài chính. Consent nên có:
Consent lifecycle điển hình:
Màn hình consent phải cho khách biết TPP nào, dữ liệu gì, mục đích gì, thời hạn bao lâu và cách thu hồi. TPP chỉ nhận đúng dữ liệu cần thiết. Thu hồi consent phải vô hiệu hóa truy cập thực tế, không chỉ đổi một cột UI.
Authorization flow an toàn
Mermaid
Loading diagram…
TPP không nên thu thập hoặc chuyển tiếp credential ngân hàng của khách hàng. Khách xác thực trực tiếp trên domain/app ngân hàng.
TPP onboarding và trust framework
Trước khi gọi production API, TPP thường phải:
Được đăng ký/được phép theo quy định thị trường.
Có software statement, organization ID, roles và contact.
Đăng ký redirect URIs, JWKS và certificate.
Chứng minh quyền sở hữu key.
Vượt qua functional/security conformance test.
Được giám sát trạng thái giấy phép/certificate sau onboarding.
Dynamic Client Registration không có nghĩa bất kỳ client Internet nào cũng tự đăng ký. Nó phải nằm sau trust framework và policy.
Certificate rotation cần overlap an toàn, audit và rollback. Hệ thống phải xử lý trường hợp TPP bị thu hồi quyền ngay cả khi token chưa hết hạn.
API resources cốt lõi
Một Open Banking API thường có:
POST /account-access-consents
GET /account-access-consents/{consentId}
DELETE /account-access-consents/{consentId} hoặc endpoint revoke theo spec.
GET /accounts
GET /accounts/{accountId}/balances
GET /accounts/{accountId}/transactions
POST /payment-consents
POST /payments
GET /payments/{paymentId}
GET /.well-known/openid-configuration
Tên resource, header và status code phải theo chuẩn thị trường đã chọn; không sao chép tùy tiện giữa UK OB, Berlin Group và profile nội bộ.
OpenAPI contract nên mô tả gì?
Contract production cần thêm:
JSON Schema chặt, enum và format.
Error model thống nhất, không lộ dữ liệu nhạy cảm.
Pagination/cursor và giới hạn time range.
x-request-id, correlation/trace ID.
Idempotency key cho payment initiation.
Rate-limit headers theo policy.
Versioning và deprecation dates.
Webhook/event schemas nếu có.
Ví dụ đã mask, không chứa dữ liệu production.
OpenAPI file không nên chứa secret, private endpoint hoặc credential thật.
Bảo vệ Account Information API
Resource server phải kiểm tra đồng thời:
JWT signature, iss, aud, exp, nbf và algorithm allowlist.
Token sender constraint mTLS/DPoP.
Client/TPP đang active và có role phù hợp.
Consent active, chưa hết hạn/thu hồi và thuộc đúng customer.
Scope/permission cho resource cụ thể.
Account ID nằm trong danh sách đã consent.
Data minimization và field-level authorization.
Không dùng account ID tuần tự lộ đoán và không tin account/customer ID do TPP gửi nếu token/consent không ràng buộc với nó.
Payment Initiation cần thêm kiểm soát
Payment là write operation có rủi ro cao hơn đọc dữ liệu:
Tạo payment consent/intent trước.
Ràng buộc amount, currency, creditor và purpose vào consent.
Strong Customer Authentication hoặc cơ chế xác thực theo quy định.
Idempotency key và unique constraint chống duplicate payment.
Transaction risk analysis, fraud engine và limit.
State machine: received -> authorised -> accepted -> settled/rejected.
Signed callback/webhook, polling và reconciliation.
Không đánh dấu settled chỉ từ browser redirect.
Nếu thay đổi amount hoặc người nhận sau khi khách đã consent, phải tạo consent mới hoặc re-authorize theo policy.
Message-level security
TLS bảo vệ đường truyền nhưng có thể kết thúc tại gateway/proxy. Một số ecosystem yêu cầu ký request/response để bảo vệ integrity và non-repudiation qua nhiều hop.
Nếu ký message:
Xác định chính xác canonicalization, covered headers và body digest.
Có kid, algorithm allowlist và key rotation.
Kiểm tra timestamp, nonce và replay.
Không tự phát minh format chữ ký; dùng profile đã chuẩn hóa.
Log hash/reference thay vì payload tài chính đầy đủ.
Encryption cấp message chỉ dùng khi threat model/regulation yêu cầu; nó làm key management và debugging phức tạp hơn.
Error handling không được tạo information leak
Không trả thông báo khác nhau khiến attacker phân biệt account thật/giả khi caller không có quyền.
Rate limit, retry và idempotency
Limit theo TPP, organization, client, PSU, endpoint và risk tier.
Cho burst hợp lý nhưng ngăn scraping và retry storm.
Dùng Retry-After, exponential backoff và jitter.
Payment retry phải dùng cùng idempotency key và payload.
GET có thể retry, nhưng vẫn cần timeout và budget.
Circuit breaker không được biến authorization failure thành success.
Có quota riêng cho sandbox và production.
Privacy và dữ liệu
Purpose limitation và data minimization ngay trong schema/response mapper.
Mask account identifiers nếu use case không cần full value.
Có retention khác nhau cho consent, audit, token metadata và business data.
Tách PII khỏi immutable security log khi có thể.
Không log access token, authorization code, client assertion hoặc raw financial payload.
Cho khách xem và thu hồi kết nối TPP.
Thiết kế quy trình data subject request phù hợp pháp luật áp dụng.
Observability và audit
Ghi nhận:
TPP/client/software ID và certificate thumbprint/key ID.
Consent ID, PSU pseudonymous reference và API operation.
Correlation ID, decision allow/deny và reason code.
Token/proof failure, PAR failure và replay detection.
Payment state transition và idempotent replay.
Theo dõi p95/p99 latency, availability, 4xx/5xx, token error, consent failure, certificate expiry, TPP revocation propagation, rate-limit rejection và fraud signal. Audit log phải tamper-evident và được phân quyền chặt.
Payment có SCA/risk control, idempotency và state machine.
OpenAPI contract chặt, versioned và có error/idempotency model.
Key/certificate rotation và revocation đã diễn tập.
Audit, privacy, rate limit, fraud monitoring và reconciliation hoạt động.
Đã chạy security/conformance test trước production.
Kết luận
Open Banking an toàn không đến từ một file OpenAPI hay một OAuth access token. Nó cần business contract rõ ràng, FAPI security profile, sender-constrained token, consent chi tiết, trust framework cho TPP, payment controls, audit và conformance testing.
Thiết kế tốt phải trả lời được bốn câu hỏi ở mọi request: TPP này là ai, được phép làm gì, khách hàng đã đồng ý điều gì, và bằng chứng mật mã nào ràng buộc request với đúng TPP?
Hướng dẫn tích hợp cổng thanh toán VNPay, ZaloPay, MoMo và Stripe: payment flow, chữ ký webhook/IPN, idempotency, retry, reconciliation, refund và vận hành production.
Hướng dẫn tích hợp VietQR và QR Code động với webhook/IPN từ ngân hàng hoặc cổng thanh toán: xác minh chữ ký, chống replay, matching giao dịch, idempotency và reconciliation.
Hướng dẫn xử lý transaction storm trong flash sale và quyết toán lương với RabbitMQ/Kafka, rate limiting, backpressure, circuit breaker, load shedding, idempotency và capacity planning.
