Open Banking 3 — Consent, OAuth2 & Bảo mật API

Vì sao consent là trái tim của Open Banking

Trong API & Chuẩn Open Banking ta đã thiết kế được những API đẹp, có versioning, idempotency, rate limit. Nhưng một câu hỏi lớn còn bỏ ngỏ: lấy quyền gì để một fintech xa lạ được đọc tài khoản của khách, hay khởi tạo lệnh chuyển tiền thay khách? Câu trả lời không nằm ở kỹ thuật thuần tuý mà ở một khái niệm nền tảng: consent — sự đồng ý có kiểm soát của chính chủ dữ liệu.

Consent là hành động khách hàng chủ động cấp cho một TPP (Third Party Provider — bên thứ ba) quyền truy cập một tập dữ liệu xác định, hoặc quyền khởi tạo một loại giao dịch xác định, trong một phạm vi (scope) và thời hạn rõ ràng. Consent không phải là "bật một công tắc cho tất cả": nó là một hợp đồng ba bên nhỏ giữa khách — ngân hàng — TPP, ghi rõ ai được xem gì, làm gì, đến bao giờ.

Vì sao consent là trái tim? Ba lý do:

• Nền tảng pháp lý: ở châu Âu, PSD2 quy định TPP chỉ được truy cập dữ liệu khi có "explicit consent". Ở Việt Nam và các nước khác, khung tương tự đang hình thành. Không có consent hợp lệ, mọi việc truy cập đều là truy cập trái phép — ngân hàng chịu trách nhiệm.
• Nền tảng niềm tin: khách chỉ dám dùng Open Banking khi biết mình kiểm soát được — nhìn thấy đã cấp quyền cho ai, và thu hồi được bất cứ lúc nào. Consent minh bạch là điều kiện để hệ sinh thái (xem Open Banking tổng quan) phát triển.
• Nền tảng kỹ thuật: consent được mã hoá thành scope trong OAuth2 và thành consentId trong API. Mọi lời gọi API sau này đều được kiểm tra ngược lại consent gốc.

Vòng đời của một consent

Consent không phải trạng thái tĩnh mà có vòng đời:

1. Cấp (grant): khách được TPP dẫn tới ngân hàng, xem rõ TPP xin quyền gì, và bấm đồng ý tại giao diện ngân hàng.
2. Hiệu lực (active): ngân hàng lưu consent với consentId, danh sách scope, thời hạn hết hạn (expiry). Mỗi lần TPP gọi API, ngân hàng đối chiếu.
3. Xem (dashboard): khách vào consent dashboard trên app/web ngân hàng, thấy toàn bộ TPP đang có quyền, quyền gì, còn hạn bao lâu.
4. Thu hồi (revoke): khách bấm thu hồi bất cứ lúc nào; ngân hàng vô hiệu consent và các token phái sinh ngay lập tức.
5. Hết hạn (expired): đến hạn, consent tự vô hiệu; muốn tiếp tục, khách phải cấp lại (re-consent).

Granular scope — cấp quyền chi tiết

Điểm tinh tế: consent phải granular (chi tiết, tối thiểu cần thiết) chứ không "tất cả hoặc không gì cả". Một app quản lý chi tiêu chỉ cần đọc lịch sử giao dịch thì không được xin luôn quyền khởi tạo thanh toán. Nguyên tắc least privilege (đặc quyền tối thiểu — xem Kiểm soát truy cập & mã hoá) áp dụng trực tiếp: scope càng hẹp, rủi ro khi lộ token càng nhỏ.

Bảng ví dụ các scope điển hình (minh hoạ theo phong cách OBIE — Open Banking Implementation Entity):

OAuth2 và OIDC — cỗ máy uỷ quyền

Consent là khái niệm nghiệp vụ; OAuth2 (Open Authorization 2.0) là giao thức kỹ thuật để hiện thực nó. OAuth2 giải quyết đúng một bài toán: cho phép một ứng dụng (TPP) truy cập tài nguyên của khách trên hệ thống khác (ngân hàng) mà không cần biết mật khẩu của khách. OIDC (OpenID Connect) là lớp định danh xây trên OAuth2, cho phép ngân hàng khẳng định "đây đúng là khách A" qua một id_token.

Authorization Code Flow

Trong nhiều "flow" của OAuth2, Open Banking gần như luôn dùng authorization code flow vì nó an toàn nhất cho ứng dụng có backend. Các vai trò:

• Resource Owner: khách hàng (chủ tài khoản).
• Client: TPP (ứng dụng fintech).
• Authorization Server: máy chủ uỷ quyền của ngân hàng (nơi khách đăng nhập & đồng ý).
• Resource Server: các API dữ liệu/thanh toán của ngân hàng.

Ba loại token quan trọng:

