2015-11-13 54 views
1

目前我開始拉我的頭髮了這個移動應用程序。我做了一些研究過去的日子裏,似乎我沒有得到相當的點如何實現以下目標:認證具有智威湯遜和刷新令牌

我目前正在建設在Rails的API與移動應用程序客戶端。移動應用程序可以是iOS或Android。現在我正在努力認證。在客戶端登錄設備後,我發出一個短期過期的JWT。所以如果令牌到期,客戶端需要重新登錄,這在我的情況下是不可接受的用戶體驗。無論如何,我覺得我需要有某種期限來防止令牌永久使用,如果它被盜。

現在我不知道如何將刷新令牌整合。我如何確保用戶只有使用已發佈到此確切設備的有效刷新令牌才能獲得新的訪問令牌?還是我過分複雜的事情,並分配一個刷新令牌,可以用於傳輸設備將做的伎倆?

更新:我看了看守門人寶石,它支持密碼授權流程。但門衛處理令牌的方式是,它將每個生成的訪問令牌都存儲在具有相應刷新令牌的數據庫中。當令牌被撤銷或刷新時,舊的訪問令牌會失效 - 隨着時間的推移,這將會變成一個龐大的數據庫表。

此外,我更喜歡使用JWT的道理,所以我沒有存儲任何東西,但在數據庫中刷新令牌。下面的過程是安全的嗎?

  1. 用戶請求使用用戶名/密碼的訪問令牌 - 我們假設一個設備名稱。
  2. 服務器發出JWT併爲當前設備創建一個刷新令牌。
  3. 服務器存儲刷新令牌。
  4. 當訪問令牌過期後,用戶使用它的刷新令牌請求一個新的。
  5. 服務器驗證刷新令牌併發出新的訪問令牌。此外,刷新令牌將被替換爲新的令牌。

我對此的疑問:用戶可以在多個設備上登錄,如何區分它們?

回答

0

我看到這項工作的方式是服務器返回未授權狀態(401),並顯示一條消息,指出訪問令牌已過期,但客戶端恰好有一次機會請求帶有該令牌的新令牌過期的令牌。一旦客戶端使用該過期令牌來申請新令牌,過期令牌就會失效並且不能再使用。這樣你就可以繼續交易舊的代幣換新的代幣。

如果您的過期時間很短,被盜的令牌仍然有效的可能性很小,但從UX的角度來看,用戶將保持登錄狀態,因爲令牌協商可能發生在後臺。用戶的令牌只有在註銷時纔會失效,或者他們正在使用的令牌在服務器端顯式失效。

對於每個用戶名/密碼組合,您都應該擁有一個唯一的令牌。對於應用程序中的每個客戶端擁有相同的標記都是非常不安全的。

+0

其實我不太喜歡只有一個訪問令牌沒有刷新令牌的想法。所以潛在的攻擊者可以用被盜的訪問令牌生成無限的新令牌。此外,我希望儘可能地接近OAuth2規範。 –

0

我喜歡刷新令牌的想法。在後端使用doorkeeper gem怎麼樣?這樣,令牌到期將在每個客戶端請求上得到更新。

用戶使用用戶名/密碼請求訪問令牌,並且讓我們假設一個 設備名稱。

發送用戶名/密碼和設備名稱到您的服務器將失敗客戶端的目的,而不必爲您提供他們的憑據。

我看到它作爲移動客戶端從oauth提供程序請求令牌id(您需要服務器clientID)。移動客戶端將令牌標識發送到您的服務器進行驗證,從而確保客戶身份。服務器可以通過成功的驗證提供JWT中的用戶電子郵件地址。看到導軌google-token-id寶石。

+0

請參閱我更新的問題。我想使用JWT,並且使用門衛+ jwt將最終在數據庫內存儲jwt令牌 - 無論如何,JWT應該是獨立於數據庫的,因此將它們存儲在數據庫中是沒有意義的。 –

0

安全性總是相對的,我們可以通過更多的努力使任何人濫用系統的難度加大。承載令牌是IO綁定(緩存/數據庫調用),JWT令牌是CPU(加密/解密)綁定。這兩種解決方案對於常規服務領域都是足夠好的解決方案,除了我們在這裏介紹移動設備的一件事情。這裏可以使用的方法之一是通過backchannel將令牌/刷新令牌發送到設備,而不是將其作爲驗證的一部分發送給設備。似乎有點額外的工作,但在發佈和刷新移動設備令牌方面提供了更多的安全性。更多細節可以在這裏找到http://sdhankar.com/2016/10/24/authentication-and-jwt-token-refresh-on-mobile-devices/

+0

堆棧溢出具有[關於聯盟披露的政策](http://stackoverflow.com/help/promotion)我知道您的網站與您的用戶名相匹配,但我建議您明確指出您的連接。例如,您可以在鏈接旁邊添加短語「我的網站」。 – RJHunter