2010-10-10 37 views
13

Tôi hiện đang nghĩ cách tôi có thể bảo vệ API REST của mình mà ứng dụng di động của tôi chỉ được sử dụng bởi các ứng dụng khác? API-Key có thể là một giải pháp tốt hay không, bởi vì chỉ cho tôi biết khóa API bí mật. Có giải pháp nào tốt hơn không?Cách bảo vệ REST API riêng lẻ

+0

Bạn có thể làm rõ bạn muốn (a) để đảm bảo rằng chỉ bạn (hoặc người dùng được ủy quyền) mới có thể sử dụng dịch vụ của bạn hoặc (b) để đảm bảo rằng chỉ ứng dụng khách của bạn mới có thể sử dụng dịch vụ của bạn? – Bruno

+0

Tôi sẽ đảm bảo rằng chỉ ứng dụng khách của tôi mới có thể sử dụng dịch vụ của tôi. – LeonS

+0

Tôi nghĩ toàn bộ quan điểm của REST là không cần API? (Giống như RPC ...) – Anders

Trả lời

3

Sử dụng xác thực HTTP. REST là tất cả về việc sử dụng các cơ sở có sẵn trong HTTP, do đó, auth HTTP gốc nên được sử dụng. Với xác thực cơ bản, bạn sẽ phải sử dụng HTTPS. Nếu bạn không thể thực hiện điều đó, hãy sử dụng auth thông báo HTTP hoặc NTLM.

Tất cả chúng đều có điểm mạnh và điểm yếu khác nhau và không phải tất cả các điểm mạnh và điểm yếu đều có thể được máy chủ HTTP và thư viện ứng dụng hỗ trợ.

+0

Vì vậy, nếu tôi sử dụng Xác thực cơ bản HTTP kết hợp với HTTPS, tôi ở bên an toàn? Đặc biệt là không ai ngoại trừ tôi sẽ sử dụng API của tôi? – LeonS

+0

Leon nếu khách hàng và máy chủ của bạn không phải là cả hai phía sau một bức tường lửa, bạn phải lo lắng về gói tin ai đó đánh hơi kết nối của bạn. HTTPS mã hóa kết nối của bạn để không thể đánh hơi và Xác thực cơ bản cung cấp khóa API bạn muốn. –

+0

Ngay cả khi tôi cung cấp nhiều người dùng với tên người dùng và mật khẩu? Vì vậy, tôi sợ người khác sử dụng API của tôi với một ứng dụng khác. Tôi có thể ngoại trừ bằng https không? – LeonS

17

Leon, bạn tiếp tục đề cập đến "ai đó đang sử dụng API của tôi với một ứng dụng khác". Vì vậy, bạn muốn buộc API của bạn chỉ được một ứng dụng sử dụng? Vì vậy, bạn không muốn cấp quyền truy cập cho người dùng, thay vào đó bạn muốn cung cấp cho họ một phiên bản ứng dụng đang chạy trên thiết bị di động của người dùng.

Về bản chất: Bạn không tin tưởng người dùng! Trong trường hợp đó, bạn cần đảm bảo rằng ứng dụng của bạn là nguồn đóng, cần mã thông tin đăng nhập vào ứng dụng của bạn theo cách mà không ai có thể truy xuất hoặc lưu trữ thông tin xác thực cho ứng dụng theo cách được mã hóa đặc biệt trên trang web. thiết bị, khóa giải mã chỉ có thể đọc được bằng ứng dụng của bạn. Theo một cách nào đó, bạn cần triển khai một hình thức DRM để ngăn mọi người làm việc với dữ liệu trên thiết bị di động của họ. Và bạn cần phải hy vọng rằng không ai có thể đảo ngược kỹ sư đó.

Nếu ứng dụng của bạn trở nên phổ biến/đủ thú vị, hãy đếm thực tế rằng những người rất, rất giỏi loại điều này sẽ xem xét đơn đăng ký của bạn và sẽ phá vỡ mã hóa của bạn trước khi bạn biết. Có lẽ, nếu bạn đặt cùng một lượng nỗ lực vào nó như Skype có, có thể sau đó bạn có thể tránh chúng ra một lúc.

Nhưng hãy tự hỏi: Tại sao phải bận tâm? Tại sao tôi không tin tưởng người dùng của mình? Có thực sự đáng để nhảy qua các vòng như thế này để ngăn một số ứng dụng khác sử dụng API của tôi không?

Chỉ cần hướng dẫn người dùng của bạn thông qua quy trình đăng ký trong đó mỗi cá thể ứng dụng nhận khóa duy nhất từ ​​máy chủ (hoặc mật khẩu xác thực HTTP duy nhất) và lưu trữ ở đâu đó trên thiết bị di động của người dùng. Sau đó, để truy cập các tính năng thú vị trong API, yêu cầu sự hiện diện của khóa/mật khẩu này. Nhưng đừng đi qua chiều dài cực đoan để làm xáo trộn hoặc mã hóa khóa khi bạn lưu trữ nó cục bộ, nó không đáng giá. Nếu bạn phát hiện sử dụng sai sau này, bạn luôn có thể thu hồi quyền truy cập cho một tài khoản cụ thể trên máy chủ.

Các vấn đề liên quan