Nơi đặt khóa API: tiêu đề HTTP tùy chỉnh VS tiêu đề ủy quyền với sơ đồ tùy chỉnh

Tôi đang thiết kế API REST bằng ủy quyền / xác thực thông qua Khóa API.

Tôi đã cố gắng tìm ra đâu là nơi tốt nhất cho nó và phát hiện ra rằng nhiều người đề xuất sử dụng tiêu đề HTTP tùy chỉnh ProjectName-Api-Key, ví dụ:

ProjectName-Api-Key: abcde

nhưng cũng có thể và chính xác về mặt ý thức hệ để sử dụng Authorizationtiêu đề với sơ đồ tùy chỉnh, ví dụ:

Authorization: ApiKey abcde

Mặt khác, tôi nhận thấy rằng một lược đồ ủy quyền tùy chỉnh có thể bị một số khách hàng bất ngờ và không được hỗ trợ và dẫn đến mã tùy chỉnh, vì vậy tốt hơn là sử dụng tiêu đề tùy chỉnh vì khách hàng không có bất kỳ mong đợi nào về nó.

Bạn muốn gửi API API theo cách nào?

— La Mã
nguồn

Các dự án theo hướng dẫn của tôi sử dụng Authorization: Bearer <token>tiêu đề và không bao giờ có một vấn đề duy nhất với điều đó. Các mã thông báo là JWT s.

— Andy

@DavidPacker Theo tôi hiểu, Bearerlược đồ được sử dụng riêng với oAuth2. Áp dụng nó riêng biệt từ oAuth nghe có vẻ như lạm dụng nó. Tại sao nó chính xác để sử dụng lược đồ này nếu không có oAuth? Nhân tiện, tôi gặp rắc rối với việc chọn loại ủy quyền cho API của mình. API sẽ chỉ khả dụng cho một dịch vụ đáng tin cậy, vì vậy tôi đã điều tra luồng thông tin xác thực ứng dụng khách của oAuth2 và không tìm thấy bất kỳ lợi ích nào so với ApiKey trong trường hợp của tôi.

— RomanG

@DavidPacker Sau đó, tôi hiểu rằng ủy quyền ApiKey có thể được coi là một triển khai oAuth hợp lệ nếu ApiKeyđược đổi tên và được hiểu là Access Tokencấp cho khách hàng mà không có thời gian hết hạn. Đó là một khía cạnh triết học, tôi quyết định không đưa ra các định nghĩa phức tạp nếu trường hợp của tôi có thể được mô tả bằng các thuật ngữ đơn giản và quyết định chỉ gọi nó là "ApiKey". Nếu giao thức của bạn thực hiện tiêu chuẩn oAuth, tôi có thể đồng ý sử dụng Bearer, nhưng không, tôi đoán sơ đồ này không thể được áp dụng.

— RomanG

Bạn đang giới hạn bản thân quá nhiều. Người tiêu dùng API không quan tâm đến việc bạn có triển khai OAuth hay không. Điều họ quan tâm là sự an toàn của mã thông báo, việc phát hành mã thông báo đó và họ có thể được xác thực đúng cách. Họ khuyên nên sử dụng Bearer ngay trong tài liệu JWT . JWT phù hợp hoàn toàn với lược đồ Bearer và tôi không thể đề xuất JWT nhiều hơn. Chúng hoàn hảo cho các ứng dụng REST vì bạn có thể xác thực người dùng ngay cả khi không nhấn cơ sở dữ liệu - trừ khi bạn cần tính năng thu hồi mã thông báo.

— Andy

(lái xe) ... vui lòng lưu ý rằng các khóa api là các bí mật được chia sẻ thường được chia sẻ giữa một bên dựa trên cấu hình và trình xác thực, không để truyền đạt danh tính hoặc ủy quyền. Nói cách khác, họ chỉ có ý định bắt đầu một cái bắt tay bảo mật, không đại diện cho một kết quả xác thực. Khóa api truyền đạt thẩm quyền của bạn để xác định chính bạn chống lại trình xác thực đáng tin cậy của hệ thống. Sử dụng khóa làm mã thông báo để kiểm soát truy cập tài nguyên an toàn là juju xấu

— K. Alan Bates

Nếu bạn sử dụng Ủy quyền, hãy nhất quán

Một số người sẽ cho rằng những điều sau đây là không cần thiết ( và cách đây không lâu tôi đã đồng ý với họ ) nhưng, ngày nay, nếu chúng ta sử dụng Authorizationtiêu đề, chúng ta nên thông báo loại mã thông báo, vì các khóa API không tự mô tả ¹ .

