基于Token的身份驗證是無狀態(tài)的，我們不將用戶信息存在服務(wù)器或Session中。
相比原始的Cookie+Session方式，更適合分布式系統(tǒng)的用戶認證，繞開了傳統(tǒng)的分布式Session一致性等問題。
基于Token的身份驗證的主流程如下:
用戶通過用戶名和密碼發(fā)送請求；
程序驗證；
程序返回一個簽名的token 給客戶端；
客戶端儲存token,并且每次用于每次發(fā)送請求。
支持跨域跨站點訪問:
Cookie是不允許垮域訪問的，可以通過設(shè)置頂級域名的方式實現(xiàn)部分跨域，但是跨站點的訪問仍然不支持，
如果使用Token機制，就可以通過HTTP頭傳輸用戶認證信息，從而更好的實現(xiàn)跨域跨站點。
無狀態(tài):
Token機制在服務(wù)端不需要存儲session信息，Token自身包含了登錄用戶的信息，只需要在客戶端的cookie或本地介質(zhì)存儲狀態(tài)信息；
去耦:不需要綁定到一個特定的身份驗證方案。Token可以在任何地方生成，只要在你的API被調(diào)用的時候，你可以進行Token生成調(diào)用即可；
更適用于移動應(yīng)用:
當(dāng)客戶端是原生應(yīng)用時，Cookie是不被支持的，雖然目前Webview的方式可以解決Cookie問題，
但是顯然采用Token認證機制會簡單得多；
安全性更強:
因為不再依賴于Cookie，所以你就不需要考慮對CSRF（跨站請求偽造）的防范；
標(biāo)準(zhǔn)化易擴展:
可以采用標(biāo)準(zhǔn)化的 JSON Web Token (JWT)，對以后系統(tǒng)接入Node等純前端開發(fā)更便捷；
相比Session一致性提高性能:
相比服務(wù)端保存Session一致性信息，并查詢用戶登錄狀態(tài)，一般來說Token的驗證過程（包含加密和解密），性能開銷會更小。
JWT 標(biāo)準(zhǔn)的 Token 有三個部分：
header.payload.signature
三個部分中間用點分隔開，并且都使用 Base64 編碼，所以生成的 Token 類似這樣：
ewogICJ0eXAiOiAiSldUIiwKICAiYWxnIjogIkhTMjU2Igp9.ewogImlzcyI6ICJjaGJsb2dzLmNvbSIsCiAiZXhwIjogIjE0NzA3MzAxODIiLAogInVpZCI6ICIxMjM0NWFiY2RlIiwKfQ.9q2eq8sa374ao2uq9607r6qu6
（1）Header報頭
header 部分主要包括兩部分，一個是 Token 的類型，另一個是使用的算法，
比如下面類型就是 JWT，使用的算法是 HS256。
{
"typ": "JWT",
"alg": "HS256"
}
Header內(nèi)容要用 Base64 的形式編碼，所以就變成這樣：
ewogICJ0eXAiOiAiSldUIiwKICAiYWxnIjogIkhTMjU2Igp9
（2）Payload載荷部分
Payload 里面是 Token 的具體內(nèi)容，這部分內(nèi)容可以自定義，JWT有標(biāo)準(zhǔn)字段，也可以添加其它需要的內(nèi)容。
標(biāo)準(zhǔn)字段：
iss：Issuer，發(fā)行者
sub：Subject，主題
aud：Audience，觀眾
exp：Expiration time，過期時間
nbf：Not before
iat：Issued at，發(fā)行時間
jti：JWT ID
這是一個典型的payload信息，包含了發(fā)行者（網(wǎng)站）、過期時間和用戶id：
{
"iss": "chblogs.com",
"exp": "1470730182",
"uid": "12345abcde",
}
這部分內(nèi)容同樣要用Base64 編碼，生成編碼類似如下格式：
ewogImlzcyI6ICJjaGJsb2dzLmNvbSIsCiAiZXhwIjogIjE0NzA3MzAxODIiLAogInVpZCI6ICIxMjM0NWFiY2RlIiwKfQ==
（3）Signature簽名部分
簽名部分主要和token的安全性有關(guān)，Signature的生成依賴前面兩部分。
首先將Base64編碼后的Header和Payload用.連接在一起，
ewogICJ0eXAiOiAiSldUIiwKICAiYWxnIjogIkhTMjU2Igp9.ewogImlzcyI6ICJjaGJsb2dzLmNvbSIsCiAiZXhwIjogIjE0NzA3MzAxODIiLAogInVpZCI6ICIxMjM0NWFiY2RlIiwKfQ
對這個字符串使用HmacSHA256算法進行加密，這個密鑰secret存儲在服務(wù)端，前端不可見，
1 2 3 4 5 6 | String str="ewogICJ0eXAiOiAiSldUIiwKICAiYWxnIjogIkhTMjU2Igp9." + "ewogImlzcyI6ICJjaGJsb2dzLmNvbSIsCiAiZXhwIjogIjE0NzA3MzAxODIiLAogInVpZCI6ICIxMjM0NWFiY2RlIiwKfQ"; byte[] inputData = str.getBytes(); String key = Coder.initMacKey(); BigInteger sha = new BigInteger(Coder.encryptHMAC(inputData, key)); System.out.println("HS256加密后——"+sha.toString(32)); |
下面使用密鑰 THISSHA 進行加密：
9q2eq8sa374ao2uq9607r6qu6
然后將Signature和前面兩部分拼接起來，得到最后的token：
ewogICJ0eXAiOiAiSldUIiwKICAiYWxnIjogIkhTMjU2Igp9.ewogImlzcyI6ICJjaGJsb2dzLmNvbSIsCiAiZXhwIjogIjE0NzA3MzAxODIiLAogInVpZCI6ICIxMjM0NWFiY2RlIiwKfQ.9q2eq8sa374ao2uq9607r6qu6
常規(guī)的token保存在sessionStorage或者localStorage中，每次請求時將token加在http請求的Header中，
下面是典型的token認證方式：
1.客戶端登錄時通過賬號和密碼到服務(wù)端進行認證，認證通過后，服務(wù)端通過持有的密鑰生成Token，Token中一般包含失效時長和用戶唯一標(biāo)識，如用戶ID，服務(wù)端返回Token給客戶端；
2.客戶端保存服務(wù)端返回的Token；
3.客戶端進行業(yè)務(wù)請求時在Head的Authorization字段里面放置Token，如：
Authorization: Bearer Token
4.服務(wù)端對請求的Token進行校驗，如果Token不是存放在Cookie中，需要解決用戶主動注銷，但設(shè)置的過期時間并未過期問題。
用戶注銷時可以把還在失效內(nèi)的Token儲存在Redis等緩存中，驗證時查找Token是否存在，如果Token在Redis中存在，則說明用戶已注銷；如果Token不存在，則校驗通過。
5.服務(wù)端可以通過從Token取得的用戶唯一標(biāo)識進行相關(guān)權(quán)限的校驗，并把此用戶標(biāo)識賦予到請求參數(shù)中，業(yè)務(wù)可通過此用戶標(biāo)識進行業(yè)務(wù)處理；
還有一種方式是把token保存在Cookie中，這時就不需要在服務(wù)端保存token的值，用戶注銷時直接清除Cookie就可以，
這種方式不需要在服務(wù)端儲存token的值，認證過程如下：
CSRF (Cross Site Request Forgery)，指在一個瀏覽器中打開了兩個標(biāo)簽頁，其中一個頁面通過竊取另一個頁面的 cookie 來發(fā)送偽造的請求，因為 cookie 是隨著請求自動發(fā)送到服務(wù)端的。
客戶端不需要持有密鑰，由服務(wù)端通過密鑰生成Token；
在JWT中，不應(yīng)該在Payload里面加入任何敏感的數(shù)據(jù)，如用戶密碼等信息，因為payload并沒有做加密，只是一個Base64的編碼，
攻擊者拿到token以后就可以得到用戶敏感信息；
參考資料：
JSON Web Token - 在Web應(yīng)用間安全地傳遞信息
