作者：Jim Liu
鏈接：https://www.zhihu.com/question/30267006/answer/47525556
token是個憑條，不過它比門票溫柔多了，門票丟了重新花錢買，token丟了重新操作下認證一個就可以了，因此token丟失的代價是可以忍受的——前提是你別丟太頻繁，要是讓用戶隔三差五就認證一次那就損失用戶體驗了。
基于這個出發(fā)點，如果你認為用數(shù)據(jù)庫來保持token查詢時間太長，會成為你系統(tǒng)的瓶頸或者隱患，可以放在內(nèi)存當中。
比如memcached、redis，KV方式很適合你對token查詢的需求。
這個不會太占內(nèi)存，比如你的token是32位字符串，要是你的用戶量在百萬級或者千萬級，那才多少內(nèi)存。
要是數(shù)據(jù)量真的大到單機內(nèi)存扛不住，或者覺得一宕機全丟風險大，只要這個token生成是足夠均勻的，高低位切一下分到不同機器上就行，內(nèi)存絕對不會是問題。
客戶端方面這個除非你有一個非常安全的辦法，比如操作系統(tǒng)提供的隱私數(shù)據(jù)存儲，那token肯定會存在泄露的問題。比如我拿到你的手機，把你的token拷出來，在過期之前就都可以以你的身份在別的地方登錄。
解決這個問題的一個簡單辦法
1、在存儲的時候把token進行對稱加密存儲，用時解開。
2、將請求URL、時間戳、token三者進行合并加鹽簽名，服務(wù)端校驗有效性。
這兩種辦法的出發(fā)點都是：竊取你存儲的數(shù)據(jù)較為容易，而反匯編你的程序hack你的加密解密和簽名算法是比較難的。然而其實說難也不難，所以終究是防君子不防小人的做法。話說加密存儲一個你要是被人扒開客戶端看也不會被噴明文存儲……
方法1它拿到存儲的密文解不開、方法2它不知道你的簽名算法和鹽，兩者可以結(jié)合食用。
但是如果token被人拷走，他自然也能植入到自己的手機里面，那到時候他的手機也可以以你的身份來用著，這你就瞎了。
于是可以提供一個讓用戶可以主動expire一個過去的token類似的機制，在被盜的時候能遠程止損。
<del>話說一個人連自己手機都保護不好還談什么安全……</del>
在網(wǎng)絡(luò)層面上token明文傳輸?shù)脑挄浅５奈ｋU，所以建議一定要使用HTTPS，并且把token放在post body里。
????
