Authentication & Authorization Khi Test API (Token)

Khi mới chuyển sang test API có bảo mật, hầu hết học viên của tôi đều rối ở chỗ phân biệt hai khái niệm. Authentication api testing là việc kiểm thử cơ chế xác thực api — xác minh "bạn là ai" — và phân quyền — quyết định "bạn được làm gì". Hai thứ này khác nhau, và tester cần test cả hai một cách độc lập.

Trong bài này tôi sẽ đi từ khái niệm gốc, qua bảng các kiểu xác thực (API key, Bearer/JWT, OAuth 2.0), cách gửi token trong Postman, đến danh sách case bảo mật mà bạn buộc phải phủ — kèm bảng test case rõ ràng. Nếu bạn còn mới với API, hãy đọc qua API testing là gì trước cho chắc nền.

Authentication vs Authorization — phân biệt

Hai từ này nghe giống nhau nhưng trả lời hai câu hỏi hoàn toàn khác.

• Authentication (xác thực): "Bạn là ai?" — hệ thống xác minh danh tính, thường qua token, API key hoặc cặp username/password. Sai bước này, bạn còn chưa được hệ thống thừa nhận.
• Authorization (phân quyền): "Bạn được phép làm gì?" — sau khi đã biết bạn là ai, hệ thống quyết định bạn có quyền truy cập tài nguyên hay thao tác đó hay không.

Một cách nhớ nhanh tôi hay dùng: authentication là cái thẻ ra vào tòa nhà, còn authorization là việc thẻ đó có mở được cửa phòng server hay không. Bạn có thể vào tòa nhà (đã xác thực) nhưng vẫn bị chặn ở cửa phòng server (không đủ quyền).

Ranh giới này quan trọng vì nó quyết định mã lỗi bạn kỳ vọng khi test: thiếu/sai xác thực thường trả 401 Unauthorized, còn đã xác thực nhưng thiếu quyền thì trả 403 Forbidden. Lẫn lộn hai cái này là lỗi phổ biến nhất khi viết test case auth.

Các kiểu xác thực API (API key, Basic, Bearer/JWT, OAuth 2.0)

Một API có thể dùng nhiều cơ chế xác thực api khác nhau. Là tester, bạn không cần tự xây chúng, nhưng phải hiểu đủ để biết gửi gì và test gì. Bảng dưới tóm tắt các kiểu phổ biến nhất:

Trong đó, bearer token là kiểu bạn sẽ gặp nhiều nhất. "Bearer" nghĩa là "người mang" — ai cầm token hợp lệ thì được truy cập, nên token phải được bảo vệ kỹ. JWT (JSON Web Token) là một dạng bearer token đặc biệt: nó tự mang thông tin người dùng và quyền hạn được ký số, nên server đọc thẳng được mà không cần tra cứu lại.

Còn oauth là gì? OAuth 2.0 là một framework cấp quyền (authorization framework) cho phép một ứng dụng truy cập tài nguyên thay mặt người dùng mà không cần biết mật khẩu của họ — ví dụ "Đăng nhập bằng Google". Cuối luồng OAuth, ứng dụng nhận về một access token và dùng nó như một bearer token ở các request sau. Để tra cứu ý nghĩa các mã trả về trong những luồng này, bài HTTP status code là tài liệu nên để sẵn bên cạnh.

Cách gửi token trong request (Postman)

Sau khi nắm khái niệm, việc thực hành gửi token trong Postman khá nhẹ nhàng. Đây là phần lõi của một bài test api có token:

1. Lấy token: đăng nhập qua API (vd POST /auth/login) để nhận về token, hoặc dùng token mẫu mà dev cấp.
2. Mở tab Authorization của request: với Bearer/JWT, chọn type Bearer Token rồi dán token vào ô — Postman sẽ tự thêm header Authorization: Bearer <token>.
3. Hoặc thêm header thủ công: vào tab Headers, thêm key Authorization, value Bearer eyJ.... Với API key thì thêm header X-API-Key theo tài liệu API.
4. Dùng biến môi trường: lưu token vào biến như {{access_token}} thay vì dán cứng — vừa gọn vừa tránh lộ token khi chia sẻ collection.

Mẹo thực chiến: dùng tính năng test script của Postman để tự bắt token từ response đăng nhập và lưu vào biến môi trường, các request sau cứ thế dùng {{access_token}}. Cách dựng request từ đầu, tôi đã hướng dẫn chi tiết trong Postman test API. Nếu bạn còn lăn tăn endpoint/method là gì, xem lại API RESTful là gì.

Tester cần test gì về auth (401/403, token hết hạn, phân quyền)

Đây là phần dễ bị bỏ sót nhất. Nhiều người chỉ test "có token đúng thì gọi được" rồi dừng — đó mới là happy path. Một bộ test auth tử tế phải phủ cả các ca xấu (negative test). Bốn nhóm bắt buộc:

• Thiếu token: gọi endpoint cần xác thực mà không gửi Authorization → kỳ vọng 401 Unauthorized.
• Sai token: gửi token bịa, token sai chữ ký, hoặc token đã bị thu hồi → kỳ vọng 401.
• Token hết hạn: gửi token đã quá thời hạn (exp) → kỳ vọng 401, và thông báo lỗi nên gợi ý cần làm mới token.
• Đúng token nhưng sai quyền (phân quyền): user đã xác thực hợp lệ nhưng truy cập tài nguyên/thao tác ngoài quyền của mình → kỳ vọng 403 Forbidden.

Điểm cốt lõi cần khắc sâu là khác biệt 401 vs 403:

Nói gọn: 401 = "tôi không biết bạn là ai", còn 403 = "tôi biết bạn là ai, nhưng bạn không được phép". Ngoài ra đừng quên test phân quyền theo vai trò (role): một tài khoản nhân viên thường không được gọi API quản trị, và một user không được sửa dữ liệu của user khác (lỗi này gọi là IDOR — truy cập trái phép tài nguyên của người khác bằng cách đổi ID).

Ví dụ test case bảo mật auth

Để cụ thể, tôi lấy "hệ thống đặt phòng họp nội bộ" làm ví dụ. API GET /api/bookings/{id} cần Bearer token; còn DELETE /api/admin/rooms/{id} chỉ admin được gọi. Bảng test case bảo mật auth có thể trích dẫn được:

Lưu ý khi viết các case này: luôn kiểm tra cả mã trạng thái lẫn nội dung response — một số API trả 200 nhưng body lại là thông báo lỗi, hoặc rò rỉ dữ liệu nhạy cảm trong message lỗi. Đồng thời kiểm tra API không trả về thông tin thừa (token, mật khẩu băm) trong response. Đây chính là nhóm kỹ năng được luyện sâu trong khóa API Testing của IT LEARN.

Lưu ý về thuật ngữ: ISTQB không định nghĩa riêng "Bearer token" hay "OAuth" — đây là khái niệm kỹ thuật của HTTP/bảo mật. Nhưng kiểm thử authentication/authorization thuộc về security testing, một loại non-functional testing được ISTQB ghi nhận, thường thực hiện ở cấp integration và system test.