Tại sao tôi nghĩ nó cần thiết và tại sao tôi nghĩ nó quan trọng? Bởi vì ngày nay việc hỗ trợ các giao thức xác thực / ủy quyền khác nhau đã trở thành bắt buộc. Nếu chúng tôi dự định sử dụng Authorizationtiêu đề cho tất cả các giao thức này, chúng tôi phải làm cho dịch vụ xác thực của chúng tôi nhất quán. Cách thức giao tiếp loại mã thông báo chúng tôi gửi và giao thức ủy quyền nào sẽ được áp dụng cũng nên đi trong tiêu đề.

Authorization: Basic xxxx
Authorization: Digest xxxx
Authorization: Bearer xxxx
Authorization: ApiKey-v1 xxxx
Authorization: ApiKey-v2 xxxx

Tôi đã từng không quan tâm đến vấn đề này, nhưng sau khi làm việc với các ứng dụng khách ứng dụng có cập nhật không được bảo đảm (chủ yếu là điện thoại di động và cảm biến), tôi bắt đầu. Tôi bắt đầu thận trọng hơn trong cách tôi thực hiện bảo mật để tôi có thể mở rộng nó mà không gây rối cho khách hàng và không phải chịu quá nhiều đau đớn từ phía máy chủ.

Mối quan tâm

Các vấn đề tôi gặp phải khi thực hiện các kế hoạch của riêng tôi tương tự như đã nhận xét.

Mặt khác, tôi thấy một sự cân nhắc rằng một lược đồ ủy quyền tùy chỉnh có thể bị bất ngờ và không được hỗ trợ bởi một số khách hàng và dù sao cũng dẫn đến mã tùy chỉnh

Nói khách hàng , nói thư viện, khung, proxy ngược .

Ưu điểm

Một lợi thế quan trọng là bộ nhớ cache. Bộ nhớ cache được chia sẻ sẽ không lưu bộ đệm tiêu đề (tất nhiên là tốt) trừ khi bạn nói khác.

Vì vậy, ủy quyền hoặc tiêu đề tùy chỉnh?

Theo kinh nghiệm của tôi, việc thực hiện Authorizationlược đồ của riêng tôi đã mang lại cho tôi khối lượng công việc tương đương (hoặc nhiều hơn) so với việc thực hiện các tiêu đề ủy quyền tùy chỉnh, với một chút khác biệt là có nhiều tự do thiết kế hơn và kiểm soát nhiều hơn bộ đệm khi tôi sử dụng các tiêu đề tùy chỉnh. Lý do khá ngu ngốc, hầu hết thời gian tôi đã Cache-controlcài đặt no-cachehoặc no-store, cho phép tôi thực hiện các cuộc gọi đến máy chủ mang tính quyết định hơn (điều này rất quan trọng khi theo dõi và kiểm tra) bất kể cấu trúc liên kết của mạng.

^{1: Tôi thấy câu trả lời này rất rõ ràng về Khóa API}

— Laiv
nguồn

Việc sử dụng X-bị từ

— chối vào

ops Tôi không biết. Chỉnh sửa và sửa lỗi.

— Laiv

Trước câu hỏi này, tôi nghĩ rằng hầu hết mọi người đều đặt khóa API trong URL, nhưng đã sử dụng HTTPS để ẩn nó. Tốt để xem một số lựa chọn thay thế. Ví dụ: Contentful cho phép ủy quyền hoặc truy vấn pamameter: contentful.com/developers/docs/references/content-delivery-api/ Kẻ

— user949300

@ user949300 ... sử dụng một bí mật được chia sẻ được mã hóa (ví dụ: khóa api trong uri qua ssl) rõ ràng an toàn hơn không có gì, nhưng rất dễ bị giả mạo nếu nó bị chặn và không cung cấp mức độ chi tiết về nhận dạng. Tôi chưa bao giờ sử dụng api_keys cho bất cứ điều gì khác ngoài giao tiếp giữa máy với máy, nơi tôi khớp với bí mật chung giữa các bên tin cậy và danh tính máy được liệt kê trong danh sách được ủy quyền để thực hiện với bí mật chung đó. Sau khi máy kết nối máy được thực hiện, người vận hành xác thực bằng các phương tiện khác.

— K. Alan Bates

@K. Alan Bates Hầu hết các tương tác API của tôi là dành cho những thứ tương đối "không quan trọng" như mã hóa địa lý miễn phí, báo cáo thời tiết và tương tự, trong đó khóa API dành cho giới hạn tốc độ hơn là bí mật người dùng nghiêm trọng. Vì vậy, đối với OP, phụ thuộc vào mức độ bảo mật là cần thiết.

— dùng949300