Đặt khóa API trong Tiêu đề hoặc URL

78

Tôi đang thiết kế một API công khai cho dữ liệu của công ty tôi. Chúng tôi muốn các nhà phát triển ứng dụng đăng ký khóa API để chúng tôi có thể giám sát việc sử dụng và sử dụng quá mức.

Vì API là REST, suy nghĩ ban đầu của tôi là đặt khóa này trong tiêu đề tùy chỉnh. Đây là cách tôi đã thấy Google, Amazon và Yahoo làm điều đó. Mặt khác, sếp của tôi cho rằng API dễ sử dụng hơn nếu khóa chỉ trở thành một phần của URL, v.v. " http: //api.domain.tld/longapikey1234/resource ". Tôi đoán có điều gì đó cần phải nói về điều đó, nhưng nó vi phạm nguyên tắc của URL là một địa chỉ đơn giản của những gì bạn muốn chứ không phải bằng cách nào hoặc tại sao bạn muốn nó.

Bạn có thấy hợp lý khi đặt khóa vào URL không? Hay bạn sẽ không phải đặt tiêu đề HTTP theo cách thủ công nếu viết một giao diện người dùng javascript đơn giản cho một số dữ liệu?

— Thomas Ahle
nguồn

77

Nó phải được đặt trong tiêu đề Ủy quyền HTTP. Thông số kỹ thuật ở đây https://tools.ietf.org/html/rfc7235

— Darrel Miller
nguồn

Tôi đã sử dụng tiêu đề Ủy quyền cho phần thứ ba - người dùng cuối. Đó là người dùng cuối cần đăng nhập vào ứng dụng để có toàn quyền truy cập vào nội dung.

— Thomas Ahle

5

@Thomas Không có giới hạn về số lượng tham số bạn có thể đặt trong tiêu đề xác thực. Nhìn vào OAuth, nó có khoảng 8 giá trị tham số khác nhau trong tiêu đề.

— Darrel Miller

1

Liên kết cập nhật - Đây hiện là RFC 7235 kể từ tháng 6 năm 2014

— Stephen P

Tôi không nói là bạn sai, nhưng khi bạn nói " Điều đó nên xảy ra " - làm sao bạn biết? Ai nói? (Tôi thấy câu hỏi này bởi vì nó dường như Apache thường dải tiêu đề ủy quyền trước PHP con để thực hiện)

— JAAulde

2

@JAAulde Tôi đi vào chi tiết hơn ở đây bizcoder.com/where-oh-where-does-the-api-key-go Tôi sẽ quan tâm nếu bạn có bất kỳ liên kết nào đến vấn đề Apache.

— Darrel Miller

67

Nếu bạn muốn một lập luận có thể thu hút sếp: Hãy nghĩ về URL là gì. URL là công khai. Mọi người sao chép và dán chúng. Họ chia sẻ chúng, họ đưa chúng lên quảng cáo. Không có gì ngăn cản ai đó (cố ý hoặc không) gửi URL đó qua đường bưu điện cho người khác sử dụng. Nếu khóa API của bạn nằm trong URL đó, thì mọi người đều có.

— đứng
nguồn

1

Ngoài điểm của bạn về công bố công khai của một URL, URL và một in-line khóa API sẽ được hiển thị cho tất cả các nhà quản trị mạng với quyền truy cập vào một bộ định tuyến, công ty máy chủ proxy, bộ nhớ đệm máy chủ, vv

— Adam Caviness

4

@AdamCaviness Không phải với HTTPS, mà tất cả các API nên triển khai. URL được mã hóa. Với tư cách là quản trị viên, bạn chỉ có thể xem tra cứu DNS và địa chỉ IP được giao tiếp chứ không phải nội dung. Rằng ngoài Tôi đồng ý với lập trường

— nickdnk

1

