Bearer token là gì? Cách sử dụng, rủi ro và quy tắc tốt nhất

Scrapeless Scraping API sử dụng khóa API tài khoản trong tiêu đề x-api-token thay vì xác thực Bearer OAuth, minh họa rằng loại thông tin xác thực và sơ đồ trình bày HTTP là các lựa chọn thiết kế tách biệt.

Bearer token là gì?

Bearer token là một mã thông báo bảo mật mà quyền lực của nó dựa trên quyền sở hữu. Từ “bearer” có nghĩa là bên mang mã thông báo có thể trình bày nó cho một tài nguyên được bảo vệ. Không giống như một thiết kế chứng minh quyền sở hữu, một luồng bearer cơ bản không yêu cầu người gọi phải chứng minh quyền kiểm soát một khóa mật mã riêng cho mỗi yêu cầu.

RFC 6750 định nghĩa việc sử dụng bearer token OAuth 2.0. Nó mô tả cách mà các khách hàng gửi mã thông báo truy cập đến các máy chủ tài nguyên, cách mà các máy chủ trả lại thách thức xác thực và lỗi, và các mối đe dọa bảo mật mà các triển khai phải giải quyết.

Bearer tokens rất phổ biến trong HTTP APIs vì tương tác giữa khách hàng rất đơn giản. Máy chủ xác thực phát hành một mã thông báo truy cập, khách hàng lưu trữ nó, và khách hàng gửi nó cùng với các yêu cầu API. Sự đơn giản chuyển trách nhiệm sang bảo mật vận chuyển, xử lý mã thông báo, xác thực, thiết kế phạm vi và phản ứng sự cố.

Cách hoạt động của tiêu đề Authorization

Trình bày HTTP ưa thích sử dụng Authorization tiêu đề yêu cầu với Bearer sơ đồ:

Authorization: Bearer REDACTED

Tên sơ đồ không phân biệt chữ hoa chữ thường dưới phân tích xác thực HTTP, nhưng khách hàng nên sử dụng cách viết hoa thông thường. Giá trị mã thông báo không rõ ràng với khách hàng trừ khi hồ sơ mã thông báo rõ ràng cung cấp cho khách hàng lý do để kiểm tra nó. Khách hàng không nên đưa ra quyết định xác thực bằng cách giải mã nội dung mã thông báo truy cập; máy chủ tài nguyên là điểm thực thi.

Yêu cầu phải sử dụng HTTPS, và khách hàng phải xác thực chứng chỉ của máy chủ theo mô hình tin cậy của nền tảng của nó. Tiêu đề vẫn có thể rò rỉ qua nhật ký ứng dụng, tác nhân truy dấu, proxies gỡ lỗi, báo cáo sự cố, hoặc tiện ích mở rộng trình duyệt, vì vậy mọi tầng mà quan sát yêu cầu cần có quy tắc xóa.

Bearer Token, Access Token, và OAuth

Mã thông báo truy cập là một thông tin xác thực đại diện cho quyền được truy cập một tài nguyên. Bearer mô tả cách mà mã thông báo đó được sử dụng. OAuth là khung mà qua đó một khách hàng có thể nhận được một mã thông báo truy cập dưới một hạn mức. Những thuật ngữ này liên quan nhưng không thể thay thế cho nhau.

Mã thông báo truy cập OAuth thường là mã thông báo bearer, nhưng một hồ sơ khác có thể gắn một mã thông báo với một khóa do khách hàng nắm giữ. Một hệ thống không phải OAuth cũng có thể phát minh ra một mã thông báo kiểu bearer, mặc dù việc sử dụng sơ đồ tiêu chuẩn mà không tuân theo bảo mật và ngữ nghĩa lỗi liên quan tạo ra sự nhầm lẫn.

Một mã thông báo ủy quyền không phải là mã thông báo truy cập bearer cho API tài nguyên. Nó là một thông tin xác thực trung gian ngắn hạn được trao đổi tại điểm cuối mã thông báo của máy chủ ủy quyền. Một mã thông báo làm mới cũng không được gửi đến các máy chủ tài nguyên thông thường; nó được sử dụng với máy chủ ủy quyền để tiếp tục một khoản cấp hiện tại.

Bearer Token vs API Key vs JWT

Một JWT có thể là một token cấp phép, nhưng không phải mọi JWT đều là một token truy cập và không phải mọi token cấp phép đều là một JWT. Một JWT đã ký chứng minh rằng một nhà phát hành được chấp thuận đã bảo vệ các yêu cầu khỏi việc bị thay đổi; nó không chứng minh rằng người trình bày là người nắm giữ được chỉ định trừ khi hồ sơ thêm ràng buộc người gửi.

Token Cấp phép Không rõ và Tự chứa

Token Không rõ

