Mục lục

Lesson 6.3: API Key Management

Cách thiết kế và quản lý API Keys an toàn cho các ứng dụng bên thứ ba (Internal & External integration).

Security
API Key
Integration

Thời lượng: 20 phút
Level: Intermediate
Yêu cầu: Đã hiểu về Authentication và Authorization.

Mục tiêu bài học

Sau bài học này, bạn sẽ:

  • Thiết kế được cấu trúc API Key an toàn và khó bị đoán (unpredictable).
  • Hiểu quy trình cấp mới, xoay vòng (Rotation) và thu hồi API Key.
  • Phân biệt được API Key và Access Token.

Nội dung chính

1. API Key là gì?

Khác với JWT dùng cho người dùng (User Authentication), API Key thường dùng cho các hệ thống máy-với-máy (Machine-to-Machine - M2M).

  • Đặc trưng: Có thời hạn dài, không thay đổi thường xuyên.
  • Vị trí: Thường truyền qua Header X-API-KEY.

2. Cấu trúc API Key an toàn

Đừng dùng một chuỗi random đơn giản. Một API Key chuyên nghiệp nên có tiền tố để dễ dàng nhận biết và quản lý.

Ví dụ (Chuẩn Stripe/GitHub): sk_live_51Mpw9x... (Secret Key - Môi trường Live) pk_test_51Mpw9x... (Public Key - Môi trường Test)

  • Tiền tố (Prefix): Giúp bạn quét code trên GitHub để tìm các key bị lộ (Secret Scanning).
  • Phần ngẫu nhiên (Entropy): Dùng các thư viện crypto để tạo chuỗi có độ dài ít nhất 32 ký tự.

3. Quy trình quản lý (Lifecycle)

  1. Cấp phát: Lưu bản băm (Hash) của Key trong Database, không lưu bản rõ (giống như mật khẩu). Chỉ hiển thị cho user 1 lần duy nhất lúc tạo.
  2. Phạm vi (Scoping): Gán API Key cho một tập hợp quyền nhất định (Read-only, Write-only) và giới hạn bởi IP (IP Whitelisting).
  3. Xoay vòng (Rotation): Khuyến khích user đổi key định kỳ hoặc khi có nghi ngờ bị lộ.
  4. Vô hiệu hóa: Thu hồi key ngay lập tức khi phát hiện hành vi bất thường.

Nguyên tắc then chốt

"Treat API Keys like passwords."

Backend không được phép lưu API Key dưới dạng văn bản thuần túy (Plain text). Nếu database bị rò rỉ, hacker sẽ có toàn quyền truy cập vào các hệ thống đối tác của bạn. Sử dụng thuật toán băm (SHA-256) để lưu trữ.


Thực hành

Bài tập 1: Thiết kế Client Identifier

Bối cảnh: Bạn mở API cho một đối tác vận chuyển. Bạn cần cấp cho họ một cặp: Client IDAPI Key.

Yêu cầu:

  • Client ID có cần bảo mật không?
  • API Key nên được lưu trữ thế nào ở Database?
  • Thiết kế Header để đối tác gửi Key lên.
Xem đáp án mẫu
  • Client ID: Không cần bảo mật cao (giống Username). Dùng để định danh đối tác.
  • API Key: Phải bảo mật. Lưu ở DB dưới dạng Hashed String.
  • Header: Authorization: Bearer <API_KEY> hoặc X-API-KEY: <API_KEY>.

Tình huống thực tế

Scenario 1: Key bị lộ trên GitHub

Bối cảnh: Một developer của đối tác vô tình commit API Key bạn cấp vào repository public trên GitHub.

Giải quyết:

  1. Phát hiện: Tích hợp với các service như GitHub Secret Scanning để nhận thông báo ngay lập tức.
  2. Xử lý: Tự động vô hiệu hóa Key đó và gửi email thông báo cho đối tác yêu cầu tạo Key mới.
  3. Phòng ngừa: Luôn tư vấn đối tác sử dụng biến môi trường (Environment Variables) để lưu Key.

Câu hỏi phỏng vấn

Senior Level

  1. Q: Làm thế nào để implement "Rate Limiting" dựa trên API Key? A:
    • Sau khi xác thực API Key thành công, ta lấy được ClientID.
    • Sử dụng Redis với thuật toán Fixed Window hoặc Leaky Bucket để đếm số request của ClientID đó trong vòng 1 phút.
    • Nếu vượt quá giới hạn (VD: 100 req/min), trả về lỗi 429 Too Many Requests.

Tóm tắt

Những điều cần nhớ

  • API Key dành cho tích hợp hệ thống (M2M).
  • Không bao giờ lưu Plain-text API Key ở Database.
  • Sử dụng Prefix để dễ nhận diện và bảo mật.

Bước tiếp theo

🎉 Chúc mừng! Bạn đã hoàn thành Module 6: Authentication & Authorization.

Giờ bạn đã là chuyên gia bảo mật API với:

  • JWT chuẩn xác.
  • Mô hình phân quyền RBAC/ABAC linh hoạt.
  • Hệ thống quản lý API Key chuyên nghiệp.

Module tiếp theo: Module 7: Reliability & Performance - Học cách làm cho hệ thống chạy nhanh hơn và không bao giờ chết.

Bắt đầu Module 7 →

Quảng cáo
mdhorizontal