Lesson 6.1: JWT Standards

Thời lượng: 25 phút
Level: Intermediate
Yêu cầu: Kiến thức cơ bản về HTTP Headers.

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 Payload của JWT chứa thông tin cần thiết.
• Hiểu và triển khai được cơ chế Access Token & Refresh Token.
• Biết cách bảo mật khóa bí mật (Secret Key) và xử lý Token hết hạn.

Nội dung chính

1. JWT trong Design System

JWT là tiêu chuẩn vàng cho các hệ thống hiện đại vì nó Stateless (Server không cần lưu session trong RAM/Redis).

Cấu trúc Payload chuẩn: Đừng đưa quá nhiều thông tin nhạy cảm vào JWT (vì nó chỉ được encode, không phải mã hóa).

{
  "sub": "user_123",        // Subject - ID của user
  "role": "admin",          // Quyền hạn
  "iss": "my-ds-auth",      // Issuer - Ai cấp token này
  "iat": 1705300000,        // Issued At - Thời điểm cấp
  "exp": 1705303600         // Expiration - Thời điểm hết hạn
}

2. Cơ chế Access & Refresh Token

Một sai lầm phổ biến là cấp 1 token có thời hạn quá dài (VD: 1 năm). Nếu bị mất token này, hacker sẽ có quyền truy cập vĩnh viễn.

Giải pháp chuẩn:

• Access Token: Thời hạn ngắn (15 - 60 phút). Dùng để gọi API.
• Refresh Token: Thời hạn dài (7 - 30 ngày). Dùng để đổi lấy Access Token mới mà không bắt user login lại. Lưu trong Database/Redis để có thể Thu hồi (Revoke) khi cần.

3. Quy trình Refresh Token

1. Client gửi Access Token hết hạn lên server.
2. Server trả về lỗi 401 Unauthorized.
3. Client gửi Refresh Token lên endpoint /auth/refresh.
4. Server kiểm tra Refresh Token trong DB, nếu hợp lệ -> Trả về Access Token mới.

Nguyên tắc then chốt

"Đừng bao giờ lưu mật khẩu, số điện thoại hay thông tin cá nhân nhạy cảm trong JWT Payload."

Mọi người đều có thể giải mã JWT để xem nội dung bên trong. Chỉ lưu ID và các thông tin cần thiết để phân quyền (Role/Permissions).

Thực hành

Bài tập 1: Xây dựng JWT Payload cho User App

Bối cảnh: Bạn đang thiết kế token cho một ứng dụng đọc báo. User có các thuộc tính: id, email, role, subscription_plan, password_hash.

Yêu cầu:

• Hãy chọn các trường cần thiết đưa vào JWT.
• Giải thích tại sao bạn loại bỏ các trường còn lại.

Tình huống thực tế

Scenario 1: Logout trên mọi thiết bị

Bối cảnh: Người dùng bị mất điện thoại và muốn nhấn "Logout khỏi tất cả thiết bị". Vì JWT là Stateless, bạn không thể xóa nó khỏi máy hacker.

Giải quyết: Đây là lúc Refresh Token phát huy tác dụng:

1. Bạn xóa toàn bộ Refresh Tokens của user đó trong Database.
2. Khi Access Token trên máy hacker hết hạn (trong vòng 15 phút), nó sẽ cố gắng dùng Refresh Token để đổi cái mới nhưng sẽ bị từ chối.
3. User được bảo vệ sau tối đa 15-30 phút (tùy thời hạn Access Token).

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

Mid Level

1. Q: Phân biệt Xác thực (Authentication) và Phân quyền (Authorization)? A:
   • Xác thực (AuthN): Câu hỏi "Bạn là ai?". (Bằng chứng: Username/Password, JWT).
   • Phân quyền (AuthZ): Câu hỏi "Bạn có được phép làm việc này không?". (Bằng chứng: Role Admin, Permission Edit).

Tóm tắt

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

• Access Token ngắn hạn, Refresh Token dài hạn.
• Không lưu dữ liệu nhạy cảm trong Payload.
• Luôn kiểm tra thời hạn hết hạn (exp) ở phía Backend.

Key Takeaways

1. Security: Bảo mật khóa bí mật (Secret Key) là ưu tiên số 1. Dùng biến môi trường (ENV), không hardcode.
2. User Experience: Dùng Refresh Token để user không phải login lại quá thường xuyên.

Bước tiếp theo

Trong bài tiếp theo, bạn sẽ học về Lesson 6.2: RBAC vs ABAC - Cách thiết kế hệ thống phân quyền thông minh và dễ quản lý.

Tiếp tục bài 6.2 →