Nếu bạn từng làm việc với các API có xác thực, chắc hẳn bạn đã quen với dòng này trong request:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Nhiều lập trình viên mới thường đặt câu hỏi:

Tại sao lại phải thêm chữ “Bearer” trước token?

Sao không gửi thẳng token đi cho nhanh?

Bài viết này sẽ giúp bạn hiểu rõ ý nghĩa thực sự của từ khóa “Bearer” và lý do nó tồn tại.

1. Cấu trúc chuẩn của header Authorization

Trong đó:

  • <type>: là phương thức hoặc “schema” xác thực, ví dụ Basic, Bearer, Digest, hoặc bất kỳ loại tùy chỉnh nào.

  • <credentials>: là phần thông tin xác thực thật sự, có thể là token, mã hóa base64 hoặc chuỗi chữ ký số.

Như vậy, Bearer chính là tên schema xác thực, không phải là một phần của token.

2. Nguồn gốc của “Bearer”

“Bearer” được định nghĩa trong chuẩn OAuth 2.0 Authorization Framework (RFC 6750).

Chuẩn này mô tả cách client gửi token đến server để truy cập tài nguyên được bảo vệ.

Cụ thể, OAuth yêu cầu client gửi token theo cú pháp:

Authorization: Bearer <access_token>

Trong ngữ cảnh này, “Bearer” có nghĩa là người mang chứng nhận.

Nói cách khác, bất kỳ ai “mang” token này đều có quyền truy cập tài nguyên, mà không cần thêm xác minh danh tính nào khác.

Đây là lý do nó được gọi là Bearer Token.

3. Tại sao không gửi token trần?

Giả sử bạn gửi như sau:

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Server sẽ không biết bạn đang dùng kiểu xác thực nào.

Token này có thể là JWT, Basic Auth, hay một loại mã hóa riêng mà hệ thống bạn tự định nghĩa.

Nhờ có prefix Bearer, server có thể phân biệt rõ ràng phương thức xác thực và chọn cách xử lý tương ứng.

Điều này đặc biệt quan trọng khi một API hỗ trợ nhiều phương thức xác thực khác nhau.

4. Các loại Authorization phổ biến

Ngoài Bearer, còn có một số loại khác cũng tuân theo chuẩn RFC:

Schema

Ví dụ header

Mô tả

Basic

Authorization: Basic dXNlcjpwYXNz

Xác thực bằng username/password mã hóa base64

Bearer

Authorization: Bearer <token>

Dùng cho OAuth 2.0 access token

Digest

Authorization: Digest username="...", response="..."

Cơ chế xác thực theo hash challenge

ApiKey (custom)

Authorization: ApiKey <key>

Dạng xác thực tuỳ chỉnh, thường do backend tự định nghĩa

5. Ví dụ thực tế trong API

Một request hợp lệ khi dùng JWT hoặc OAuth token sẽ trông như sau:

GET /api/user HTTP/1.1
Authorization: Bearer eyJhbGciOi...

Khi đó, server chỉ cần đọc phần header, tách ra:

  • Schema: Bearer

  • Token: eyJhbGciOi...

và xử lý xác thực theo chuẩn OAuth.

Nếu bạn bỏ chữ “Bearer” đi, server sẽ không thể xác định cách parse token và sẽ trả về lỗi:

HTTP/1.1 400 Bad Request
WWW-Authenticate: Bearer realm="example"

6. Tổng kết

Từ khóa “Bearer” không phải là chi tiết thừa.

Nó là phần quan trọng trong chuẩn xác thực của HTTP và OAuth 2.0, giúp máy chủ:

  • Xác định loại xác thực đang được sử dụng.

  • Áp dụng quy trình kiểm tra token đúng cách.

  • Giữ tính tương thích giữa các hệ thống API khác nhau.

Nói cách khác, Bearer không chỉ là một từ khóa, mà là “ngữ pháp” của bảo mật trong giao thức HTTP.

Nó giúp thế giới API vận hành thống nhất và an toàn hơn.