Khóa API so với Xác thực HTTP so với OAuth trong API RESTful

Tôi đang làm việc để xây dựng một API RESTful cho một trong những ứng dụng mà tôi duy trì. Chúng tôi hiện đang tìm cách xây dựng nhiều thứ khác nhau vào đó yêu cầu quyền truy cập và bảo mật được kiểm soát nhiều hơn. Trong khi nghiên cứu cách bảo mật API, tôi đã tìm thấy một vài ý kiến ​​khác nhau về việc sử dụng biểu mẫu nào. Tôi đã thấy một số tài nguyên nói rằng HTTP-Auth là cách để đi, trong khi những người khác thích khóa API hơn và thậm chí những người khác (bao gồm cả các câu hỏi tôi tìm thấy ở đây trên SO) thề bằng OAuth.

Sau đó, tất nhiên, những thứ thích, chẳng hạn như khóa API, nói rằng OAuth được thiết kế cho các ứng dụng thay mặt người dùng truy cập (theo tôi hiểu, chẳng hạn như đăng nhập vào một trang web không phải Facebook bằng tài khoản Facebook của bạn), và không dành cho người dùng truy cập trực tiếp vào tài nguyên trên trang web mà họ đã đăng ký cụ thể (chẳng hạn như ứng dụng Twitter chính thức truy cập máy chủ Twitter). Tuy nhiên, các đề xuất dành cho OAuth dường như chỉ dành cho nhu cầu xác thực cơ bản nhất.

Sau đó, câu hỏi của tôi là - giả sử tất cả đều được thực hiện qua HTTPS, thì đâu là một số khác biệt thực tế giữa ba loại này? Khi nào thì một cái nên được xem xét hơn những cái khác?

Nó phụ thuộc vào nhu cầu của bạn. Bạn có cần:

• Identity - ai tuyên bố đang đưa ra yêu cầu API?
• Xác thực - họ có thực sự là người mà họ nói không?
• Ủy quyền - họ có được phép làm những gì họ đang cố gắng làm không?

hoặc cả ba?

Nếu bạn chỉ cần xác định người gọi để theo dõi khối lượng hoặc số lượng Lệnh gọi API, hãy sử dụng Khóa API đơn giản. Hãy nhớ rằng nếu người dùng mà bạn đã cấp khóa API chia sẻ khóa này với người khác, họ cũng có thể gọi API của bạn.

Tuy nhiên, nếu bạn cũng cần Ủy quyền, tức là bạn chỉ cần cung cấp quyền truy cập vào một số tài nguyên nhất định dựa trên trình gọi của API, sau đó sử dụng oAuth.

Đây là một mô tả tốt: http://www.srimax.com/index.php/do-you-need-api-keys-api-identity-vs-authorization/

Khóa API hoặc thậm chí là Mã thông báo thuộc loại cơ chế Xác thực và Ủy quyền trực tiếp, vì chúng cấp quyền truy cập vào các tài nguyên tiếp xúc của API REST. Các cơ chế trực tiếp như vậy có thể được sử dụng trong các trường hợp sử dụng ủy quyền.

Để có quyền truy cập vào một tài nguyên hoặc một tập hợp các tài nguyên được tiếp xúc bởi các điểm cuối REST, cần phải kiểm tra các đặc quyền của người yêu cầu theo danh tính của nó. Bước đầu tiên của quy trình làm việc sau đó là xác minh danh tính bằng cách xác thực yêu cầu; bước kế tiếp là kiểm tra danh tính dựa trên một tập hợp các quy tắc đã xác định để cấp phép cấp độ truy cập (tức là đọc, ghi hoặc đọc / ghi). Khi các bước đã nói được hoàn thành, một mối quan tâm điển hình nữa là tốc độ yêu cầu cho phép , có nghĩa là người yêu cầu được phép thực hiện bao nhiêu yêu cầu mỗi giây đối với (các) tài nguyên đã cho.

OAuth (Ủy quyền mở) là một giao thức tiêu chuẩn cho quyền truy cập được ủy quyền , thường được các Công ty Internet lớn sử dụng để cấp quyền truy cập mà không cần cung cấp mật khẩu. Rõ ràng, OAuth là giao thức đáp ứng các mối quan tâm đã đề cập ở trên: Xác thực và Ủy quyền bằng cách cung cấp quyền truy cập được ủy quyền an toàn vào tài nguyên máy chủ thay mặt cho chủ sở hữu tài nguyên. Nó dựa trên cơ chế Mã thông báo truy cập cho phép bên thứ 3 có quyền truy cập vào tài nguyên do máy chủ quản lý thay mặt cho chủ sở hữu tài nguyên. Ví dụ: ServiceX muốn truy cập vào Tài khoản Google của John Smith thay mặt cho John, sau khi John đã ủy quyền; ServiceX sau đó sẽ được cấp một Mã thông báo dựa trên thời gian để truy cập vào chi tiết Tài khoản Google, rất có thể chỉ trong quyền truy cập đọc.

Khái niệm về Khóa API rất giống với Mã thông báo OAuth được mô tả ở trên. Sự khác biệt chính bao gồm việc không có ủy quyền: Người dùng trực tiếp yêu cầu Khóa cho nhà cung cấp dịch vụ cho các tương tác theo chương trình liên tiếp. Trường hợp của Khóa API cũng dựa trên thời gian: Khóa làm Mã thông báo OAuth phải tuân theo thời gian thuê hoặc thời gian hết hạn. Theo khía cạnh bổ sung, Khoá cũng như Mã thông báo có thể bị giới hạn tốc độ theo hợp đồng dịch vụ, tức là chỉ có thể phục vụ một số lượng yêu cầu nhất định mỗi giây.

Tóm lại, trên thực tế không có sự khác biệt thực sự giữa các cơ chế Xác thực và Ủy quyền truyền thống và các phiên bản dựa trên Key / Token. Tuy nhiên, mô hình hơi khác một chút: thay vì tiếp tục sử dụng lại thông tin đăng nhập ở mỗi và mọi tương tác giữa máy khách và máy chủ, một Khóa / Mã hỗ trợ được sử dụng để làm cho trải nghiệm tương tác tổng thể mượt mà hơn và có khả năng an toàn hơn (thường là theo tiêu chuẩn JWT , Khóa và Các mã thông báo được máy chủ ký kỹ thuật số để tránh làm thủ công).

• Xác thực và Ủy quyền Trực tiếp : Các giao thức dựa trên khóa như một biến thể của các phiên bản dựa trên thông tin xác thực truyền thống.
• Xác thực và Ủy quyền được ủy quyền : giống như các giao thức dựa trên OAuth, lần lượt sử dụng Mã thông báo, lại là một biến thể của các phiên bản dựa trên thông tin xác thực (mục tiêu tổng thể là không tiết lộ mật khẩu cho bất kỳ bên thứ ba nào).

Cả hai danh mục đều sử dụng quy trình xác minh danh tính truyền thống cho lần tương tác đầu tiên với máy chủ sở hữu (các) tài nguyên quan tâm.