Tóm tắt: Token hợp lệ chỉ cho biết ai đang gọi. Nó không chứng minh người đó được phép thực hiện mọi thao tác.
Thuật ngữ chính: Authentication: xác minh danh tính; authorization: kiểm tra quyền; webhook: thông báo do hệ thống khác gửi tới API.
Bài toán
Khóa API dài hạn có thể bị lộ. Người dùng đã đăng nhập vẫn có thể đổi mã tài nguyên để truy cập dữ liệu khác. Webhook cũng có thể bị giả mạo hoặc phát lại nếu hệ thống chỉ tin vào nội dung nhận được.
Vì sao cách làm đơn giản chưa đủ
JWT library chỉ kiểm tra chữ ký khi được cấu hình đúng. Dịch vụ còn phải từ chối issuer, audience, algorithm không mong đợi và key đã cũ.
Horizontal object authorization thường bị bỏ sót: user được đọc một invoice nhưng đổi ID để tới invoice khác. Chính truy vấn cần mang authorized phạm vi.
Luồng xử lý
giới hạn size và abuse→Identity
issuer và audience→chính sách
khách hàng và object access→Audit
decision và vòng đời key
Quyết định kiến trúc
chính sách tập trung, enforcement tại chỗ
Chia sẻ chính sách definition và test. Tuy nhiên, enforcement ở dịch vụ sở hữu dữ liệu. Gateway không thể authorize field nó không hiểu.
Ưu tiên danh tính của tiến trình
Dùng machine credential ngắn hạn cấp cho khối lượng công việc thay vì chép secret vĩnh viễn vào môi trường.
Xem webhook là input không tin cậy
Verify signature trước khi parse, lưu delivery ID, giới hạn timestamp và xử lý tác động phụ idempotent.
Phân tích chuyên sâu
Authorization phải hiểu dữ liệu
Role name đơn thuần quá thô. Quyết định thường cần khách hàng membership, resource quyền sở hữu, record trạng thái và độ nhạy field.
Break-glass là một tính năng sản phẩm
Emergency access cần approval, ngày hết hạn, reason, phạm vi hẹp và audit bất biến. Admin bypass không tài liệu sẽ trở thành đường chính sách yếu nhất.
Các bước triển khai
- Validate issuer, audience, algorithm, ngày hết hạn và key status cho mọi token.
- Authorize đồng thời action, khách hàng và object tại server ranh giới.
- Ký webhook trên raw bytes kèm timestamp, replay protection và secret rotation.
Ví dụ kỹ thuật: Envelope kiểm tra webhook
signed = timestamp + '.' + rawBody
expected = HMAC(activeSecret, signed)
reject unless constantTimeEqual(signature, expected)
reject if abs(now - timestamp) > 5 minutes
reject if deliveryId already processedKhi rotate, chấp nhận current và next secret trong khoảng overlap ngắn, ghi nhận key nào verify. Không log secret hay raw nội dung dữ liệu nhạy cảm.
Các tình huống lỗi cần tính trước
- Gateway validate token nhưng internal dịch vụ lại tin identity header giả.
- Clock skew làm mọi webhook bị từ chối.
- Credential đã revoke vẫn được chấp nhận trong cache quá lâu.
Tín hiệu cần giám sát
| Tín hiệu | Ý nghĩa |
|---|---|
| Quyết định deny theo chính sách reason | Phát hiện tấn công, client lỗi và chính sách regression. |
| Tuổi credential và trạng thái rotation | Lộ ra quyền truy cập dài hạn hoặc không còn người phụ trách. |
| Lỗi signature và replay của webhook | Phân biệt lỗi tích hợp với abuse chủ động. |
Cách kiểm chứng thiết kế
- Chạy ma trận user, khách hàng, object và action gồm cả negative case.
- Rotate rồi revoke key trong khi lưu lượng vẫn chạy.
- Replay và sửa nội dung dữ liệu webhook có chữ ký, gồm delivery ID trùng.
Kế hoạch triển khai an toàn
Kiểm kê credential và authorization check trước. Thêm decision logging mà chưa đổi kết quả. Sau đó, chuyển từng nhóm API sang shared chính sách test. Rút ngắn credential lifetime từ từ và diễn tập emergency rotation trước khi enforcement toàn hệ thống.
Checklist trước khi đưa vào vận hành
- dịch vụ credential có tuổi ngắn và phạm vi cho đúng một khối lượng công việc.
- Key rotation hỗ trợ thời gian overlap và revoke ngay.
- Truy cập bị từ chối cùng thay đổi đặc quyền tạo audit sự kiện chống sửa đổi.
Kết luận
Bảo mật API là quá trình liên tục thu hẹp authority, không phải một cổng đăng nhập.