Video học lập trình mỗi ngày

Bearer token là gì? Đây là một câu hỏi rất hay, ngay bản thân tôi cũng không hiểu tại sao tôi lại cắm đầu vào code mà không hiểu vì sao người ta lại quy định Bearer trước token trong việc Authorization trên header.

Bài viết này cung cấp cho bạn được những gì?

• Hiểu được Bearer token là gì? 
• Tại sao lại có Bearer trước token? 
• Nếu không khai báo Bearer thì chuyện gì xảy ra với Authorization?

Ok, bây giờ chúng ta rõ mục tiêu rồi, ngay bây giờ vào giải bài toán này luôn.

Bearer token là gì?

Bearer token hay gọi là Bearer authentication chính là token authentication. Là một HTTP authentication scheme liên quan đến các token bảo mật thì nó gọi là bearer tokens. Theo HTTP authentication. Đến đây ngay cả bản thân mình cũng éo hiểu được tại sao lại định nghĩa như vậy. Theo các tài liệu thì Bearer có thể hiểu là "cấp quyền truy cập cho người mang mã thông báo này". 

"Bearer token" là một chuỗi nhìn vào đố ai mà hiểu, nó được tạo ra bởi server cộng với một vài định nghĩa của mỗi công ty. Khách hàng muốn truy cập vào tài nguyên của chính họ thì phải luôn mang theo token này. Điều này đã được nói ở những số trước rồi, chằng hạn như token là gì? Hay vì sao login github cần phải lấy được token? Anh em vào xem tiếp.

Tại sao Bearer trước token?

Cú pháp Authorization:  quay lại lịch sử một chút thì cú pháp này được giới thiệu ở W3C in HTTP 1.0 và cũng chính từ đó mà được tái sử dụng nhiều nơi. Do nhiều nơi cắm đầu sử dụng cho nên anh em ta bây giờ phải đau đầu là do vậy, chứ chẳng quan trọng gì cả? Đó là tôi đoán thôi. Nhưng thực tế thì có những trường hợp mình khai báo mỗi token thôi thì không đủ. Phải thật đầy đủ mới được.

Authorization : Bearer cn389ncoiwuencr

Chính là do mấy cụ tổ đi trước định nghĩa như vậy thì anh em ta sau này sao mà làm sai được, việc này làm tôi liên tưởng đến việc check null mà ra Object trong bài viết 44 câu hỏi phỏng vấn nhanh trong javascript thật là vãi đạn.

Nếu không khai báo Bearer thì chuyện gì xảy ra với Authorization?

Tiếp theo và cũng là phần giải đáp cuối cho bài viết này. Liệu team back end bảo không cần "bearer" đâu, vậy có đúng hay không? Đúng, không sao cả, bởi như giải thích ở trên thì việc sử dụng "bearer" đó là một quy ước lâu đời. Chính vì đó là quy ước thì không thể làm chuẩn hết được. Điều đó giúp chúng ta cũng có một quy ước mà thôi. Ví dụ bên tôi thì tôi quy ước là Basic hay đại loại là JWT. Như ví dụ dưới đây:

let [scheme, token] = req.headers.authorization.split(' ') 
// now depending on the scheme value, treat token differently. 
 
switch(scheme) { 
	case 'Bearer': 
		// check token is valid, (means are out of the scope of the question) 
		// example header "Bearer RUq7nTFjPl" 
		break; 
	case 'Basic' 
		// check that username and password are valid 
		// example header "Basic someusername:somepassword"  
	  break; 
    case 'JWT': 
		// check that presented token is valid JWT intended for this server 
	    break; 
	default: 
		res.status(403) 
		return res.end('Unsupported authorization scheme') 
} 

Đây là một ví dụ có thể chưa được tối ưu cho lắm, nhưng cũng đủ giúp cho các bạn trả lại được câu hỏi như trên.

Tóm lại

Như tôi đã nói "Authorizing" là một khái niệm, quy trình rất quan trọng. Nó liên quan tới bảo mật hệ thống, phát hiện lỗ hổng ngay từ đầu và từ đâu. Anh em nào yêu thích và thích tìm tòi thêm nữa thì có thể qua những bài viết về token, refresh token... Cảm ơn đã đọc!!