• Authorization code: một mã tạm, dùng-một-lần, ngắn hạn (thường vài chục giây), TPP nhận qua redirect rồi đổi lấy token. Nó không phải access token — kẻ chặn được code vẫn không dùng trực tiếp được nếu thiếu client secret / PKCE.
• Access token: "chìa khoá" ngắn hạn (ví dụ 5–10 phút) để gọi API. Gắn kèm scope. Hết hạn nhanh để giảm thiệt hại khi lộ.
• Refresh token: dài hạn hơn, dùng để xin access token mới mà không bắt khách đăng nhập lại — nhưng chỉ hợp lệ khi consent còn hiệu lực.

Redirect-based flow — khách xác thực TẠI ngân hàng

Đây là điểm cốt tử phân biệt Open Banking chuẩn với cách làm cũ. Trong redirect-based flow, khi cần cấp quyền, TPP chuyển hướng (redirect) trình duyệt của khách sang trang đăng nhập của ngân hàng. Khách nhập tài khoản/mật khẩu và xác thực trực tiếp trên hệ thống ngân hàng — TPP không bao giờ nhìn thấy thông tin đăng nhập. Sau khi khách đồng ý, ngân hàng redirect ngược lại TPP kèm authorization code.

Hãy so sánh với screen scraping — cách làm cũ và nguy hiểm mà Open Banking sinh ra để xoá bỏ:

Screen scraping nguy hiểm vì khách phải giao toàn bộ thông tin đăng nhập cho bên thứ ba, TPP lưu mật khẩu (mục tiêu tấn công béo bở), và không có cách giới hạn phạm vi hay thu hồi ngoài việc đổi mật khẩu. OAuth2 redirect xoá sạch các rủi ro này.

FAPI — hồ sơ bảo mật cấp tài chính

OAuth2 "trần" đủ cho đăng nhập mạng xã hội, nhưng chưa đủ chặt cho tiền bạc. FAPI (Financial-grade API) là một hồ sơ bảo mật (security profile) do OpenID Foundation ban hành: nó siết OAuth2/OIDC bằng cách bắt buộc các biện pháp mạnh và cấm các lựa chọn yếu. Nói cách khác, FAPI = OAuth2 + một danh sách yêu cầu khắt khe. Ở mức khái niệm, những yêu cầu cốt lõi gồm:

• PKCE (Proof Key for Code Exchange): TPP tạo một bí mật ngẫu nhiên (code_verifier), gửi bản băm của nó (code_challenge) khi xin authorization code, và chứng minh lại code_verifier khi đổi lấy token. Điều này chống tấn công chặn authorization code — kẻ trộm được code cũng vô dụng vì thiếu verifier.
• mTLS (mutual TLS — TLS hai chiều): không chỉ client kiểm chứng server, mà server cũng đòi client trình chứng thư số (certificate). Chỉ TPP đã đăng ký, có chứng thư hợp lệ mới bắt tay được.
• Request object ký JWT: tham số của yêu cầu authorize không truyền trần trên URL mà đóng gói trong một JWT (JSON Web Token) có chữ ký số của TPP. Ngân hàng xác minh chữ ký, đảm bảo tham số không bị sửa dọc đường (chống tampering).
• Sender-constrained token (token ràng buộc người gửi): access token bị "khoá" vào chứng thư mTLS của đúng TPP đã nhận nó. Nếu token bị đánh cắp và dùng từ máy khác (chứng thư khác), ngân hàng từ chối. Đây là bước tiến lớn so với "bearer token" — loại token mà "ai cầm cũng dùng được".

FAPI có nhiều cấp (baseline và advanced); Open Banking cho thanh toán thường yêu cầu cấp cao hơn với mTLS + sender-constrained token bắt buộc.

Strong Customer Authentication (SCA)

SCA (Strong Customer Authentication — xác thực khách hàng mạnh) là yêu cầu xác thực đa yếu tố cho các hành động nhạy cảm: truy cập tài khoản trực tuyến, khởi tạo thanh toán điện tử. Nguyên tắc: khách phải chứng minh danh tính bằng ít nhất hai trong ba yếu tố độc lập:

• Knowledge (điều bạn biết): mật khẩu, PIN.
• Possession (điều bạn có): điện thoại đã đăng ký, thẻ, token cứng, khoá phần cứng.
• Inherence (điều bạn là): vân tay, khuôn mặt, giọng nói.

