關於APP token驗證的疑問?

01-06

伺服器和APP都是自家應用。我的思路是：APP登錄的時候發送加密的用戶名和密碼到伺服器，伺服器驗證用戶名和密碼，如果成功，以某種方式比如隨機生成32位的字元串作為token，存儲到伺服器中，並返回token到APP，以後APP請求時，凡是需要驗證的地方都要帶上該token，然後伺服器端驗證token，成功返回所需要的結果，失敗返回錯誤信息，讓他重新登錄。其中伺服器上token設置一個有效期，每次APP請求的時候都驗證token和有效期。那麼我的問題來了： 1.伺服器上的token存儲到資料庫中，每次查詢會不會很費時。如果不存儲到資料庫，應該存儲到哪裡呢。 2.客戶端得到的token肯定要加密存儲的，發送token的時候再解密。存儲到資料庫還是配置文件呢？ 3.以上我的思路是否正確呢，請大神們解答下，謝謝

token是個憑條，不過它比門票溫柔多了，門票丟了重新花錢買，token丟了重新操作下認證一個就可以了，因此token丟失的代價是可以忍受的——前提是你別丟太頻繁，要是讓用戶隔三差五就認證一次那就損失用戶體驗了。

基於這個出發點，如果你認為用資料庫來保持token查詢時間太長，會成為你系統的瓶頸或者隱患，可以放在內存當中。

比如memcached、redis，KV方式很適合你對token查詢的需求。

這個不會太占內存，比如你的token是32位字元串，要是你的用戶量在百萬級或者千萬級，那才多少內存。

要是數據量真的大到單機內存扛不住，或者覺得一宕機全丟風險大，只要這個token生成是足夠均勻的，高低位切一下分到不同機器上就行，內存絕對不會是問題。

客戶端方面這個除非你有一個非常安全的辦法，比如操作系統提供的隱私數據存儲，那token肯定會存在泄露的問題。比如我拿到你的手機，把你的token拷出來，在過期之前就都可以以你的身份在別的地方登錄。

解決這個問題的一個簡單辦法

1、在存儲的時候把token進行對稱加密存儲，用時解開。

2、將請求URL、時間戳、token三者進行合併加鹽簽名，服務端校驗有效性。

這兩種辦法的出發點都是：竊取你存儲的數據較為容易，而反彙編你的程序hack你的加密解密和簽名演算法是比較難的。然而其實說難也不難，所以終究是防君子不防小人的做法。話說加密存儲一個你要是被人扒開客戶端看也不會被噴明文存儲……

方法1它拿到存儲的密文解不開、方法2它不知道你的簽名演算法和鹽，兩者可以結合食用。

但是如果token被人拷走，他自然也能植入到自己的手機裡面，那到時候他的手機也可以以你的身份來用著，這你就瞎了。

於是可以提供一個讓用戶可以主動expire一個過去的token類似的機制，在被盜的時候能遠程止損。

&話說一個人連自己手機都保護不好還談什麼安全……&

在網路層面上token明文傳輸的話會非常的危險，所以建議一定要使用HTTPS，並且把token放在post body里。

token是個易失數據，丟了無非讓用戶重新登錄一下，新浪微博動不動就讓我重新登錄，反正這事兒我是無所謂啦。

所以如果你覺得普通的資料庫表撐不住了，可以放到 MSSQL/MySQL 的內存表裡（不過據說mysql的內存表性能提升有限），可以放到 Memcache里（講真，這個是挺常見的策略），可以放到redis里（我做過這樣的實現），甚至可以放到 OpenResty 的變數字典里（只要你有信心不爆內存）。

客戶端么，iOS/OSX可以放到 Key chain 里，別的 OS 不了解。

不多說，直接上Github，裡面有說明：

https://github.com/bigmeow/JWT

如果你覺得查資料庫很費事，那麼每次給用戶簽發token時，直接發送一個對稱加密後的

時間戳+uid+鹽

作為token給數據，用戶拿到這個token回來的時候解密再比對時間戳判斷token是否過期。

好像確實非主流了一點，但是效率和安全本來就是需要權衡的兩端

如果是前後端分離的web站點呢？token存在瀏覽器如何防止被拷走？app的話可以將請求URL、時間戳、token三者進行合併加鹽簽名，web要怎麼杜絕這個問題？

查個token都嫌費時，那還能查什麼？
可逆加密必然會泄漏，完全不考慮。

1. 登錄的時候你加密用戶名密碼沒卵用

2. token存 redis 的做法太常見了

3. token固定就會存在中間人截取重放攻擊

這個認證的問題很多有好的方案求指教

綜合樓下幾位大神的~時間戳+uid+隨機碼生成後丟redis裡面，設置個時間~ thk下

token的有效期是動態更新的嗎，

還是說假如有效期是7天，從第一天登錄開始，我每天都用，到了第八天了，app會提示我token過期嗎？