# 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â…

- **URL canonical**: https://itlearn.edu.vn/blog/test-api-authentication
- **Published**: 2026-07-06T11:00:00+07:00
- **Modified**: 2026-07-06T12:10:00+07:00
- **Author**: Anh Tuấn
- **Category**: API Testing (https://itlearn.edu.vn/blog/cat/api-testing)
- **Reading time**: 10 phút
- **Source site**: IT LEARN — Học viện Software Testing tiếng Việt

---

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.

![authentication api testing - tester gửi token Bearer trong Postman và kiểm tra phản hồi 401 với 403](/uploads/2026/07/test-api-authentication.jpg)

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ì](/blog/api-testing-la-gi) 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:

Kiểu xác thực

Gửi ở đâu trong request

Đặc điểm

Khi test cần lưu ý

API key

Header (vd `X-API-Key`) hoặc query param

Đơn giản, một chuỗi cố định định danh ứng dụng

Dễ lộ nếu để trong URL; test thiếu/sai key

Basic Auth

Header `Authorization: Basic <base64>`

Mã hóa base64 username:password (không phải mã hóa an toàn)

Chỉ an toàn khi đi qua HTTPS; test sai mật khẩu

Bearer / JWT

Header `Authorization: Bearer <token>`

Token có hạn dùng, JWT mang sẵn thông tin & quyền

Test token hết hạn, token sai chữ ký, sai quyền

OAuth 2.0

`Authorization: Bearer <access_token>`

Quy trình cấp quyền nhiều bước, có access & refresh token

Test luồng lấy token, scope (phạm vi quyền), refresh

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](/blog/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*:

- **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.

- **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>`.

- **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.

- **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](/blog/postman-test-api). Nếu bạn còn lăn tăn endpoint/method là gì, xem lại [API RESTful là gì](/blog/api-restful-la-gi).

## 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**:

Tình huống

Đã xác thực?

Đủ quyền?

Mã kỳ vọng

Thiếu / sai / hết hạn token

Không

—

401 Unauthorized

Token hợp lệ, không đủ quyền

Có

Không

403 Forbidden

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:

TC

Mô tả

Token gửi

Kết quả mong đợi

TC01

Lấy booking khi không gửi token

(không có)

401 Unauthorized

TC02

Lấy booking với token sai chữ ký

Bearer token bịa

401 Unauthorized

TC03

Lấy booking với token đã hết hạn

Bearer token `exp` quá khứ

401 Unauthorized

TC04

Lấy booking với token hợp lệ

Bearer token đúng

200 OK + đúng dữ liệu

TC05

Nhân viên gọi API xóa phòng (admin)

Bearer token của nhân viên

403 Forbidden

TC06

User A xem booking của user B

Bearer token của user A

403 Forbidden (chặn IDOR)

TC07

Admin xóa phòng

Bearer token của admin

200 OK / 204 No Content

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](/api.html) 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.

## Câu hỏi thường gặp

### Authentication và authorization khác gì?

Authentication (xác thực) trả lời câu hỏi "bạn là ai" — hệ thống xác minh danh tính qua token, API key hay mật khẩu. Authorization (phân quyền) trả lời "bạn được làm gì" — quyết định bạn có quyền truy cập tài nguyên đó không. Thiếu xác thực trả 401, đủ xác thực nhưng thiếu quyền trả 403.

### Bearer token là gì?

Bearer token là một chuỗi xác thực gửi trong header `Authorization: Bearer <token>`. "Bearer" nghĩa là người mang — ai cầm token hợp lệ thì được truy cập, nên cần bảo vệ kỹ. JWT là một dạng bearer token phổ biến, tự mang thông tin người dùng và quyền hạn đã được ký số để server đọc thẳng.

### OAuth 2.0 là gì?

OAuth 2.0 là một framework cấp quyền cho phép ứ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, ứng dụng nhận một access token và dùng nó như bearer token ở các request sau. Khi test, bạn kiểm tra luồng lấy token, scope quyền và refresh token.

### Test token hết hạn thế nào?

Bạn gửi request với một token đã quá thời hạn (trường `exp` nằm trong quá khứ) đến endpoint cần xác thực, rồi kiểm tra API trả về 401 Unauthorized chứ không phải 200. Nên xác minh thêm rằng thông báo lỗi rõ ràng, gợi ý cần làm mới token, và API không vô tình chấp nhận token cũ.

### 401 vs 403 khi test auth?

401 Unauthorized nghĩa là "tôi không biết bạn là ai" — xảy ra khi thiếu token, token sai hoặc token hết hạn. 403 Forbidden nghĩa là "tôi biết bạn là ai nhưng bạn không được phép" — xảy ra khi token hợp lệ nhưng tài khoản không đủ quyền. Phân biệt đúng hai mã này là chìa khóa khi viết test case phân quyền. Muốn luyện kiểm thử bảo mật API bài bản với Postman trên dự án thật, bạn có thể tham khảo [khóa API Testing](/api.html) của IT LEARN. Để chắc nền, hãy đọc thêm [API testing là gì](/blog/api-testing-la-gi) và [HTTP status code](/blog/http-status-code).