"Độc lập" nghĩa là lộ một yếu tố không kéo theo lộ yếu tố kia. SCA thường được thực thi ngay tại bước redirect trong OAuth2: khi khách sang trang ngân hàng để đồng ý consent, ngân hàng đồng thời bắt khách vượt qua SCA (ví dụ mật khẩu + mã OTP đẩy qua app). Chi tiết về đa yếu tố, mã hoá và quản trị khoá xem Kiểm soát truy cập & mã hoá. PSD2 còn cho phép một số miễn trừ SCA (SCA exemption) cho giao dịch giá trị nhỏ hoặc người nhận tin cậy, để cân bằng bảo mật và trải nghiệm.

Bảo mật kênh và chống lạm dụng

Consent + OAuth2 + FAPI lo phần uỷ quyền. Nhưng đường truyền và bản thân API vẫn cần các lớp phòng thủ riêng:

• mTLS ở tầng kết nối: mọi lời gọi từ TPP tới API đi qua kênh TLS hai chiều, chứng thư TPP được kiểm ở mỗi kết nối — vừa mã hoá vừa định danh.
• Chữ ký thông điệp (message signing): với thanh toán, phần thân request (số tiền, người nhận) được TPP ký số. Ngân hàng xác minh chữ ký để đảm bảo toàn vẹn (không ai sửa số tiền dọc đường) và chống chối bỏ (non-repudiation — TPP không thể phủ nhận đã gửi lệnh).
• Chống replay (phát lại): kẻ tấn công có thể bắt một request hợp lệ rồi gửi lại nhiều lần. Phòng chống bằng nonce (số dùng-một-lần), timestamp (dấu thời gian, từ chối request quá cũ), và idempotency key (đã bàn ở API & Chuẩn) — key trùng thì trả kết quả cũ thay vì thực thi lại.
• API gateway: đứng trước core banking, gánh việc kiểm token, mTLS, rate limit, logging tập trung, và cách ly core khỏi Internet.
• Rate limit & chống lạm dụng: giới hạn tần suất theo TPP/scope, phát hiện hành vi bất thường (một TPP đột nhiên quét hàng loạt tài khoản), gắn cảnh báo gian lận.

Đăng ký & định danh TPP

Trước khi được gọi API dòng nào, TPP phải đăng ký (client registration): được cơ quan quản lý cấp phép, đăng ký với ngân hàng (hoặc qua một directory chung của hệ sinh thái), nhận client ID và chứng thư số. Chứng thư này (ví dụ eIDAS QWAC/QSEAL ở EU) vừa dùng cho mTLS vừa dùng ký thông điệp, gắn chặt danh tính pháp lý của TPP vào từng kết nối. Khi TPP vi phạm hoặc mất phép, cơ quan quản lý thu hồi (revoke) chứng thư — mọi ngân hàng lập tức từ chối TPP đó.

Cân bằng bảo mật và trải nghiệm

Siết bảo mật quá thì khách bỏ cuộc giữa chừng (SCA rườm rà, redirect lỗi trên mobile), lỏng quá thì lộ token, consent giả mạo, phishing. Vài rủi ro trọng yếu và cách chặn:

• Lộ access token: giảm thiệt hại bằng token ngắn hạn + sender-constrained (đánh cắp cũng khó dùng) + scope hẹp.
• Consent giả mạo: kẻ xấu lừa khách đồng ý một quyền rộng hơn thực cần. Chặn bằng màn hình consent rõ ràng, đúng scope tối thiểu, và consent dashboard để khách rà soát.
• Phishing: kẻ xấu dựng trang "ngân hàng" giả để hứng mật khẩu. Đây chính là lý do redirect phải tới đúng miền ngân hàng (khách được dạy kiểm URL), và vì sao TPP tuyệt đối không được nhúng form đăng nhập ngân hàng bên trong app của mình.

Luồng OAuth2 authorization code (sequence)

Sơ đồ dưới minh hoạ luồng đầy đủ: khách ↔ TPP ↔ ngân hàng, từ authorize → consent → token → gọi API.

Ví dụ access token & scope (MINH HOẠ, không phải dữ liệu thật) — payload một JWT access token có thể trông như:

{
  "iss": "https://auth.ncb.com.vn",
  "sub": "cust-8842190",
  "client_id": "tpp-moneylover-01",
  "scope": "accounts balances transactions",
  "consent_id": "urn:ncb:consent:6f3a9c",
  "cnf": { "x5t#S256": "…thumbprint chứng thư mTLS…" },
  "exp": 1770000000,
  "iat": 1769999400
}

Trường scope giới hạn TPP chỉ đọc, consent_id trỏ về consent gốc để kiểm ngược, cnf ràng buộc token vào chứng thư mTLS (sender-constrained), exp - iat = 600 giây (10 phút) là tuổi thọ token.

Use case thực tế

Bối cảnh NCB. Một app fintech quản lý chi tiêu cá nhân (gọi là "MoneyLover", TPP đã được cấp phép) muốn giúp khách NCB tự động phân loại chi tiêu bằng cách đọc lịch sử giao dịch. Đây là kịch bản AIS thuần đọc — không đụng tới thanh toán.