@nickdnk, đó là sự thật. Bây giờ liên quan đến HTTPS, ngay cả khi đó, các URL đầy đủ vẫn còn trong lịch sử trình duyệt! Công cụ thú vị. Tôi không phải là người thích bất cứ thứ gì nhạy cảm trong URL.

— Adam Caviness

@AdamCaviness Vâng, theo nghĩa đó. Tôi hiểu nó giống như ai đó có thể đọc lưu lượng nếu họ có quyền truy cập vào bộ định tuyến.

— nickdnk

Và API này là một ví dụ điển hình về cách không làm như pipedrive.com/en/api .

— John John Pichler

13

Tốt hơn là sử dụng Khóa API trong tiêu đề, không phải trong URL.

URL được lưu trong lịch sử của trình duyệt nếu nó được thử từ trình duyệt. Đó là kịch bản rất hiếm. Nhưng vấn đề xảy ra khi máy chủ phụ trợ ghi lại tất cả các URL. Nó có thể làm lộ khóa API.

Theo hai cách, bạn có thể sử dụng Khóa API trong tiêu đề

Ủy quyền cơ bản:

Ví dụ từ sọc:

curl https://api.stripe.com/v1/charges -u sk_test_BQokikJOvBiI2HlWgH4olfQ2:

curl sử dụng cờ -u để chuyển thông tin xác thực cơ bản (thêm dấu hai chấm sau khóa API của bạn sẽ ngăn khóa API yêu cầu bạn nhập mật khẩu).

Tiêu đề tùy chỉnh

curl -H "X-API-KEY: 6fa741de1bdd1d91830ba" https://api.mydomain.com/v1/users

— Fizer Khan
nguồn

1

Tại sao sử dụng X-API-KEY? X này có phải là một loại đặc tả HTTP cho tiêu đề tùy chỉnh không?

— John John Pichler

1

stackoverflow.com/questions/3561381/…

— Fizer Khan,

2

Tôi sẽ không đặt khóa trong url, vì nó vi phạm 'tiêu chuẩn' lỏng lẻo này là REST. Tuy nhiên, nếu bạn đã làm vậy, tôi sẽ đặt nó trong phần 'người dùng' của url.

ví dụ: http: //me@example.com/myresource/myid

Bằng cách này, nó cũng có thể được chuyển dưới dạng tiêu đề với basic-auth.

— Adam Wagner
nguồn

5

Lưu ý 1) đây chỉ là cách viết tắt của xác thực cơ bản, 2) không phải tất cả các ứng dụng HTTP đều tuân theo điều đó và 3) ít nhất một trình duyệt chính sẽ hiển thị cảnh báo lừa đảo.

— dùng359996

@ user359996 Đã lấy điểm. Đáp lại: 1) Tôi đã né tránh điều đó trong câu cuối cùng của mình, 2) Điều này được đề cập trong tiêu chuẩn ( tools.ietf.org/html/rfc3986 ), vì vậy đó là lỗi của khách hàng, 3) Tôi không biết về điều đó , mặc dù tôi cho rằng nó có lý, tôi tự hỏi liệu điều này có còn xảy ra khi được sử dụng như một cuộc gọi api (XHR) hay không. Cuối cùng, câu hỏi là về việc bao gồm thông tin xác thực trong url một cách dễ hiểu và tôi nghĩ tôi đã trả lời điều đó.

— Adam Wagner

1

truyền khóa api trong các tham số khiến khách hàng khó giữ bí mật các khóa API của họ, họ có xu hướng làm rò rỉ khóa một cách thường xuyên. Một cách tiếp cận tốt hơn là chuyển nó vào tiêu đề url yêu cầu. Bạn có thể đặt tiêu đề khóa người dùng trong mã của mình. Để kiểm tra Url yêu cầu của bạn, bạn có thể sử dụng ứng dụng Postman trong google chrome bằng cách đặt tiêu đề khóa người dùng thành khóa api của bạn.

— himanshu_chawla
nguồn

1

Các khóa api trong thông số như thế nào khiến người dùng bị lộ khóa?

— Heinzlmaen