Khóa API là gì?

Scrapeless Web Unlocker xác thực các yêu cầu API được tài liệu hóa với một khóa API Scrapeless được gửi trong tiêu đề x-api-token.

Một khóa API là một giá trị được phát hành bởi dịch vụ để phần mềm có thể xác định chính nó khi thực hiện các yêu cầu. Nó thường thuộc về một tài khoản, dự án hoặc ứng dụng hơn là về một phiên người dùng cụ thể. Máy chủ kiểm tra giá trị được trình bày và áp dụng các quy tắc truy cập và sử dụng của riêng nó. Định dạng khóa, tên tiêu đề, kiểm soát phạm vi và hành vi hết hạn là cụ thể cho nhà cung cấp. Một client nên tìm hiểu những quy tắc đó từ tài liệu API hiện tại thay vì giả định rằng mọi khóa hoạt động giống như một mã thông báo mang theo.

Đối với một ứng dụng dữ liệu web, sự phân biệt là thực tiễn. Một yêu cầu có thể đến đúng điểm cuối nhưng lại thất bại vì không có khóa được cung cấp, khóa được gửi trong trường sai, hoặc tài khoản không có quyền truy cập vào sản phẩm đó. Ngược lại, một khóa mà xác thực thành công không chứng minh rằng URL hoặc dữ liệu đã yêu cầu là hợp lệ. Hướng dẫn này coi khóa như một phần của yêu cầu được kiểm soát và theo dõi vòng đời của nó từ việc tạo ra đến việc thu hồi.

Một Khóa Xác định và Những Gì Nó Không Xác định

Một nhà cung cấp có thể cấp một khóa để xác định người gọi, đo lường mức sử dụng, thực thi hạn ngạch và liên kết các yêu cầu với một tài khoản hoặc dự án. Một số hệ thống cũng cho phép một khóa bị giới hạn bởi môi trường, hoạt động hoặc nguồn gốc mạng. Không có các hạn chế nào nên được giả định trừ khi nhà cung cấp thực sự cung cấp chúng. Khóa là một thông tin xác thực; chính sách ủy quyền của nhà cung cấp xác định những gì thông tin xác thực đó có thể làm vào thời điểm của một yêu cầu.

Một khóa không giống như mật khẩu người dùng. Nó thường cho phép truy cập máy mà không cần đăng nhập tương tác, và nhiều dịch vụ có thể phụ thuộc vào nó. Nó cũng không tự động là một mã thông báo truy cập OAuth. Thông số kỹ thuật token bearer OAuth mô tả một sơ đồ trình bày; nhiều hệ thống khóa API sử dụng một tiêu đề tùy chỉnh. Đối xử với mỗi bí mật như một giá trị Bearer có thể phá vỡ xác thực hoặc đặt nó ở nơi mà nhà cung cấp không bao giờ dự định.

Scrapeless Hướng dẫn về khóa API says Web Unlocker REST requests gửi khóa thô trong x-api-token mà không có tiền tố Bearer. Hướng dẫn tương tự giải thích rằng các giao diện Scrapeless khác có thể sử dụng các phương pháp kết nối khác nhau. Đọc hướng dẫn sản phẩm đã chọn trước khi di chuyển thông tin xác thực giữa một khách hàng REST, kết nối trình duyệt, cấu hình proxy, hoặc SDK.

Nơi một API Key thuộc về trong một yêu cầu HTTP

Hợp đồng dịch vụ quyết định xem một thông tin xác thực sẽ nằm trong một tiêu đề, một trường vận chuyển khác, hoặc một tham số kết nối cụ thể. Các tiêu đề HTTP thường được sử dụng cho các API server-to-server vì chúng giữ thông tin xác thực tách biệt khỏi URL tài nguyên. The Mô hình trường HTTP giải thích cách mà siêu dữ liệu yêu cầu di chuyển cùng với một thông điệp. Các tiêu đề vẫn có thể nhìn thấy đối với khách hàng, các proxy dưới sự kiểm soát của họ, và nhật ký máy chủ nếu những hệ thống đó ghi lại chúng; một tiêu đề không phải là một thay thế cho TLS hoặc việc xóa nhật ký.

Tránh việc đưa một khóa tồn tại lâu dài vào URL trừ khi nhà cung cấp yêu cầu rõ ràng. Các URL có thể xuất hiện trong lịch sử trình duyệt, phân tích, quy trình giới thiệu, nhật ký proxy ngược và ảnh chụp màn hình đã dán. Ngay cả một tiêu đề chính xác cũng có thể rò rỉ nếu theo dõi HTTP chi tiết in ra các yêu cầu hoàn chỉnh. Xóa x-api-token và bất kỳ URL kết nối nào chứa một token trước khi chia sẻ thông tin chẩn đoán. Lưu trữ một ID yêu cầu hoặc tiền tố an toàn cho hỗ trợ thay vì thông tin xác thực đầy đủ.

