Có phải lựa chọn tốt cho OAuth cho RESTful API trong kịch bản SaaS này không?

Question

OAuth có hợp lý để sử dụng khi thông tin tài khoản người dùng (id người dùng, mật khẩu, vai trò, v.v.) sẽ được duy trì trong back-end của chính chúng tôi và khi không có bất kỳ chia sẻ tài nguyên nào với các trang web khác không? Hoặc đang chia sẻ toàn bộ vấn đề sử dụng OAuth?

Bối cảnh:

Tôi đang nghiên cứu phát triển một sản phẩm SaaS doanh nghiệp và chúng tôi đang tạo ra một API RESTful để được sử dụng bởi các ứng dụng front-end của chúng tôi. Người tiêu dùng của API sẽ là trình duyệt và điện thoại thông minh bản địa (iOS & Android) mà chúng tôi phát triển. Vì chúng tôi sẽ hỗ trợ nhiều loại ứng dụng khách, nên tạo một RESTful API mà tất cả các ứng dụng khách của chúng tôi có thể tiêu thụ.

Đương nhiên, chúng tôi cần bảo mật API RESTful này. Chúng tôi đang cân nhắc việc xác thực bằng HTTPS/Basic Auth nhưng chúng tôi biết một số nhược điểm nổi tiếng của phương pháp này.

Một số nghiên cứu nhanh cho thấy OAuth được khuyến khích. Nhưng hầu hết những gì tôi tìm thấy với OAuth là trong bối cảnh cho phép các trang web chia sẻ thông tin thay mặt cho người dùng.

Mọi thông tin nếu được chào đón nhiều nhất.

Answer 1

Tốt câu hỏi, và chúng tôi đang có một cuộc thảo luận tốt trên hơn này tại Craft API:

https://groups.google.com/group/api-craft/browse_thread/thread/b87fd667cccb9c00

Dưới đây là câu trả lời mà tôi đăng ở đó:

Tôi nghĩ rằng đây là một sử dụng tốt trường hợp cho OAuth, thực sự.

Trước hết, với OAuth, ứng dụng di động của bạn có thể lưu trữ mã thông báo OAuth trên máy khách thay vì mật khẩu "thực" của người dùng.Vì vậy, bạn có thể tự động "đăng nhập người dùng" bằng cách nhận mã thông báo OAuth mà không phải lưu trữ mật khẩu thực trên thiết bị. Nếu người dùng mất thiết bị hoặc nếu bị xâm phạm, họ (hoặc bạn) có thể xóa mã thông báo OAuth mà không yêu cầu người dùng thay đổi mật khẩu và thổi đi những thứ khác mà họ có thể đang thực hiện với API của bạn. Có những ví dụ tương tự cho một ứng dụng web kiểu Ajax nhưng nó phụ thuộc nhiều hơn vào cách cụ thể mà bạn xây dựng ứng dụng khách.

Thứ hai, mã thông báo OAuth được liên kết với khóa duy nhất xác định ứng dụng đang thực hiện cuộc gọi API và xác định nhà phát triển đã tạo ứng dụng. Điều đó cung cấp cho bạn các tùy chọn như theo dõi mức sử dụng theo ứng dụng, tắt ứng dụng có thể đã bị xâm phạm mà không vô hiệu hóa toàn bộ API và nếu bạn muốn mở quyền truy cập cho bên thứ ba hoặc đối tác xây dựng ứng dụng cho API của bạn, bạn có thể cung cấp các cấp khác nhau dịch vụ cho các khách hàng khác.

Thứ ba, người bảo mật CNTT của bạn sẽ hài lòng nếu bạn nói với họ rằng bạn không bao giờ lưu mật khẩu trên thiết bị di động của người dùng hoặc giấu nó ở đâu đó trong trình duyệt của họ.

Thứ tư, bạn có tùy chọn đăng nhập dựa trên trình duyệt cho ứng dụng dành cho thiết bị di động. Điều đó có nghĩa là ứng dụng dành cho thiết bị di động sẽ không bao giờ thấy mật khẩu của người dùng và nếu bạn muốn triển khai bảo mật hai yếu tố hoặc thứ gì đó tương tự, bạn có thể làm điều đó trong màn hình đăng nhập mà không thay đổi ứng dụng dành cho thiết bị di động. Bây giờ, nhược điểm là người dùng thấy cửa sổ trình duyệt bật lên. Đó là lý do tại sao OAuth cung cấp cho bạn một số cách khác nhau để nhận mã thông báo truy cập cho một ứng dụng, vì vậy bạn có thể chọn có cần đăng nhập dựa trên trình duyệt hay không hoặc trực tiếp nhập mật khẩu của họ vào ứng dụng.

Thứ năm, làm thế nào để bạn biết rằng API của bạn sẽ chỉ được sử dụng bởi các ứng dụng của riêng bạn? Nếu bạn sử dụng OAuth ngay bây giờ thì bạn sẽ có thời gian dễ dàng hơn để thực hiện chuyển đổi đó sau đó.

Answer 2

OAuth chỉ là mã thông báo và ứng dụng yêu cầu sẽ phát hành một mã thông báo. Bạn có thể đọc thêm trong pingidentity.com, nơi cũng có một số hội thảo trên chủ đề này (nhận dạng điện toán đám mây và cấp phép người dùng).

Answer 3

Tôi đã triển khai OAuth cho Django nonrel với piston để hiển thị API của tôi cho người tiêu dùng. Có một số loại trong OAuth (2-chân 3legs).

Nói chung, hỗ trợ OAuth là một thử thách khá lớn. Bạn phải lấy mã thông báo yêu cầu, ủy quyền, lưu trữ mã thông báo truy cập để ký mọi yêu cầu bạn muốn xác thực.

Ưu
- Bạn không cần phải gửi tên người dùng và mọi mật khẩu, an toàn.
- Cho phép bên thứ ba tiêu thụ ứng dụng của bạn.
Nhược điểm
- Thực hiện 2,3 chuyến đi khứ hồi để xác thực.
- Phức tạp để thực hiện nó một mình.

Tôi khá chắc chắn rằng bạn có thể tìm thấy một số thư viện cho phép bạn:
- Hiển thị Api của bạn và hỗ trợ OAuth. Ví dụ: piston Django.
- Ký các yêu cầu của bạn bằng cách thêm tiêu đề cho chúng. Ví dụ: Biển báo Oauth.

Answer 4

Vâng, điều này rất phù hợp với OAuth. Bạn vẫn có thể sử dụng HTTP cơ bản qua SSL trong quá trình bắt tay để xác thực. Đầu ra của bắt tay OAuth sẽ là một mã thông báo mà sau đó có thể được sử dụng để tiêu thụ API. Bằng cách này, ứng dụng không cần lưu trữ thông tin đăng nhập và mã thông báo có thể dễ dàng bị thu hồi với tác động tối thiểu của người dùng.

OAuth 2.0 xác định một số loại cấp tài trợ khác nhau cho các tình huống khác nhau. Nghe có vẻ như tôi là 'ngầm' hoặc 'thông tin đăng nhập mật khẩu của chủ sở hữu tài nguyên' là thích hợp nhất nhưng bạn có thể muốn xem xét cẩn thận.

Bạn không nên triển khai trực tiếp điều này trong API của mình nhưng sử dụng cơ sở hạ tầng để ủy quyền hỗ trợ OAuth và quản lý mã thông báo thay mặt cho API SaaS của bạn thay thế.

Hãy xem

http://www.layer7tech.com/blogs/index.php/oauth-token-management-2/

và

http://www.layer7tech.com/products/oauth-toolkit

Hope trợ giúp này,

-fl