Token：服務端身份驗證的流行方案
01-
身份認證
服務端提供資源給客戶端，但是某些資源是有條件的。所以服務端要能夠識別請求者的身份，然後再判斷所請求的資源是否可以給請求者。
token是一種身份驗證的機制，初始時用戶提交賬號數據給服務端，服務端采用一定的策略生成一個字符串（token），token字符串中包含了少量的用戶信息，並且有一定的期限。服務端會把token字符串傳給客戶端，客戶端保存token字符串，並在接下來的請求中帶上這個字符串。
它的工作流程大概是這樣：
組件圖
Token機制
在這樣的流程下，我們需要考慮下面幾個問題：
-
服務端如何根據token獲取用戶的信息？
-
如何確保識別偽造的token？
這裏是指token不是經過服務端來生成的。
-
如何應付冒充的情況？
非法客戶端攔截了合法客戶端的token，然後使用這個token向服務端發送請求，冒充合法客戶端。
用戶匹配
服務端在生成token時，加入少量的用戶信息，比如用戶的id。服務端接收到token之後，可以解析出這些數據，從而將token和用戶關聯了起來。
防偽造
一般情況下，建議放入token的數據是不敏感的數據，這樣只要服務端使用私鑰對數據生成簽名，然後和數據拼接起來，作為token的一部分即可。比如JWT，參考JSON Web Token - 在Web應用間安全地傳遞信息。
在我知道JWT之前，我先了解的是另一種模式。基於加密的算法，對數據進行加密，把加密的結果作為token（http://blog.leapoahead.com/2015/09/06/understanding-jwt/）。
本文主要討論後一種模式。
防冒充
加幹擾碼
服務端在生成token時，使用了客戶端的UA作為幹擾碼對數據加密，客戶端進行請求時，會同時傳入token、UA，服務端使用UA對token解密，從而驗證用戶的身份。
如果只是把token拷貝到另一個客戶端使用，不同的UA會導致在服務端解析token失敗，從而實現了一定程度的防冒充。但是攻擊者如果猜到服務端使用UA作為加密鑰，他可以修改自己的UA。
有效期
給token加上有效期，即使被冒充也只是在一定的時間段內有效。這不是完美的防禦措施，只是盡量減少損失。
服務端在生成token時，加入有效期。每次服務端接收到請求，解析token之後，判斷是否已過期，如果過期就拒絕服務。
token刷新
如果token過期了，客戶端應該對token續期或者重新生成token。這取決於token的過期機制。
-
服務器緩存token及對應的過期時間
這個時候就可以采用續期的方式，服務器更新過期時間，token再次有效。
-
token中含有過期時間
這個時候需要重新生成token。
在token續期或者重新生成token的時候，需要額外加入數據來驗證身份。因為token已經過期了，即token已經不能用來驗證用戶的身份了。這個時候可以請求用戶重新輸入賬號和密碼，但是用戶體驗稍差。
另一種方式是使用摘要。服務端生成token，同時生成token的摘要，然後一起返回給客戶端。客戶端保存摘要，一般請求只需要用到token，在刷新token時，才需要用到摘要。服務端驗證摘要，來驗證用戶的身份。因為摘要不會頻繁的在客戶端和服務端之間傳輸，所以被截取的概率較小。
02-
Token工作流程
生成token
生成token
一般在登錄的時候生成token。Token管理者負責根據用戶的數據生成token和摘要，摘要用來給APP端刷新token用，類似於微信登錄中的refresh_token。
生成token的過程中，ua的充作幹擾碼。沒有相同的ua，就無法解析生成的token字符串。如果客戶端是混合開發的模式，生成token和使用token的代理可能不同（比如一個是h5，一個是原生），ua就會不同，token就無法成功的使用。可以選擇其他的客戶端數據作為幹擾碼，註意考慮下面的問題：
-
不同的客戶端，幹擾碼應該不同
幹擾碼的很大一個作用是防冒充，如果選擇的充當幹擾碼的客戶端數據沒有區分性，就達不到效果。
-
選擇充當幹擾碼的數據，在哪些情況下會變化？這些情況是否合理？
比如幹擾碼數據中含有app的版本號，那麽app版本升級就會導致幹擾碼變化。服務端根據新的幹擾碼，無法解析舊的token，此時用戶必須重新登錄。這種情況是合理的嗎？如果不合理，幹擾碼中就不應該含有app的版本號。
攔截驗證
攔截驗證
客戶端的每一次請求，都必須攜帶token、ua，攔截器會對敏感資源的訪問進行攔截，然後根據ua解析token，解析不成功，表示token和ua不匹配。解析成功之後，判斷token是否已過期，如果是，拒絕服務。所有都ok的情況下，攔截器放行，請求傳達到業務服務者。
token刷新
token刷新
當token過期，用戶需要刷新token。刷新token本質上是這樣的：
服務端：這個token是你的嗎？
客戶端：是的。
服務端：當初我給你token的時候，還給了一個摘要，你把摘要拿過來證明。
客戶端需要把token、摘要、ua都傳給服務端，服務端對token重新生成摘要，通過判斷兩個摘要是否相同來驗證這次請求刷新token的客戶端，是不是上次請求生成token的客戶端。驗證通過，服務端需要使用用戶數據重新生成token，用戶數據則來自用ua解析token的結果。
? ? ? ? ? ? ? ?
作者：守正
Token：服務端身份驗證的流行方案