9

我意識到這個問題上有很多問題,我一直在研究這個問題幾天。我想確保我的問題儘可能具體,因爲我尚未充分理解最佳方法。Web客戶端和移動REST API安全性的推薦配置

目前我有一個開發的Django站點,與web客戶端通過django活塞json REST API進行大概95%的通信。其他5%是一些重新登錄功能,仍然通過POST表單與CSRF保護。理想情況下,我想將其餘部分移入REST API。

我現在需要找出最佳推薦解決方案,以保護Web客戶端和移動客戶端(應用程序尚待開發)的可重用和快樂共存的方式。我已經閱讀了許多帖子,最終爲移動端推薦了OAuth2(和https),但我仍然對如何設置Web客戶端安全性感到困惑。我也在瞭解OAuth2方面,以及我是否可以使用雙腿形式。就目前來看,Web客戶端是django認證的。從技術上講,jsonp功能在活塞中仍然很活躍,所以我認爲只要他們的Web會話具有auth cookie,任何人都可以使用來自第三方應用程序的api?

總結我的API的用法:

  1. 的API是一個完全私有接口的服務器應用程序
  2. 這將是理想的,如果API無法得到廣泛的第三方網絡重用客戶混搭。
  3. 該數據不是necc敏感。它只是一個社交型網站最個人信息是基本的用戶配置文件的東西像電子郵件,地址等我的問題

摘要:

  1. 的OAuth2是最好的推薦方法保護移動應用程序訪問權限?它與Web客戶端方面有什麼關係?如果推薦使用OAuth2,它是否應該是與應用版本一起版本化的應用範圍內的密鑰?
  2. Web客戶端應該使用通過ajax傳遞的CSRF,並且只需禁用jsonp以確保其始終相同的原點?基本上,我是否分開處理Web客戶端安全?
  3. 我應該如何組織網址/應用程序實例/子域名或建議使用哪種方式來維護網絡與移動安全?我只需要單獨的網址前綴,一個用於使用不同規則的移動設備?

我在尋找django-piston的具體建議來解決這些問題。我已支我的項目,並開始與活塞的這個分叉版本玩:https://bitbucket.org/jespern/django-piston-oauth2

我有一個想法是創建一個活塞的資源,首先檢查它的同源,然後只強制Django的權威性,否則強制oauth2,但我不確定這是否合適。

更新1/1/2012

從尖峯提供的信息,我開始與活塞的oauth2工作。我結束了創建的一個叉子增加對nonrel的Django(MongoDB的)一些修復和我分叉某人的例子也使用的oauth2和活塞:

https://bitbucket.org/justinfx/django-piston-oauth2-nonrel-example

現在,它只是我真的掛鉤這件事的問題到我自己的項目並讓它工作。但是這些測試都很好。

+0

現在_this_是寫得很好的問題!很高興看到有人嘗試。 – Polynomial 2012-01-28 22:15:19

+0

謝謝!我真的不想問一個問題,如果我知道它不是很詳細,並被問到以前相同的方式。我在這裏看到太多的人只是隨便丟下2句話,並要求所有人解決問題:-) – jdi 2012-01-28 22:18:17

回答

4

我都是OAuth2,所以我會根據該解決方案進行回覆。

OAuth2是保護移動應用程序 訪問權限的最佳方法嗎?它與Web客戶端方面有什麼關係?如果推薦使用 OAuth2,它是否應該是應用程序版本爲 版本的應用程序範圍內的密鑰?

是的,OAuth2被廣泛認爲是目前推薦的方法。這比OAuth1容易得多。我建議實際上閱讀the spec,而不是關於規範的博客文章,因爲規範本身非常清晰。除了規範之外,查看其已建立的實現如Facebook'sFoursquare's是有用的,因爲它們不以各種方式遵循規範,而是進行一些修改以使其更加實用和易於使用。

至於版本化版本,從教條REST的角度來看,這是frowned upon。但是,從更實際的角度來看,這是非常普遍的做法,並且使API開發人員和客戶的生活變得更加簡單。我建議閱讀Apigee博客,因爲他們有許多關於versioning等主題的文章。

應該是在阿賈克斯通過Web客戶端使用CSRF,只是 禁用JSONP,以確保其始終同一產地?基本上,我是否分別對待網絡客戶端安全?

如果使用完整的oauth2解決方案,則需要啓用跨站點api請求。要拒絕的應用程序,你不知道,你可以再補充檢查,當你看看正在傳遞的access_tokens下面是一些閱讀不同的選項,你必須:。

http://blog.apigee.com/detail/crossing_the_streams_handling_cross-site_api_requests/

我應該如何去組織網址/應用程序實例/子域名或 什麼建議維護網絡與移動安全嗎?我的 只需要單獨的網址前綴,一個用於移動設備,使用不同的 規則?

只要決定什麼適合你。這些天,很多人在「m.mysite.com」或「mobile.mysite.com」都有他們的移動網站。如果您使用完整的OAuth2實現,此決定與整個身份驗證討論無關。

我在尋找django-piston的具體建議來解決 這些問題。我已支我的項目,並開始打 與活塞的這個叉版本: https://bitbucket.org/jespern/django-piston-oauth2

我不熟悉這個,因爲我用tastypie。如果它不爲你很好地工作,有一個很好的Django的OAuth2獨立的服務器,我用:

https://github.com/hiidef/oauth2app

+0

好的,所以我會努力讓oauth2成爲一切。如果是這樣的話,那麼我關於移動和網絡的單獨url終結點的問題就沒有必要,因爲他們的auth是完全一樣的。我想我的剩餘障礙是得到適合django /活塞的oauth2的解決方案。您的鏈接oauth2app似乎是一個oauth應用程序,而不是necc獨立服務器。所以它會用django-pistin-oauth2叉取代做任何事情。我將不得不看到如何將它與活塞結合起來,因爲我目前無法獲得活塞 - oauth2的工作。我只是希望有一個特定的嘖嘖。 – jdi 2012-01-29 19:12:29

+0

很酷。對不起,我不清楚oauth2app。你是對的,它不是一個獨立的服務器。這是一個django應用程序,它爲您的網站實現oauth2服務器視圖,並且不受任何其他第三方django應用程序束縛。 – Spike 2012-01-29 19:31:47

+0

在接受這個之前,我想稍微等一下,因爲我正在尋找更多活塞的具體信息,但從那時起我就與活塞 - 奧斯特2混淆了。查看我的更新信息! – jdi 2012-02-02 00:05:11