Làm thế nào để bảo mật các dịch vụ web RESTful?

Tôi phải triển khai các dịch vụ web RESTful an toàn . Tôi đã thực hiện một số nghiên cứu bằng cách sử dụng Google nhưng tôi bị mắc kẹt.

Các tùy chọn:

TLS (HTTPS) +

• HTTP Cơ bản (pc1oad1etter)
• Thông báo HTTP
• OAuth hai chân
• một cách tiếp cận dựa trên Cookie
• chứng chỉ khách hàng (Tom Ritter và tại đây )
• Yêu cầu đã ký sử dụng HMAC và thời gian tồn tại có hạn

Có nhiều lựa chọn khả thi hơn để xem xét không? Nếu OAuth thì phiên bản nào? Nó thậm chí không quan trọng? Từ những gì tôi đã đọc cho đến nay OAuth 2.0 với các mã thông báo không có chữ ký (tức là không có chữ ký) dường như không an toàn .

Tôi đã tìm thấy một bài viết rất thú vị khác về xác thực dựa trên REST .

Bảo mật API REST của bạn ... Cách phù hợp

Có một phương pháp khác, rất an toàn. Đó là chứng chỉ khách hàng. Biết cách máy chủ hiển thị Cảnh báo SSL khi bạn liên hệ với họ trên https? Máy chủ tốt có thể yêu cầu chứng chỉ từ khách hàng để họ biết khách hàng là người mà họ nói. Khách hàng tạo chứng chỉ và cung cấp cho bạn qua một kênh bảo mật (như vào văn phòng của bạn bằng khóa USB - tốt nhất là khóa USB không trojaned).

Bạn tải khóa công khai của chứng chỉ ứng dụng khách cert (và (các) chứng chỉ của người ký, nếu cần) vào máy chủ web của bạn và máy chủ web sẽ không chấp nhận kết nối từ bất kỳ ai ngoại trừ những người có khóa riêng tương ứng cho chứng chỉ nó biết về. Nó chạy trên lớp HTTPS, vì vậy bạn thậm chí có thể bỏ qua hoàn toàn xác thực cấp ứng dụng như OAuth (tùy thuộc vào yêu cầu của bạn). Bạn có thể tóm tắt một lớp và tạo Cơ quan phát hành chứng chỉ cục bộ và ký Yêu cầu cảnh báo từ máy khách, cho phép bạn bỏ qua các bước 'đưa họ vào văn phòng' và 'tải chứng chỉ vào máy chủ'.

Đau cổ? Chắc chắn rồi. Tốt cho mọi thứ? Không. Rất an toàn? Đúng vậy.

Tuy nhiên, nó dựa vào việc khách hàng giữ chứng chỉ của họ an toàn (họ không thể đăng khóa cá nhân của mình trực tuyến) và nó thường được sử dụng khi bạn bán dịch vụ cho khách hàng thay vì cho phép bất kỳ ai đăng ký và kết nối.

Dù sao, nó có thể không phải là giải pháp bạn đang tìm kiếm (thành thật mà nói thì có lẽ không phải vậy), nhưng đó là một lựa chọn khác.

HTTP Basic + HTTPS là một trong những phương pháp phổ biến.

Nếu chọn giữa các phiên bản OAuth, hãy sử dụng OAuth 2.0.

Mã thông báo mang tên OAuth chỉ nên được sử dụng với phương thức vận chuyển an toàn.

Các mã thông báo mang OAuth chỉ an toàn hoặc không an toàn như phương thức truyền mã hóa cuộc trò chuyện. HTTPS đảm nhận việc bảo vệ chống lại các cuộc tấn công phát lại, vì vậy mã thông báo mang tên không cần thiết cũng phải bảo vệ chống phát lại.

Mặc dù đúng là nếu ai đó chặn mã thông báo mang tên của bạn thì họ có thể mạo danh bạn khi gọi API, nhưng có rất nhiều cách để giảm thiểu rủi ro đó. Nếu bạn cung cấp cho mã thông báo của mình một khoảng thời gian hết hạn dài và mong đợi khách hàng của bạn lưu trữ mã thông báo tại địa phương, bạn có nguy cơ bị chặn và sử dụng sai mã thông báo hơn là nếu bạn cung cấp cho mã thông báo của mình hết hạn ngắn, yêu cầu khách hàng nhận mã thông báo mới cho mỗi phiên, và khuyên khách hàng không tiếp tục sử dụng token.

Nếu bạn cần bảo mật các trọng tải đi qua nhiều người tham gia, thì bạn cần một thứ gì đó hơn HTTPS / SSL, vì HTTPS / SSL chỉ mã hóa một liên kết của biểu đồ. Đây không phải là lỗi của OAuth.

Khách hàng dễ dàng nhận được mã thông báo mang tên Bearer, dễ dàng cho khách hàng sử dụng cho các lệnh gọi API và được sử dụng rộng rãi (với HTTPS) để bảo mật các API công khai từ Google, Facebook và nhiều dịch vụ khác.