[Playwright Typescript] Bài 23 - Nền tảng giao thức API

🔐 Phần 1: AUTHENTICATION, AUTHORIZATION VÀ CƠ CHẾ JWT

PHÂN BIỆT AUTHENTICATION VS. AUTHORIZATION

Hai thuật ngữ này hay đi cùng nhau và viết tắt cũng na ná nhau (AuthN và AuthZ), nên rất dễ nhầm. Hãy dùng ví dụ "Đi Máy Bay" để giải thích.

1. Authentication (Xác thực) - "Bạn là ai?" 🆔

• Định nghĩa: Là quá trình xác minh danh tính của người dùng.

• Ví dụ: Khi bạn đến sân bay, bạn đưa Hộ chiếu/CCCD cho nhân viên an ninh. Nhân viên nhìn ảnh, nhìn mặt bạn và xác nhận: "Ok, đúng là ông Nguyễn Văn A".

• Trong phần mềm: Là lúc bạn nhập Username + Password. Hệ thống kiểm tra trong Database xem có khớp không.

• Kết quả: Nếu đúng -> Hệ thống cấp cho bạn một cái "Thẻ bài" (Session ID hoặc Token).

2. Authorization (Phân quyền) - "Bạn được làm gì?" 👮

• Định nghĩa: Là quá trình kiểm tra xem người dùng (đã được xác thực) có quyền truy cập vào tài nguyên cụ thể nào đó không.

• Ví dụ: Sau khi qua cửa an ninh (Authentication), bạn cầm vé máy bay đi ra cửa lên tàu bay.

  • Vé hạng Thương gia (Admin): Được vào phòng chờ VIP, được đi lối ưu tiên.

  • Vé hạng Phổ thông (User): Chỉ được ngồi ghế thường, không được vào phòng VIP.

• Trong phần mềm: Bạn click vào trang /admin/dashboard. Hệ thống kiểm tra: "Ông A này có role là Admin không? Có thì cho vào, không thì chặn lại".

• Lỗi đặc trưng:

  • Sai Authentication -> Trả về 401 Unauthorized (Chưa đăng nhập).

  • Sai Authorization -> Trả về 403 Forbidden (Đã đăng nhập nhưng không đủ tuổi/không đủ quyền).

 TẠI SAO LẠI CẦN JWT (JSON WEB TOKEN)?

Trước khi có JWT, thế giới dùng Session-based Authentication.

Vấn đề của cách cũ (Session)

1. Client: Login xong, Server tạo ra 1 SessionID, lưu vào bộ nhớ (RAM/Database) của Server.

2. Server: Gửi SessionID về cho Client (dưới dạng Cookie).

3. Vấn đề:

   • Tốn RAM: Nếu có 1 triệu user online, Server phải lưu 1 triệu cái session trong RAM.

   • Khó mở rộng (Scaling): Nếu bạn có 3 con Server (A, B, C). User login vào Server A (lưu session ở A). Request sau User bị điều hướng sang Server B -> Server B không thấy session đâu -> Bắt login lại. (Rất phiền).

Giải pháp JWT (Stateless - Không lưu trạng thái)

JWT ra đời với tư duy: "Server không cần nhớ gì cả. Hãy đưa toàn bộ thông tin cho Client tự cầm. Server chỉ cần ký tên đóng dấu là được."

 CẤU TRÚC GIẢI PHẪU CỦA JWT

Một chuỗi JWT nhìn như một đống ký tự lằng nhằng, nhưng thực ra nó gồm 3 phần, ngăn cách nhau bởi dấu chấm .:

AAAAAA.BBBBBB.CCCCCC

1. Header (AAAAAA)

Chứa thông tin về thuật toán mã hóa.

{
  "alg": "HS256", // Thuật toán ký
  "typ": "JWT"
}

2. Payload ( BBBBBB) - QUAN TRỌNG NHẤT

Chứa dữ liệu (Claims) mà Server muốn gửi gắm. Đây là nơi chứa thông tin User.

{
  "sub": "1234567890",  // User ID
  "name": "Anh Tester", // Tên
  "role": "admin",      // Quyền (Dùng để Authorization)
  "iat": 1516239022,    // Thời điểm tạo (Issued At)
  "exp": 1516242622     // Thời điểm hết hạn (Expiry)
}

⚠️ Lưu ý  Payload này chỉ được Mã hóa Base64 (dạng encode ai cũng dịch ngược được), KHÔNG ĐƯỢC MẬT MÃ HÓA.

