2016-11-28 85 views
1

此問題與原生移動應用程序中基於OAuth的登錄有關。根據授權授予類型流程,用戶在登錄頁面輸入用戶名和密碼,作爲響應,在URL中獲得授權碼(因爲其URL,基於https的加密也不會起作用)。與OAuth流相關的安全問題

這意味着授權代碼在代理中可用,並且任何人都可以使用它,前提是他們也有客戶端密碼。由於移動應用程序不被認爲是安全的,所以客戶端祕密不能被存儲在移動應用程序中。我想到的用於規避客戶端祕密安全的方法是提供服務器端點,移動客戶端可以在其中調用客戶端ID,授權碼和重定向網址。端點將豐富客戶端祕密,然後調用實際的令牌端點來獲取訪問權限。由於整個通信都是通過HTTPS進行的,因此accesstoken受到保護。

現在的問題是 - URL參數中的授權代碼不安全且易受攻擊。或者我是否過度瞭解安全。這是主要問題,如果這確實是一個安全問題,那麼採取的緩解措施是什麼?

我可以想到的一個選擇,從一個較舊的stackoverflow線程是安全的令牌端點,將從服務器端提供訪問令牌。任何有關如何做到這一點的建議? - 如果它的證書,然後證書將打包在移動應用程序,使其不安全再次)

回答

2

無恥的插件...但自從我通讀完整的規格,並做了一些離線討論,我想提供我的看法一樣的。

a。客戶端和authroization服務器之間的TLS - 當授權提供者內的少量重定向完成完整身份驗證時,授權提供者會將位置標頭設置爲重定向URI以及位置標頭中查詢參數中的授權碼。由於授權代碼位於位置標題內,並且響應標頭仍受TLS保護,因此竊聽不會暴露授權代碼。

b。如果客戶端是移動應用程序 - 重定向URI應指向自定義URI方案,該方案將指向移動應用程序本身。因此,當瀏覽器根據位置標題執行重定向時,瀏覽器將調用移動應用程序。該呼叫不會從設備中消失,因此授權碼不會暴露給外部世界。

c。如果客戶端是一個Web應用程序 - redirect uri將通過瀏覽器執行,並且授權代碼將暴露在代理日誌中(https卸載後)和瀏覽器緩存中,或者如果存在重定向,它將很容易代碼的泄漏。授權碼的保護有兩種方式 - a。授權碼可以設置爲使用期限,可以很小。灣授權碼只能使用一次。因此,如果實際的客戶端已經使用它,則沒有人可以重新使用授權碼來再次獲取訪問令牌。 d)。基於Kris在下面的評論中提到的觀點,該規範定義了一種保護濫用授權代碼的方法。如果代碼被多次使用,授權服務器可以撤銷使用授權代碼創建的所有訪問令牌。

+0

d。從[規範](https://tools.ietf.org/html/rfc6749#section-3.1.2.1):當請求的響應類型是「code」時,重定向端點應該按照第1.6節中的描述使用TLS。或「令牌」,或者重定向請求會導致通過開放網絡傳輸敏感憑據。 –

+0

@Kris - 同意重定向端點正在使用TLS,但授權碼是HTTP查詢參數的一部分,該參數不能由TLS保護。 – Vaya

+0

這取決於你的意思是「受保護」。當然,它可能會被您的Web服務器記錄下來,如果終止TLS,可能還會通過代理進行記錄。但是網絡上的竊聽者看不到它。 –