公司的 mobile app 是外包給其他公司做的,所以現(xiàn)在他們需要我們提供 API 接口進(jìn)行調(diào)試,由于沒有 API 開發(fā)的經(jīng)驗,所以現(xiàn)在一個比較難把握的問題就是如何實現(xiàn)服務(wù)器端與移動 APP 端通信時的用戶身份認(rèn)證問題。搜集了一些資料,大部分的建議是在服務(wù)器端生成一個 token 然后在通信報文的 headers 利用這個 token 來進(jìn)行驗證。這里有兩個問題,首先這樣直接生成 token 進(jìn)行認(rèn)證的安全性。其次,生成的 token 應(yīng)該怎么保存呢?存在 DB 里面還是哪個地方?(服務(wù)器端使用的是 php)因為本身產(chǎn)品對安全性要求不是特別高,遠(yuǎn)沒有達(dá)到網(wǎng)銀之類的需求,所以在不考慮使用 oauth 等授權(quán)協(xié)議基礎(chǔ)上,我比較希望知道一些常用的身份驗證機(jī)制,以保證基本的安全性即可。再把問題寫清楚點:1.怎么生成安全性比較高的 token。2.token 需不需要設(shè)置過期時間(考慮到是 mobile app,所以這個比較難設(shè)計,因為很少有人會在 app 上會 log out 再重新登錄)。3.token 除了存在 db 內(nèi),有沒有一些更方便合適的方式。
2 回答

嚕嚕噠
TA貢獻(xiàn)1784條經(jīng)驗 獲得超7個贊
APP里預(yù)埋一個token,結(jié)合時間戳/每次請求的一個隨機(jī)值randstr,生成一個最終signature,在Server進(jìn)行驗證即可,(安全級別不是很高,但防大部分惡意請求沒問題了)。
如果還需要針對不同用戶生成不同的sigature,可以結(jié)合手機(jī)的DeviceId,在首次請求是上報這個,以后的請求就把DeviceId也作為因子帶入sigature的生成里。當(dāng)然,這個過程也不是絕對安全的。
看你的意思是不需要絕對安全的,所以猜測你的目的是防惡意請求的,以上兩種方式應(yīng)該可以滿足了。
- 2 回答
- 0 關(guān)注
- 1633 瀏覽
添加回答
舉報
0/150
提交
取消