2011-11-03 55 views
17

Ứng dụng của tôi được cấu trúc như sau: Tôi có dịch vụ web (chạy trên GAE, không liên quan đến câu hỏi này) và dữ liệu mà dịch vụ này chứa có sẵn thông qua trang web và thông qua ứng dụng dành cho thiết bị di động và máy tính để bàn.Cách cho phép ứng dụng di động với bên thứ ba bằng oauth BUT kết nối với dịch vụ của tôi, không phải bên thứ ba

Hiện tại, người dùng xác thực với trang web qua Google ClientLogin và các ứng dụng xác thực/được ủy quyền thông qua nhà cung cấp Oauth tích hợp của GAE. (OAuth đang được sử dụng ở đây chủ yếu để xác thực, ứng dụng của tôi không thực sự sử dụng bất kỳ dữ liệu bên ngoài nào qua OAuth ngoài ID và địa chỉ email duy nhất của người dùng.)

Điều tôi muốn làm là mở rộng số lượng dịch vụ mà người dùng có thể sử dụng để đăng nhập. Do yếu tố phức tạp của các ứng dụng, có vẻ như tôi cần OAuth. Nhưng tôi có thể không thực sự đúng cách khái niệm hóa dòng chảy này nên đi như thế nào.

Cho phép lấy Facebook làm ví dụ. Khi một ứng dụng di động đi qua luồng oauth của Facebook và lấy mã thông báo truy cập, điều này là không đủ - bởi vì dịch vụ của tôi, không phải ứng dụng, thực sự cần nói chuyện với facebook để lấy thông tin liên hệ và ID người dùng duy nhất. Điều này khiến tôi nghĩ rằng quá trình OAuth cần phải xảy ra trong ngữ cảnh dịch vụ của tôi chứ không phải ứng dụng dành cho thiết bị di động. Dịch vụ của tôi sau đó trở thành người tiêu dùng và Facebook là nhà cung cấp oauth và dịch vụ giữ mã thông báo truy cập oauth, điều này xảy ra khi người dùng thiết lập tài khoản của họ lần đầu tiên.

Nếu đây là cách tiếp cận chính xác, điều đó sẽ để lại xác thực cho ứng dụng ở đâu? Điều gì sẽ xảy ra khi người dùng đã có tài khoản và cài đặt phiên bản ứng dụng dành cho thiết bị di động mới? Tôi cũng hình dung quá trình oauth, kết hợp thông tin đăng nhập với dữ liệu đã được dịch vụ của tôi lưu trữ và sau đó phát hành "mã thông báo truy cập" của riêng tôi cho ứng dụng từ dịch vụ, để cho phép ứng dụng đó. Điều này có vẻ phức tạp và hackish.

Tôi chắc chắn rằng tôi không thể là người duy nhất có hiệu lực "mượn" hệ thống tài khoản của bên thứ ba cho ứng dụng dành cho thiết bị di động với chương trình phụ trợ, nhưng tôi thực sự không thấy cách thích hợp để làm điều này.

Tôi không thấy gì và/hoặc bị sai về mặt khái niệm?

+0

* Dế * Tôi cảm thấy như tôi có thể đã xây dựng câu hỏi này không chính xác. Nếu vậy, xin vui lòng cho tôi biết. Nếu không, tôi sẽ trả lời câu hỏi của riêng tôi ở đây ... cuối cùng. – tempy

Trả lời

10

Một vài đồng nghiệp và tôi đã từng làm một dự án khá giống về bản chất, sau đại học. Chúng tôi đã xác thực người dùng của mình thông qua Facebook hoặc Foursquare, sử dụng API OAuth tương ứng của họ.

Phiên bản Android gốc của ứng dụng đã mở một WebView với trang bắt đầu của nhà cung cấp OAuth, đã chuyển hướng trở lại dịch vụ của chúng tôi sau khi xác thực. Sau đó, dịch vụ của chúng tôi đã gửi yêu cầu mã thông báo OAuth từ nhà cung cấp OAuth (Foursquare có một số pretty simple instructions). Khi chúng tôi nhận được mã thông báo đó, chúng tôi đã thiết lập một phiên sử dụng cookie mà chúng tôi có thể truy cập từ ứng dụng.

Để xác thực phiên, chúng tôi vừa kiểm tra xem mã thông báo truy cập vẫn hợp lệ với nhà cung cấp. Chúng tôi cũng đã sử dụng ID người dùng duy nhất của nhà cung cấp tương ứng để phân biệt người dùng.

Vì vậy, có, những gì đã làm việc cho chúng tôi là: Làm cho ứng dụng xác thực & ủy quyền cho dịch vụ của bạn chứ không phải chính ứng dụng.

+0

Vì vậy, ứng dụng của bạn đã lưu trữ các cookie này và sử dụng chúng để xác thực dịch vụ và bạn sẽ kết hợp cookie với mã thông báo oauth thích hợp trên dịch vụ của mình? Điều đó có khác biệt gì so với việc chỉ tạo ra một guid và đưa nó cho ứng dụng? – tempy

+0

Chính xác, ứng dụng đang sử dụng các cookie được lưu trữ đó (chứa ID được mã hóa, v.v.) để xác thực dịch vụ, sau đó sẽ trao đổi với nhà cung cấp OAuth (để kiểm tra xem mã thông báo vẫn hợp lệ). Bạn cũng có thể sử dụng một số loại GUID, nhưng bạn cần làm cho việc mạo danh ứng dụng đó trở nên khó khăn, ví dụ: có một cái gì đó mà chỉ có máy chủ biết để xác minh chống lại. – Rich

+1

Rất may, ứng dụng không xử lý dữ liệu đặc biệt nhạy cảm trong trường hợp của tôi. Nhưng vẫn còn, cách tiếp cận này có ý nghĩa nhưng có vẻ hơi quá "cuộn của bạn" ish. Đó là một giải pháp, nhưng tôi tự hỏi liệu đây có phải là cách tiếp cận đồng thuận cho vấn đề này hay không. – tempy

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