Một ứng dụng nên từ chối một khóa trống tình cờ trước khi gửi yêu cầu. Trong quy trình máy chủ, đọc một bí mật từ môi trường triển khai hoặc trình quản lý bí mật và thất bại trong quá trình khởi động nếu nó không có sẵn. Một shell phát triển cục bộ có thể tải một giá trị cho một phiên, nhưng điều đó không làm cho khóa an toàn trong lịch sử shell hoặc một tệp cấu hình đã được cam kết. Giữ ví dụ như là các ký hiệu thay thế và chỉ kiểm tra giá trị thực trong một môi trường riêng tư.

Lưu trữ an toàn trong suốt quá trình phát triển và triển khai

Trong quá trình phát triển, hãy sử dụng biến môi trường hoặc tệp bí mật cục bộ không được đưa vào kiểm soát phiên bản. Tệp .env chỉ là nơi lưu trữ; quá trình sẽ không đọc nó trừ khi một bộ nạp hoặc mã ứng dụng làm như vậy. Các tệp ví dụ được chia sẻ nên chứa các giá trị rỗng hoặc các chỗ giữ chỗ rõ ràng. Hướng dẫn về thông tin xác thực mã cứng của OWASP giải thích tại sao các bí mật nhúng trong mã nguồn khó bị kiểm soát sau khi phát hành.

Trong sản xuất, hãy đặt khóa trong kho bí mật của nền tảng và chỉ cấp quyền truy cập đọc cho dịch vụ cần nó. Tiêm nó vào thời gian chạy thay vì nhúng nó vào một hình ảnh hoặc gói frontend. Kiểm tra ai có thể thay đổi bí mật và những triển khai nào tiêu thụ nó. Một ứng dụng JavaScript phía trình duyệt không thể giữ bí mật của khóa có thời gian sống dài khỏi người đang chạy trình duyệt đó; hãy sử dụng một backend đáng tin cậy khi khóa cấp quyền truy cập ở cấp tài khoản.

Bảo vệ các bề mặt liền kề cũng vậy. Đầu ra CI, theo dõi lỗi, theo dõi yêu cầu, ô trong sổ tay, vé hỗ trợ và bản ghi màn hình đều có thể mang theo thông tin chứng thực ngay cả khi kho lưu trữ không có. Cấu hình việc xóa tự động cho các tên tiêu đề và mẫu khóa đã biết, nhưng hãy kiểm tra một bản ghi đại diện để xác nhận bộ lọc hoạt động. Hạn chế việc lưu giữ các bản ghi đã từng lưu trữ bí mật và xóa các bản sao đã bị lộ sau khi thu hồi.

Cách Sử Dụng Một Chìa Khóa Mà Không Gặp Lỗi Đọc Sai

Một yêu cầu có nhiều giai đoạn xác thực. Máy chủ kiểm tra phương tiện vận chuyển và cú pháp, xác định thông tin đăng nhập, đánh giá quyền truy cập, kiểm tra input cụ thể cho sản phẩm, và cuối cùng trả về kết quả hoặc lỗi. Một lỗi xác thực gợi ý rằng khóa đã bị thiếu, sai định dạng, hết hạn, hoặc được gửi bằng phương thức sai. Một lỗi ủy quyền hoặc cân bằng có thể xảy ra ngay cả khi khóa được công nhận. Một payload không hợp lệ là một vấn đề tách biệt. Chỉ thay đổi lớp liên quan đến lỗi đã được tài liệu hóa.

Scrapeless tài liệu một yêu cầu Lấy Thông tin Người dùng như một cách để xác minh xác thực khóa mà không cần bắt đầu một nhiệm vụ quét. Việc xác thực thành công ở đó chứng minh rằng khóa đã hoạt động cho thao tác đó; nó không thiết lập quyền truy cập vào mọi sản phẩm. Một tài liệu nhỏ, đã được xác nhận Yêu cầu mở khóa web sau đó có thể kiểm tra đường dẫn cụ thể của sản phẩm. Kiểm tra nội dung phản hồi cũng như trạng thái HTTP và không bao giờ công khai thông tin tài khoản được trả về bởi một cuộc gọi xác minh.

The Trang sản phẩm Web Unlocker mô tả việc truy xuất web công khai dựa trên URL. Nếu một phản hồi được lấy thiếu nội dung mong đợi, hãy tránh coi chìa khóa là nguyên nhân có thể xảy ra chỉ vì cuộc gọi giống nhau đã sử dụng một chìa khóa. Xác nhận URL mục tiêu, chuyển hướng, nhu cầu kết xuất, loại đầu ra và danh tính trang nguồn. Xác thực thông tin đăng nhập và xác thực nội dung trả lời các câu hỏi khác nhau.

Xoay, Phơi sáng và Tước quyền

