token是個憑條，不過它比門票溫柔多了，門票丟了重新花錢買，token丟了重新操作下認證一個就可以了，因此token丟失的代價是可以忍受的——前提是你別丟太頻繁，要是讓使用者隔三差五就認證一次那就損失使用者體驗了。基於這個出發點，如果你認為用資料庫來保持token查詢時間太長，會成為你係統的瓶頸或者隱患，可以放在記憶體當中。比如memcached、redis，KV方式很適合你對token查詢的需求。這個不會太佔記憶體，比如你的token是32位字串，要是你的使用者量在百萬級或者千萬級，那才多少記憶體。要是資料量真的大到單機記憶體扛不住，或者覺得一宕機全丟風險大，只要這個token生成是足夠均勻的，高低位切一下分到不同機器上就行，記憶體絕對不會是問題。客戶端方面這個除非你有一個非常安全的辦法，比如作業系統提供的隱私資料儲存，那token肯定會存在洩露的問題。比如我拿到你的手機，把你的token拷出來，在過期之前就都可以以你的身份在別的地方登入。解決這個問題的一個簡單辦法1、在儲存的時候把token進行對稱加密儲存，用時解開。2、將請求URL、時間戳、token三者進行合併加鹽簽名，服務端校驗有效性。這兩種辦法的出發點都是：竊取你儲存的資料較為容易，而反彙編你的程式hack你的加密解密和簽名演算法是比較難的。然而其實說難也不難，所以終究是防君子不防小人的做法。話說加密儲存一個你要是被人扒開客戶端看也不會被噴明文儲存……方法1它拿到儲存的密文解不開、方法2它不知道你的簽名演算法和鹽，兩者可以結合食用。但是如果token被人拷走，他自然也能植入到自己的手機裡面，那到時候他的手機也可以以你的身份來用著，這你就瞎了。於是可以提供一個讓使用者可以主動expire一個過去的token類似的機制，在被盜的時候能遠端止損。<del>話說一個人連自己手機都保護不好還談什麼安全……</del>在網路層面上token明文傳輸的話會非常的危險，所以建議一定要使用HTTPS，並且把token放在post body裡。
token是個憑條，不過它比門票溫柔多了，門票丟了重新花錢買，token丟了重新操作下認證一個就可以了，因此token丟失的代價是可以忍受的——前提是你別丟太頻繁，要是讓使用者隔三差五就認證一次那就損失使用者體驗了。基於這個出發點，如果你認為用資料庫來保持token查詢時間太長，會成為你係統的瓶頸或者隱患，可以放在記憶體當中。比如memcached、redis，KV方式很適合你對token查詢的需求。這個不會太佔記憶體，比如你的token是32位字串，要是你的使用者量在百萬級或者千萬級，那才多少記憶體。要是資料量真的大到單機記憶體扛不住，或者覺得一宕機全丟風險大，只要這個token生成是足夠均勻的，高低位切一下分到不同機器上就行，記憶體絕對不會是問題。客戶端方面這個除非你有一個非常安全的辦法，比如作業系統提供的隱私資料儲存，那token肯定會存在洩露的問題。比如我拿到你的手機，把你的token拷出來，在過期之前就都可以以你的身份在別的地方登入。解決這個問題的一個簡單辦法1、在儲存的時候把token進行對稱加密儲存，用時解開。2、將請求URL、時間戳、token三者進行合併加鹽簽名，服務端校驗有效性。這兩種辦法的出發點都是：竊取你儲存的資料較為容易，而反彙編你的程式hack你的加密解密和簽名演算法是比較難的。然而其實說難也不難，所以終究是防君子不防小人的做法。話說加密儲存一個你要是被人扒開客戶端看也不會被噴明文儲存……方法1它拿到儲存的密文解不開、方法2它不知道你的簽名演算法和鹽，兩者可以結合食用。但是如果token被人拷走，他自然也能植入到自己的手機裡面，那到時候他的手機也可以以你的身份來用著，這你就瞎了。於是可以提供一個讓使用者可以主動expire一個過去的token類似的機制，在被盜的時候能遠端止損。<del>話說一個人連自己手機都保護不好還談什麼安全……</del>在網路層面上token明文傳輸的話會非常的危險，所以建議一定要使用HTTPS，並且把token放在post body裡。