Một token không rõ là một giá trị không thể đoán trước mà ý nghĩa của nó được giữ bởi hạ tầng ủy quyền. Máy chủ tài nguyên có thể gọi một điểm cuối introspection, sử dụng một kho lưu trữ token chia sẻ, hoặc dựa vào một cổng thông tin giải quyết token. Tìm kiếm trung tâm có thể phản ánh việc thu hồi và thay đổi chính sách một cách nhanh chóng, nhưng nó làm gia tăng khả năng sẵn có, độ trễ và các quyết định về bộ nhớ cache.

Token Tự chứa

Một token tự chứa mang theo các yêu cầu mà máy chủ tài nguyên có thể xác thực cục bộ. JWT là một đại diện phổ biến. Máy chủ xác minh chữ ký hoặc mã xác thực tin nhắn theo một hồ sơ nghiêm ngặt và sau đó kiểm tra nhà phát hành, đối tượng, thời gian, loại token, phạm vi và bất kỳ yêu cầu xác nhận nào cần thiết.

RFC 8725 cung cấp các thực hành tốt nhất về bảo mật JWT hiện tại.Nó cảnh báo chống lại sự nhầm lẫn thuật toán, xác thực yếu, nhầm lẫn cross-JWT, và niềm tin mù quáng vào các yêu cầu nhận được. Một máy chủ tài nguyên phải cấu hình các thuật toán được phép và hồ sơ token kỳ vọng thay vì chấp nhận bất cứ điều gì mà tiêu đề token yêu cầu.

Những gì một Máy chủ Tài nguyên Phải Xác thực

• Toàn vẹn token hoặc trạng thái hoạt động. Xác thực chữ ký theo một thuật toán được phép hoặc giải quyết token không rõ thông qua hệ thống ủy quyền đáng tin cậy.
• Nhà phát hành. Chỉ chấp nhận token từ máy chủ ủy quyền được cấu hình cho tài nguyên này.
• Đối tượng. Xác nhận token đã được phát hành cho API hoặc bộ tài nguyên này.
• Thời gian sống. Thực thi hết hạn và bất kỳ điều kiện không trước nào với một độ chênh lệch đồng hồ tài liệu nhỏ.
• Hồ sơ và loại token. Ngăn chặn một token ID, mã ủy quyền, hoặc token từ một ngữ cảnh giao thức khác được chấp nhận như một token truy cập API.
• Phạm vi hoặc yêu cầu ủy quyền. Xác nhận token cho phép hoạt động được yêu cầu.
• Chính sách cấp độ tài nguyên. Kiểm tra người thuê, quyền sở hữu, vai trò, trạng thái đối tượng và các quy tắc miền khác ngay cả khi token có phạm vi rộng.

Một chữ ký hợp lệ chỉ là một kiểm tra. Nó chứng minh rằng token đã được bảo vệ bởi một khóa đáng tin cậy theo thuật toán đã chấp nhận. Nó không chứng minh rằng token nhằm vào API này, đang hiện tại, có quyền lực cần thiết, hoặc có thể truy cập vào bản ghi cụ thể này.

Rủi ro Bảo mật Token Cấp phép

Rủi ro chính là việc tiết lộ token. Một token cấp phép bị sao chép có thể được sử dụng cho đến khi nó hết hạn, bị thu hồi hoặc bị từ chối bởi một chính sách kiểm soát khác. Việc tiếp xúc có thể xảy ra thông qua các URL, nhật ký ứng dụng, ảnh chụp màn hình hỗ trợ, bộ nhớ trình duyệt, tiêu đề referrer, lưu trữ proxy, điều khiển nguồn hoặc thiết bị khách đã bị xâm phạm.

Các URL đặc biệt nguy hiểm. Chuỗi truy vấn xuất hiện trong nhật ký truy cập máy chủ web, lịch sử trình duyệt, hệ thống phân tích, và các liên kết sao chép. RFC 6750 định nghĩa một phương pháp thân thể mã hóa hình thức dưới các điều kiện hẹp và tài liệu việc sử dụng truy vấn URI để tương thích, nhưng các khách hàng mới nên sử dụng tiêu đề ủy quyền.

Kịch bản cross-site có thể tiết lộ các token có thể truy cập trình duyệt. Giữ một token cấp phép sống lâu trong bộ nhớ địa phương làm cho nó có sẵn cho kịch bản độc hại thực thi trong cùng một nguồn. Kiến trúc trình duyệt nên giảm thiểu việc tiết lộ token cho JavaScript, sử dụng thời gian sống truy cập ngắn, thực thi một chính sách bảo mật nội dung mạnh, và xem xét một mẫu backend-for-frontend khi thích hợp.

Lưu trữ Token theo Loại Khách hàng

Một dịch vụ backend lưu trữ token trong bộ nhớ phía máy chủ hoặc một kho credential bảo vệ đã được phê duyệt và giới hạn quyền truy cập đối với danh tính công việc cần đến chúng. Token không nên được ghi vào bộ nhớ cache đĩa, xuất môi trường, hoặc nhật ký chung mà không có lý do đã được xem xét và mô hình bảo vệ.

