移動 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模型（安全性更高）