Luồng triển khai:

1. Đăng ký TPP (một lần): MoneyLover đăng ký với NCB, nhận client_id = tpp-moneylover-01 và chứng thư mTLS. NCB ghi vào directory nội bộ.
2. Khách khởi tạo trong app MoneyLover, bấm "Kết nối tài khoản NCB".
3. Redirect sang NCB: app mở trình duyệt tới auth.ncb.com.vn với scope xin là accounts balances transactions (KHÔNG có payments), kèm PKCE challenge.
4. SCA tại NCB: khách đăng nhập NCB (mật khẩu) + xác nhận OTP đẩy qua app NCB — hai yếu tố.
5. Màn hình consent NCB hiển thị rõ: "MoneyLover xin quyền: Xem danh sách tài khoản, Xem số dư, Xem giao dịch. Thời hạn: 90 ngày. Không được chuyển tiền." Khách bấm Đồng ý.
6. Token giới hạn: NCB phát access token (10 phút) + refresh token gắn consent_id, expiry consent = 90 ngày. MoneyLover chỉ đọc, không thể khởi tạo lệnh.
7. Gọi API: mỗi ngày MoneyLover làm mới access token bằng refresh token, gọi GET /transactions qua mTLS. NCB kiểm scope + consent còn hạn ở từng lời gọi.
8. Thu hồi: sang tháng thứ 2 khách đổi ý, vào consent dashboard trong app NCB, thấy "MoneyLover — còn 47 ngày", bấm Thu hồi. NCB vô hiệu consent; lần làm mới token kế tiếp của MoneyLover bị từ chối 403. Không cần đổi mật khẩu.

Số liệu tiêu biểu (minh hoạ): consent hạn 90 ngày; access token 10 phút; refresh token gắn consent; scope đúng 3 quyền đọc; hết 90 ngày khách phải re-consent nếu muốn tiếp tục. So với screen scraping, khách không bao giờ đưa mật khẩu NCB cho MoneyLover, và NCB kiểm soát được chính xác TPP nào đọc gì. Đội quản trị NCB còn theo dõi các chỉ số như tỉ lệ hoàn tất cấp consent, số consent active theo TPP, tỉ lệ thu hồi — nối với Chỉ số & KPI và quyền riêng tư dữ liệu ở Chia sẻ dữ liệu & quyền riêng tư.

Ghi nhớ

• Consent là trái tim: khách cấp quyền cho TPP trong scope và thời hạn xác định — vừa là nền tảng pháp lý, vừa là niềm tin. Vòng đời: cấp → active → xem (dashboard) → thu hồi → hết hạn.
• Granular scope + least privilege: chỉ xin đúng quyền cần (đọc khác ghi), scope hẹp thì rủi ro lộ token nhỏ.
• OAuth2 authorization code + redirect-based flow: khách xác thực tại ngân hàng, TPP không bao giờ thấy mật khẩu. Đây là điểm xoá bỏ screen scraping — cách cũ buộc giao toàn bộ mật khẩu cho bên thứ ba.
• Ba token: authorization code (dùng-một-lần, ngắn), access token (ngắn hạn, gắn scope), refresh token (dài hơn, chỉ hợp lệ khi consent còn hiệu lực).
• FAPI siết OAuth2 cho tài chính: PKCE, mTLS, request object ký JWT, sender-constrained token.
• SCA: xác thực đa yếu tố (2 trong 3: knowledge / possession / inherence), thường thực thi ngay ở bước redirect.
• Bảo mật kênh: mTLS (chứng thư TPP), chữ ký thông điệp (toàn vẹn + chống chối bỏ), chống replay (nonce/timestamp/idempotency), API gateway, rate limit.
• Đăng ký & thu hồi TPP: client registration + chứng thư số gắn danh tính pháp lý; vi phạm thì bị revoke.
• Luôn cân bằng bảo mật vs trải nghiệm; rủi ro chính: lộ token, consent giả mạo, phishing — chặn bằng token ngắn hạn, màn hình consent rõ ràng, redirect đúng miền ngân hàng.

Nguồn tham khảo

• RFC 6749 — The OAuth 2.0 Authorization Framework (IETF)
• RFC 7636 — Proof Key for Code Exchange by OAuth Public Clients (PKCE) (IETF)
• RFC 8705 — OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (IETF)
• OpenID Connect Core 1.0 (OpenID Foundation)
• FAPI 2.0 Security Profile — Financial-grade API (OpenID Foundation)
• Commission Delegated Regulation (EU) 2018/389 — Regulatory Technical Standards on Strong Customer Authentication (PSD2 SCA RTS)
• Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân (Chính phủ Việt Nam)