Một ứng dụng đã cài đặt sử dụng bộ nhớ an toàn của hệ điều hành khi có sẵn. Một khách hàng trình duyệt có môi trường lộ hơn và nên giữ cho thời gian sống của token và quyền truy cập kịch bản nhỏ nhất có thể. Một cookie phiên không tự động an toàn hơn; thiết kế cookie cần Kiểm soát Bảo mật, HttpOnly, SameSite, kiểm soát giả mạo yêu cầu cross-site, và chính sách phiên phía máy chủ.

Không có lựa chọn lưu trữ nào sửa chữa một token quá mạnh. Giữ cho phạm vi hẹp, đối tượng cụ thể, thời gian sống ngắn, và tài nguyên được bảo vệ bởi ủy quyền phía máy chủ.

Các lựa chọn Giới hạn Người gửi

Một token giới hạn người gửi yêu cầu người trình bày chứng minh quyền sở hữu một khóa riêng biệt, giảm giá trị của một chuỗi token bị đánh cắp. Chứng minh Bằng chứng Quyền sở hữu, hoặc DPoP, ràng buộc các token OAuth với một khóa ứng dụng thông qua các chứng minh đã ký đính kèm vào các yêu cầu.

RFC 9449 định nghĩa DPoP của OAuth.TLS tương hỗ là một cách tiếp cận giới hạn người gửi khác cho các môi trường khách hàng bảo mật thích hợp. Những thiết kế này thêm yêu cầu tạo khóa, lưu trữ, phát hiện tái phát, và yêu cầu tương tác, vì vậy chúng nên được chọn dưới một mô hình mối đe dọa rõ ràng.

Hết hạn, Thu hồi và Kiểm tra

Các token truy cập có thời gian sống ngắn hạn chế thời gian mà một token được tiết lộ còn hữu ích. Khách hàng có thể nhận được truy cập mới thông qua một phiên được ủy quyền hoặc quy trình token làm mới. Credential làm mới xứng đáng được bảo vệ mạnh mẽ hơn vì nó có thể mở rộng quyền truy cập vượt ra ngoài thời gian sống của một token truy cập.

Token không rõ có thể phản ánh việc thu hồi thông qua kiểm tra hoặc tìm kiếm trung tâm. Các token tự chứa thường được chấp nhận cho đến khi hết hạn trừ khi máy chủ tài nguyên kiểm tra trạng thái thu hồi hoặc phiên. Thiết kế đúng cân bằng các thay đổi chính sách ngay lập tức, độ trễ, tính khả dụng, bộ nhớ cache và rủi ro.

Ý nghĩa đăng xuất phải được xác định. Kết thúc một phiên khách hàng cục bộ, thu hồi một token làm mới, thu hồi một token truy cập, và kết thúc một phiên máy chủ ủy quyền là các hoạt động khác nhau. Giao diện người dùng nên mô tả những gì nó thực sự vô hiệu hóa.

Các Tình huống Sử dụng Token Cấp phép Thông thường

Danh sách Kiểm Tra Mã Thông Báo Bearer

1. Chỉ gửi mã thông báo qua HTTPS. Xác thực máy chủ dự kiến và giữ mã thông báo ra khỏi URL.
2. Sử dụng tiêu đề Authorization. Theo sơ đồ tài liệu hóa của API và không phát minh ra vị trí thay thế.
3. Phát hành quyền hạn hạn hẹp. Giới hạn khán giả, phạm vi, thời gian sống, chủ thuê và quyền truy cập vào tài nguyên.
4. Xác thực hồ sơ mã thông báo đầy đủ. Chữ ký đơn giản không đủ.
5. Xóa trước khi xuất khẩu khả năng quan sát. Che chắn tiêu đề, dấu vết, ngoại lệ, bản sao yêu cầu và công cụ hỗ trợ.
6. Bảo vệ lưu trữ cho loại khách hàng. Các khách hàng công khai và bảo mật có khả năng khác nhau.
7. Lập kế hoạch thu hồi và phản ứng sự cố. Biết mã thông báo, cấp phép và phiên nào có thể bị vô hiệu hóa và nhanh chóng các máy chủ tài nguyên quan sát thay đổi.

Kết luận

Mã thông báo bearer rất mạnh mẽ vì nó làm cho các cuộc gọi API được ủy quyền trở nên đơn giản: trình bày mã thông báo và máy chủ tài nguyên đánh giá quyền hạn của nó. Tính chất giống nhau làm cho việc tiết lộ trở nên nghiêm trọng. Hệ thống mã thông báo bearer an toàn sử dụng TLS, tiêu đề Authorization, xác thực hồ sơ mã thông báo nghiêm ngặt, khán giả và phạm vi hạn chế, thời gian sống ngắn, lưu trữ được bảo vệ, xóa quyết liệt và kiểm soát thu hồi. Khi rủi ro trộm cắp yêu cầu đảm bảo mạnh mẽ hơn, mã thông báo bị hạn chế người gửi thêm bằng chứng liên quan đến một khóa do khách hàng nắm giữ.