Một luân chuyển đã lên kế hoạch là một thay đổi triển khai được phân đoạn. Kiểm kê các dịch vụ sử dụng khóa cũ, cung cấp một khóa thay thế bằng cách sử dụng các điều khiển có sẵn của nhà cung cấp, cập nhật từng kho bí mật, khởi động lại các quy trình chỉ đọc bí mật khi khởi động, và xác minh các hoạt động đại diện. Khi khóa mới đã được chứng minh, hãy hủy hiệu lực khóa cũ. Ghi lại chủ sở hữu và thời gian chuyển giao để các sự cố sau này có thể được truy nguyên về thay đổi này thay vì phải đoán.

Một khóa bị lộ yêu cầu phải được kiềm chế trước. Hủy hiệu lực của nó thông qua các điều khiển hoặc kênh hỗ trợ có sẵn của nhà cung cấp, ngay cả khi điều này làm gián đoạn một công việc, sau đó phát hành một khóa thay thế và xem xét việc sử dụng gần đây. Việc xóa một commit kho lưu trữ hoặc hiệu chỉnh một ảnh chụp màn hình không hủy hiệu lực một khóa đã sao chép. Bảo tồn đủ bằng chứng sự cố để hiểu nơi xảy ra việc lộ khóa, nhưng tránh sao chép bí mật vào các vé mới trong khi điều tra.

Phạm vi và thời hạn làm giảm bán kính vụ nổ khi nhà cung cấp cung cấp chúng, nhưng chúng không loại bỏ nhu cầu về lưu trữ an toàn. Một khóa có phạm vi hẹp vẫn có thể tiết lộ dữ liệu hoặc phát sinh charges trong phạm vi của nó. Tách biệt thông tin xác thực phát triển và sản xuất khi mô hình tài khoản hỗ trợ. Nếu một khóa phục vụ cho nhiều công việc không liên quan, việc xoay vòng trở nên khó khăn hơn vì mỗi người tiêu dùng phải di chuyển cùng nhau; lên kế hoạch cho sự phụ thuộc đó trước một tình huống khẩn cấp.

Chọn Giữa Khóa API và Quyền Truy Cập Được Ủy Quyền

Khóa API hoạt động tốt cho một dịch vụ backend sử dụng tài khoản riêng của nó, đặc biệt khi nhà cung cấp đưa ra các hạn chế và khả năng thu hồi rõ ràng. Chúng là cách kém hiệu quả để cấp quyền truy cập rộng rãi cho một ứng dụng bên thứ ba không liên quan đến tài khoản của người dùng. Một giao thức ủy quyền ủy quyền có thể cấp quyền truy cập có giới hạn thay mặt cho người dùng và cung cấp các vòng đời token riêng biệt. Sự chọn lựa đúng đắn phụ thuộc vào mối quan hệ tin cậy, không phải vào việc thông tin xác thực nào trông ngắn hơn trong một ví dụ.

Đối với việc tích hợp khách hàng, hãy viết xuống ai sở hữu tài khoản, nơi lưu trữ bí mật, nó có thể làm gì, cách sử dụng của nó được giám sát như thế nào và cách nó sẽ bị thu hồi. Nếu một ứng dụng di động hoặc trình duyệt phải gọi nhà cung cấp, hãy xem xét một proxy phía sau xác thực người dùng cuối và sau đó thực hiện yêu cầu nhà cung cấp từ một môi trường đáng tin cậy. Backend đó cần có các kiểm tra ủy quyền riêng của nó để không trở thành một điểm phát tín hiệu mở.

Các quy tắc: 1. Chỉ xuất ra văn bản đã dịch — không giải thích, không mã gói thêm. 2. Bảo tồn cấu trúc Markdown/HTML (đầu đề, danh sách, liên kết, bảng) chính xác như vậy. 3. Giữ nguyên bất kỳ mã giữ chỗ nào như @@CODEBLOCK_0@@ hoặc @@INLINECODE_0@@ ĐÚNG NHƯ VẬY; không bao giờ dịch, thay đổi thứ tự, gộp hoặc định dạng lại chúng. 4. KHÔNG thêm hoặc xóa ``` mã gói, và KHÔNG bọc văn bản bình thường vào một khối mã. Văn bản liên quan Hướng dẫn gọi API Python hiển thị các cơ chế HTTP xung quanh. Giữ các ý tưởng về vận chuyển riêng biệt với các chi tiết xác thực cụ thể của nhà cung cấp, có thể thay đổi. Đối với Scrapeless, tài liệu hướng dẫn quản lý khóa hiện tại vẫn là cơ sở cho tiêu đề chính xác và bề mặt xác minh.

Kết luận

Một khóa API xác định một trình gọi theo chính sách truy cập của nhà cung cấp. Việc sử dụng an toàn của nó phụ thuộc vào phương thức yêu cầu chính xác, lưu trữ được kiểm soát, chẩn đoán bị che khuất và một quy trình thay thế đã được kiểm tra. Xác minh khóa với một thao tác đã được tài liệu hóa, sau đó xác minh riêng quyền truy cập sản phẩm và nội dung phản hồi.