👉 Tuyệt đối không để Password hay thông tin thẻ tín dụng vào đây, vì ai nhặt được Token cũng có thể đọc được nội dung này (dùng trang jwt.io để soi).

3. Signature ( CCCCCC) - Chữ ký bảo mật

Đây là phần đảm bảo tính toàn vẹn. Server sẽ tạo ra chữ ký bằng công thức:

Sign = Hash(Header + Payload + SecretKey)

• SecretKey: Là cái chìa khóa bí mật chỉ nằm trên Server. Không ai biết.

• Cơ chế bảo vệ: Nếu Hacker cố tình sửa Payload (ví dụ sửa role: "user" thành role: "admin"), thì khi Server tính toán lại Hash, nó sẽ ra một chuỗi Signature khác hẳn với cái Signature đang có -> Server biết ngay là Token giả mạo -> Từ chối (Reject).

LUỒNG HOẠT ĐỘNG (THE FLOW) 

Đây là luồng đi mà Tester cần nắm rõ để viết test case.

1. Login: Client gửi User/Pass lên Server.

2. Verify & Sign: Server check đúng Pass -> Lấy thông tin User -> Tạo JWT -> Ký tên bằng SecretKey.

3. Response: Server trả JWT về cho Client.

4. Store: Client nhận JWT, lưu vào LocalStorage (phổ biến) hoặc Cookie.

5. Request: Client muốn lấy dữ liệu, gửi Request kèm theo Header:

   Authorization: Bearer <token_jwt_cua_toi>

6. Verify: Server nhận request -> Lấy Token ra -> Dùng SecretKey để verify chữ ký.

   • Nếu chữ ký đúng và exp chưa hết hạn -> Cho phép truy cập (lấy role trong payload để phân quyền).

   • Nếu chữ ký sai hoặc hết hạn -> Trả về 401.

KIẾN THỨC MỞ RỘNG 

1. Tại sao token hết hạn (Expired)?

Trong payload có trường exp. Đây là cơ chế bảo mật. Nếu hacker trộm được token, hắn chỉ dùng được trong 1 khoảng thời gian ngắn (vd: 15 phút). Hết giờ token tự hủy.

-> Test case: Login -> Chờ quá thời gian token -> Gọi API -> Expect 401.

2. Refresh Token là gì?

Vì Access Token (cái JWT ở trên) thường sống rất ngắn (15-30p). Chẳng lẽ cứ 30p bắt user login lại?

-> Server sẽ cấp thêm 1 cái Refresh Token (sống lâu hơn, vd: 7 ngày). Khi Access Token hết hạn, Client âm thầm dùng Refresh Token để xin cấp Access Token mới mà User không hề hay biết.

3. Lưu JWT ở đâu an toàn nhất?

• LocalStorage: Dễ làm (JS đọc ghi thoải mái). Dễ bị dính lỗi XSS (Hacker chạy script lấy trộm token). -> Dùng cho các khóa học cơ bản/Project nhỏ.

HttpOnly Cookie: Khó làm hơn. JS không đọc được (chống XSS). An toàn hơn. -> Dùng cho Production/Ngân hàng

const id = 1;
const role = 'admin';
// Dễ thiếu dấu ? hoặc &
await request.get('/users/' + id + '?role=' + role + '&active=true');

const userId = 123;
// Gọn gàng, dễ đọc
const response = await request.get(`/users/${userId}`);

test('Get Users với bộ lọc', async ({ request }) => {
  const response = await request.get('/users', {
    // 👇 Playwright sẽ tự biến cái này thành: /users?role=admin&page=1&sort=desc
    params: {
      role: 'admin',
      page: 1,
      sort: 'desc'
    }
  });

  expect(response.ok()).toBeTruthy();
});

POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

------WebKitFormBoundary7MA4YWxkTrZu0gW  <-- Vách ngăn 1
Content-Disposition: form-data; name="username"

Nguyen Van A  <-- Dữ liệu Text
------WebKitFormBoundary7MA4YWxkTrZu0gW  <-- Vách ngăn 2
Content-Disposition: form-data; name="avatar"; filename="anh.png"
Content-Type: image/png

(Dữ liệu nhị phân của tấm ảnh nằm ở đây...)
------WebKitFormBoundary7MA4YWxkTrZu0gW-- <-- Vách ngăn kết thúc