Bảo MậtỞ đây không có user, nên không dùng authorization code. Hai lựa chọn phổ biến:
Client credentials grant — service tự lấy token bằng chính danh tính của nó.
POST /token
grant_type=client_credentials&client_id=svc-order&client_secret=...&scope=inventory:writeToken nhận được là access token của service, không mang sub là user. Ưu điểm: dùng chung hạ tầng OAuth sẵn có, scope kiểm soát được service nào gọi được gì, token ngắn hạn nên rò rỉ ít hại. Nhược: phải quản lý và xoay client_secret.
mTLS — hai bên cùng xuất trình chứng chỉ khi bắt tay TLS. Danh tính nằm ở tầng vận chuyển, không có secret nào đi trong request. Ưu điểm: mạnh hơn, chống replay tốt hơn, không lộ qua log. Nhược: cần hạ tầng PKI (cấp phát, xoay, thu hồi chứng chỉ) — thường được service mesh (Istio, Linkerd) lo giúp.
Thực tế hay kết hợp: mTLS cho lớp mạng (ai được nói chuyện với ai) + token cho lớp ứng dụng (được làm gì, và chuyển tiếp ngữ cảnh user).
Một điểm hay bị hỏi thêm: khi service A gọi service B thay mặt user, đừng để B tự tin tưởng header X-User-Id do A gửi — bên trong mạng nội bộ header đó giả được. Hoặc chuyển tiếp chính token của user, hoặc dùng token exchange để đổi lấy token mới có ngữ cảnh user.