Thiết kế API với mã thông báo truy cập, làm thế nào để xử lý các yêu cầu GET?

Tôi đang xây dựng một API sẽ sử dụng mã thông báo truy cập để tôi có thể theo dõi việc sử dụng giữa các bộ phận khác nhau và để kiểm soát truy cập. Kế hoạch của tôi là sử dụng các động từ HTTP một cách thích hợp - GETsẽ lấy thông tin, POSTsẽ thêm, DELETEsẽ xóa, v.v.

Câu hỏi của tôi là, tôi nên xử lý mã thông báo truy cập như thế nào trên các cuộc gọi GET?

Tùy chọn một:

Là để cung cấp mã thông báo truy cập như một phần của chuỗi truy vấn : /api/users/?token=ACCESSTOKEN. Vấn đề tôi gặp phải là ACCESSTOKEN xuất hiện trong nhật ký máy chủ. Phương pháp này cũng sẽ khác với các yêu cầu POST hoặc DELETE có mã thông báo được truyền qua cơ thể.

Tùy chọn hai:

Cung cấp phần thân cho yêu cầu (như bạn thực hiện trong POSTyêu cầu) và một trong các tham số là mã thông báo. Vấn đề của tôi ở đây là các nhà phát triển khác trong công ty của tôi đang nói với tôi đây không phải là "yêu cầu NHẬN đúng" vì tôi đang truyền dữ liệu. Các url họ gọi đơn giản là trông như thế này /api/users/và họ cung cấp token=ACCESSTOKENtrong cơ thể.

Tùy chọn ba:

Thả sử dụng GETvà buộc mọi thứ phải là a POST. Tôi không thích ý tưởng này vì đối với nhiều cuộc gọi API này, tôi không tạo tài nguyên mới. Tôi chỉ đơn giản là trả lại dữ liệu tình cờ ngồi sau một API yêu cầu ủy quyền.

Có một lựa chọn mà tôi đang thiếu hoặc nên tinh chỉnh? Tôi thích tùy chọn 2, nhưng nhạy cảm với mối quan tâm của các nhà phát triển bộ phận khác.

Tùy chọn 4: Tiêu đề ủy quyền và RFC 6750 (Mã thông báo mang)

Giải pháp bạn đang tìm kiếm đã được chỉ định là một phần của tiêu chuẩn OAuth2, nhưng nó tự đứng vững và sẽ hữu ích trong kịch bản của bạn.

https://tools.ietf.org/html/rfc6750

Tất cả các yêu cầu từ máy khách sẽ chuyển qua mã thông báo mang (mã thông báo truy cập của bạn) và nó trông giống như bất kỳ tiêu đề yêu cầu nào khác đến máy chủ. Bản thân yêu cầu trông như thế này:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

Vì đó là một tiêu chuẩn công cộng được triển khai rộng rãi, bạn không phải lo lắng về việc xác định hành vi - chỉ cần chỉ các nhà phát triển phía khách hàng tại RFC. Bạn cũng có thể xem xét việc thực hiện phần còn lại của tiêu chuẩn OAuth2 như cả một máy chủ tài nguyên và một máy chủ uỷ quyền , nhưng đó là một công việc nhiều hơn nữa.

Tại sao bạn không sử dụng tiêu đề yêu cầu? Điều này tách dữ liệu xác thực / ủy quyền khỏi dữ liệu có ý nghĩa thực tế của yêu cầu và nó có thể được sử dụng cho bất kỳ loại yêu cầu nào (sử dụng phần thân yêu cầu trên get thường là điều bạn không nên làm.)

Có quyền trong các tiêu đề cho phép bạn xác thực người dùng trước khi phân tích nội dung yêu cầu, điều này có lợi khi bạn không muốn hệ thống của mình lãng phí thời gian phân tích dữ liệu từ người dùng trái phép.