將oauth2與本機（iOS/Android）移動應用程序集成

我需要將OAuth2集成到iOS和Android本機應用程序中。我一直在研究OAuth2和移動應用程序，並發現此文檔 - Google APIs - Using OAuth 2.0 for Installed Applications 將oauth2與本機（iOS/Android）移動應用程序集成

上述文檔主要介紹瞭如何在移動應用程序中使用Goolge OAuth 2.0端點。

這裏的文件說什麼 -

在註冊應用程序時，你指定應用程序是一個已安裝的應用。這會導致redirect_uri參數的值不同。

在註冊過程中獲得的client_id和client_secret嵌入到應用程序的源代碼中。在這種情況下，client_secret顯然不被視爲祕密。

授權碼可以在瀏覽器的標題欄或查詢字符串中的http://localhost端口返回到您的應用程序。

假設用戶在智能手機上安裝了2個應用程序。

應用1 - 合法的應用程序消耗谷歌OAuth2.0的端點

應用2 - 惡意應用

真的什麼我不能肯定是否是集成/耗費了本地移動中的OAuth2.0端點的上述技術應用程序是不安全的或我錯過了什麼。這裏是我的問題 -

的REDIRECT_URI可以是http://localhost網址，並且可以包含任何端口號。端口號不是初始API配置的一部分，因此它可以是任何有效的端口號。此外，client_id（不應該是一個祕密）和client_secret並不是真正的祕密，因爲它們嵌入在移動應用程序源代碼中。

使用上述條件，沒有下面的可能性 -

用戶啓動App2的
App2的用戶對谷歌的OAuth2.0端點重定向然而，在請求時，應用2包括客戶端ID爲App1幷包含App2正在偵聽的本地端口號。
當用戶被重定向並向Google OAuth2.0終端進行身份驗證時，Google會向用戶表明「App1（合法應用）要求代表用戶訪問Google API /數據」，這似乎是一種網絡釣魚因爲用戶可能會點擊「是」，認爲它是要求訪問的App1。
Google OAuth2.0隨後會向App2發出授權代碼，然後App2可以發出下一個請求，包括App1的client_id和client_secret，並獲取access_token和refresh_token，並繼續訪問Google的用戶數據。

的REDIRECT_URI也可能是 - 甕：IETF：WG：OAuth的：2.0：OOB這意味着 -

此值信號給谷歌授權服務器的授權碼應該在瀏覽器的標題欄中返回。如果客戶端無法在沒有重要客戶端配置的情況下偵聽HTTP端口，這很有用。 Windows應用程序具有此特性。

當使用此值時，您的應用程序可以感測到頁面已加載並且HTML頁面的標題包含授權代碼。然後，如果您想確保用戶永遠不會看到包含授權碼的頁面，則可以由您的應用程序關閉瀏覽器窗口。這種做法的機制因平臺而異。

以上意味着授權碼返回瀏覽器窗口的標題中。

我的問題是 - App2是否也可以感覺到頁面已經加載並捕獲授權代碼，然後在App_I和Client_secret之前使用它（以獲取access_token和refresh_token）。瀏覽器實例是否全局，並且任何應用程序都可以監視它，並且上述攻擊方案是有效的，或者瀏覽器實例是某種程度上與應用程序相關的，這樣只有App1可以檢測/監視這些更改？

我的理解是正確的還是我錯過了什麼？我是否錯過了緩解上述威脅的緩解措施？或者鑑於我們在移動操作系統平臺上，上述風險是否有效但被接受？

在移動應用程序中使用OAuth2.0的安全方式是什麼？ - 在瀏覽器頁面顯示授權碼，讓用戶在應用程序中手動輸入授權碼？在這種情況下，瀏覽器實例是私有的，以便其他應用程序無法監視它並在用戶將其輸入合法的應用程序之前獲取授權代碼本身？

任何幫助表示讚賞

感謝和問候，

來源

2013-04-24 user967973

我可以問你爲什麼假設app2可以訪問app1的client_secret？如果沒有client_secret，app2無法對授權碼進行任何操作。我不是說它不可能，但我不認爲它是微不足道的。 – anfab 2013-07-31 16:40:44

@anfab - 我在想有人下載應用程序的可能性。二進制和反編譯或打印應用程序中的硬編碼字符串。以揭示客戶端的祕密... – user967973 2013-08-07 21:07:12

從我的經驗，我發現有一些真正支持在乾淨的方式獲取授權碼很少庫。

在大多數移動平臺，你可以「聽」到重定向URL（即http或一些定製方案）

例如在Android上可以很容易地創建一個活動來獲取一個訪問令牌（基於授權碼是通過重定向URL接收。

<activity android:name=".OAuthAccessTokenActivity" android:launchMode="singleTask">> 
     <intent-filter> 
      <action android:name="android.intent.action.VIEW" /> 
      <category android:name="android.intent.category.DEFAULT" /> 
      <category android:name="android.intent.category.BROWSABLE" /> 
      <data android:scheme="http" android:host="localhost" /> 
     </intent-filter> 
    </activity>

在這種情況下

http://localhost

在Android這樣的移動平臺上，這似乎是邏輯THI可以做。

在iOS上也可以做到這一點，但如果我沒有記錯的話，iOS的Google OAuth庫使用頁面標題方法。

從技術上講，2個流程沒有區別。唯一的區別是重定向URL的語法，導致授權代碼的位置不同。

從安全的角度來看，如果沒有OAuth2客戶端的祕密，授權代碼本身就毫無價值。

讓用戶輸入授權碼是我不習慣在Oauth2流程中看到的東西，但它是可能的。如果懷疑它會增加任何安全方面的東西。恕我直言，它只會挫敗用戶。

這並不意味着有檢索和處理授權碼

來源

2013-08-07 11:16:24 ddewaele

客戶端的祕密雖然不是一個真正的祕密（如谷歌文件指出），因爲有人可以反編譯應用程序，並獲得相同的知識... – user967973 2013-08-07 21:05:07

我問了一個類似的問題有關客戶端機密在移動應用程序的方式回來（http://stackoverflow.com/questions/4419915/how-to-keep-the-oauth-consumer-secret-safe-and-how-to-react-when-its-compromis）。人們必須假定獲得客戶機密碼是一回事，但是另一件事是模擬你的應用程序並使用該客戶機密碼誘騙用戶認爲你的應用程序要求再次訪問他的數據。但我同意將它保留在您的應用程序中並非100％緊張。代理網絡服務器是另一個層面的間接方式，但仍然不是100％緊張。 – ddewaele 2013-08-07 23:10:33

不直接回答這個（通過與本地主機或自定義的URI方案，或手動輸送重定向代碼的自動捕獲）的方式不同問題，但對於像我這樣來到這裏的人，並得到過時的答覆。最好從這裏開始：Google have published他們的OAuth Java庫和Scribe是Java準備好的。

來源

2015-03-25 14:45:45

將oauth2與本機（iOS/Android）移動應用程序集成

回答

相關問題