移動 APP 端與服務器端用戶身份認證的安全方案

最近要做一個項目是java開發后端服務，然后移動APP調用。由於之前沒有接觸過這塊，所以在網上搜索相關的方案。然后搜到下面的一些方案做一些參考。

 

原文：移動 APP 端與服務器端用戶身份認證的安全方案

公司的 mobile app 是外包給其他公司做的，所以現在他們需要我們提供 API 接口進行調試，由於沒有 API 開發的經驗，所以現在一個比較難把握的問題就是如何實現服務器端與移動 APP 端通信時的用戶身份認證問題。
搜集了一些資料，大部分的建議是在服務器端生成一個 token 然后在通信報文的 headers 利用這個 token 來進行驗證。
這里有兩個問題，首先這樣直接生成 token 進行認證的安全性。其次，生成的 token 應該怎么保存呢？存在 DB 里面還是哪個地方？(服務器端使用的是 php)

因為本身產品對安全性要求不是特別高，遠沒有達到網銀之類的需求，所以在不考慮使用 oauth 等授權協議基礎上，我比較希望知道一些常用的身份驗證機制，以保證基本的安全性即可。

再把問題寫清楚點：
1.怎么生成安全性比較高的 token。
2.token 需不需要設置過期時間（考慮到是 mobile app，所以這個比較難設計，因為很少
有人會在 app 上會 log out 再重新登錄）。
3.token 除了存在 db 內，有沒有一些更方便合適的方式。

 

 

默認排序 時間排序

6 個回答

 

采納

peixinchen 111  2014年04月29日 回答

1. APP里預埋一個token，結合時間戳/每次請求的一個隨機值randstr，生成一個最終signature，在Server進行驗證即可，（安全級別不是很高，但防大部分惡意請求沒問題了）。
2. 如果還需要針對不同用戶生成不同的sigature，可以結合手機的DeviceId，在首次請求是上報這個，以后的請求就把DeviceId也作為因子帶入sigature的生成里。當然，這個過程也不是絕對安全的。

看你的意思是不需要絕對安全的，所以猜測你的目的是防惡意請求的，以上兩種方式應該可以滿足了。

 

wenhx 131  2014年04月29日 回答

告訴你一個很好的學習方式，去各大網站，微博、騰訊、Facebook、Google，看他們的OpenApi是怎么實現的，需要提供什么樣的參數，你就可以依葫蘆畫瓢做出來了。

 

 

遠方的落日 63  2014年04月29日 回答

1. token一般可以用用戶名和密碼處理后生成。
2. token過期可做可不做，如果移動端發現token過期則跳到登錄界面讓用戶重新登錄即可。
3. 你是指客戶端存token的地點還是服務器端？一般都可以存在數據庫中，不過對移動設備來說存在XML中作為鍵值對更為普遍。

 

 

 

 

_404_MrYes 103  2014年05月07日 回答 · 2014年05月08日 更新

首先回答第三個問題：存在rdb不妥，本來保存的就是臨時數據，沒有持久化的必要，用緩存即可，memcached/redis均可。

為何說是臨時數據，token本來是用來做授權的，應當只能允許可信用戶使用，假如是長久數據，那么一旦token泄露，就難免會造成偽造訪問的風險。

不知道提主的應用是用什么做用戶認證，假定是傳統的用戶名密碼認證方式，其實可以參考http的session，認證通過后生成的sessionid信息其實就可以作為后續訪問的token。用戶每次請求是攜帶uid+sid信息來即可，通過sid反查uid或者uid查詢sid，然后匹配即可。在token超時時讓用戶重新來申請即可。對於移動端，建議走https通道。

如何生成安全性高的token，常規的簽名算法就可以了，畢竟是不可逆的，原串組合方式不泄露就行，md5的話記得加鹽。

對於在app中內置token的做法不建議。首先，內置的token所有應用統一呢？這樣獲取到了token，基本就可以偽造了，不同的設備不同呢？其實也差不多。而且這樣實現起來也比較負責，因為server端要進行驗證，猜測應當是用對稱加密算法，簽名驗證？其實最大的疑問是真能用來授權么？我看題主提到了多賬戶的問題，那么設備與用戶就不是一一對應的關系。

 

 

 

web_focus 86  2014年04月30日 回答

最簡單用session，業務層上不用做太大的變動，呵呵。

 

小熊油耗 30  4月3日 回答

應該采用 OAuth 2.0 Client Credentials Grant（最容易），或者 JSON Web Token模型（安全性更高）