Bảo mật cho REST "Riêng tư" REST

Question

Tôi hiện đang phát triển một ứng dụng web ngay bây giờ bao gồm giao diện người dùng hiển thị và tương tác với dữ liệu bằng cách sử dụng API REST mà chúng tôi đã viết. Điều duy nhất sẽ sử dụng API là trang web giao diện người dùng của chúng tôi và tại một thời điểm nào đó, ứng dụng dành cho thiết bị di động mà chúng tôi sẽ phát triển.

Tôi đã đọc rất nhiều về cách OAuth là cơ chế lý tưởng để bảo mật API và tại thời điểm này, tôi bắt đầu hiểu rõ cách hoạt động của API.

Câu hỏi của tôi là - vì tôi không bao giờ cấp quyền truy cập vào API của tôi cho ứng dụng khách của bên thứ ba, OAuth có thực sự cần thiết không? Có lý do gì đó là thuận lợi không? Hơn nữa, vì phần cuối chỉ đơn giản là API, không có cổng cho người dùng xác thực (như khi bạn đang viết một ứng dụng bằng API Twitter, khi người dùng xác thực họ sẽ được chuyển đến trang Twitter để cấp quyền truy cập sau đó được chuyển hướng trở lại máy khách).

Tôi không thực sự chắc chắn hướng đi. Có vẻ như phải có một số cách tiếp cận giữa xác thực http và OAuth phù hợp với tình huống này nhưng tôi không nhận được.

Answer 1

OAuth 2 chân có lẽ là những gì bạn muốn sử dụng. Về cơ bản nó băm một khóa chia sẻ, nhưng bạn có lợi thế là không phải tự viết mã.

Dưới đây là một câu hỏi liên quan: Two-legged OAuth - looking for information

Answer 2

Bạn nên sử dụng OAuth cho điện thoại di động để liên lạc lớp API.

Tuy nhiên, không có lợi ích nào của Oauth trong lớp giao diện người dùng web này đối với truy cập lớp giữa (máy đến máy).

Mặt khác có một số vấn đề tiềm năng

1. Quản lý việc truy cập hết hạn thẻ trở thành một nỗi đau. Hãy xem xét giao diện người dùng của bạn phải cache mã thông báo truy cập trên nhiều nút trong một cụm. Làm mới nó khi hết hạn, và thực tế là lớp UI đang thương lượng bảo mật với phần phụ trợ sẽ chỉ mất thêm thời gian một lần trong một thời gian.

2. Trong hai chân Oauth (Thông tin ứng dụng khách OAuth như trong v2.0) không hỗ trợ bất kỳ mã hóa nào. Vì vậy, bạn vẫn cần phải gửi khóa và bí mật cho cả máy chủ để nhận mã thông báo truy cập.

3. Backend có để thực hiện phát hành access token, làm mới thẻ, xác nhận access token vv, mà không cần bất kỳ lợi ích đáng kể

Answer 3

Từ quan điểm của tôi, một trong những kịch bản có lợi cho OAuth qua tùy chọn khác là để làm việc với các khách hàng không tin cậy, cho dù chúng được phát triển bởi bạn hay một bên thứ ba.

Khách hàng không tin cậy là gì? Hãy suy nghĩ từ quan điểm của người xử lý thông tin xác thực cấp quyền truy cập vào API của bạn.

• Ví dụ, ứng dụng web của bạn có thể tương tác với API của bạn trong hai falvors:

  1. của bạn ứng dụng web đàm phán phía máy chủ để API của bạn.Máy chủ ứng dụng web của bạn là một ứng dụng đáng tin cậy vì thông tin đăng nhập để truy cập API của bạn chỉ có thể được truy cập bởi những người có quyền truy cập vào máy chủ ... Bạn và nhóm của bạn. Bạn có thể xác thực máy chủ ứng dụng web của mình với client_id và client_secret.
  2. Bạn có thể thực hiện cuộc gọi trực tiếp tới API của mình từ ứng dụng khách Web, chạy trên trình duyệt của người dùng cuối bằng JavaScript. Trình duyệt của người dùng cuối là một ứng dụng không tin cậy. Nếu bạn cung cấp thông tin đăng nhập cho API của mình xuống trình duyệt, bất kỳ ai cũng có thể kiểm tra mã JavaScript và lấy cắp thông tin đăng nhập của bạn.

• Ứng dụng gốc của bên thứ ba cũng không đáng tin cậy. Một nhà phát triển độc hại sử dụng API của bạn có thể lưu thông tin đăng nhập và người dùng cuối của nền tảng của bạn.

• Ứng dụng gốc của bạn là ứng dụng khách đáng tin cậy và có thể quản lý xác thực bằng tên người dùng, mật khẩu đơn giản và id ứng dụng nhận dạng ứng dụng của bạn.

Làm thế nào để OAuth có thể trợ giúp? OAuth Authorization code và Implicit khoản trợ cấp có thể giúp bạn giải quyết vấn đề này. Các luồng này chỉ hoạt động với các khách hàng hỗ trợ chuyển hướng, như trình duyệt. Và cho phép bạn xác thực một máy khách không đáng tin cậy và người dùng chống lại Máy chủ ủy quyền của bạn để truy cập vào Máy chủ tài nguyên, API của bạn, mà không để lộ thông tin xác thực. Hãy xem RFC để xem cách thực hiện.

Điều tốt của OAuth là nó không chỉ hỗ trợ các luồng xác thực dựa trên chuyển hướng này, mà còn hỗ trợ cấp ủy nhiệm khách hàng và cấp ủy nhiệm người dùng. Vì vậy, Máy chủ ủy quyền OAuth sẽ bao gồm tất cả các trường hợp.

Answer 4

OAuth 2.0 ban đầu có vẻ như PITA nếu bạn nghĩ về việc phải tự mình xây dựng, nhưng hầu hết các ngôn ngữ đều có một số thiết lập OAuth 2.0 thực sự vững chắc mà bạn có thể sử dụng với số lượng thay đổi không đáng kể. Nếu bạn đang sử dụng một framework như Laravel hoặc RoR thì nó hầu như không có tác dụng.

• PHP: http://oauth2.thephpleague.com/
• Ruby (Rails hoặc nho): https://github.com/doorkeeper-gem/doorkeeper

Nếu bạn không muốn chuyển hướng người dùng như đề xuất trong bài viết của bạn thì bỏ qua ý kiến ​​và câu trả lời khác mà nói về hai dòng chảy chân. Bạn có thể sử dụng loại tài trợ client_credentials để các ứng dụng chỉ cung cấp id khách hàng và bí mật của chúng để đổi lấy mã thông báo truy cập, điều này thật dễ dàng và dễ dàng.

Tôi sẽ hỏi chúng ta đang nói chuyện như thế nào, bởi vì nếu hệ thống duy nhất nói chuyện với nó nằm trong phần phụ trợ và không có tương tác với thế giới bên ngoài, bạn có thể để nó mở rộng và chỉ dựa vào mạng để giữ an toàn (VPN/Tường lửa).

Nhưng nếu riêng tư theo nghĩa "ứng dụng iPhone của chúng tôi sử dụng ứng dụng" thì bạn chắc chắn muốn sử dụng OAuth 2.0 hoặc một thứ gì đó tương tự.