點擊上方“藍字”帶你去看小星星

菜菜，上次你講的cookie和session認證方式，我這次面試果然遇到了

結果怎么樣？

結果面試官問我還有沒有更好的方式？

看來你又掛了

別說了，傷心呀。到底還有沒有更好的方式呢？

你猜？

基于Token的認證

通過上一篇你大體已經了解session和cookie認證了，session認證需要服務端做大量的工作來保證session信息的一致性以及session的存儲，所以現代的web應用在認證的解決方案上更傾向于客戶端方向，cookie認證是基于客戶端方式的，但是cookie缺點也很明顯，到底有哪些缺點可以跳轉上一次的文章。那有沒有一種比較折中的方案呢？有的

把認證信息保存在客戶端，關鍵點就是安全的驗證，如果能解決認證信息的安全性問題，完全可以把認證信息保存在客戶端，服務端完全無認證狀態，這樣的話服務端擴展起來要方便很多。關于信息的安全解決方案，現在普遍的做法就是簽名機制，像微信公眾接口的驗證方式就基于簽名機制。

簽名，就是只有信息的發送者才能產生的別人無法偽造的一段數字串，這段數字串同時也是對信息的發送者發送信息真實性的一個有效證明。

當用戶成功登陸系統并成功驗證有效之后，服務器會利用某種機制產生一個token字符串，這個token中可以包含很多信息，例如來源IP，過期時間，用戶信息等， 把這個字符串下發給客戶端，客戶端在之后的每次請求中都攜帶著這個token，攜帶方式其實很自由，無論是cookie方式還是其他方式都可以，但是必須和服務端協商一致才可以。當然這里我不推薦cookie。當服務端收到請求，取出token進行驗證（可以驗證來源ip，過期時間等信息），如果合法則允許進行操作。

基于token的驗證方式也是現代互聯網普通使用的認證方式，那它有什么優點嗎？

1. 支持跨域訪問，Cookie是不允許垮域訪問的，這一點對Token機制是不存在的，前提是傳輸的用戶認證信息通過HTTP頭傳輸.

2. 無狀態:Token機制在服務端不需要存儲session信息，因為Token自身包含了所有登錄用戶的信息，只需要在客戶端的cookie或本地介質存儲狀態信息.

3. 解耦 不需要綁定到一個特定的身份驗證方案。Token可以在任何地方生成，只要在你的API被調用的時候，你可以進行Token生成調用即可.

4. 適用性更廣：只要是支持http協議的客戶端，就可以使用token認證。

5. 服務端只需要驗證token的安全，不必再去獲取登錄用戶信息，因為用戶的登錄信息已經在token信息中。

6. 基于標準化:你的API可以采用標準化的 JSON Web Token (JWT). 這個標準已經存在多個后端庫（.NET, Ruby, Java,Python,PHP）和多家公司的支持（如：Firebase,Google, Microsoft）.

那基于token的認證方式有哪些缺點呢？

1. 網絡傳輸的數據量增大：由于token中存儲了大量的用戶和安全相關的信息，所以比單純的cookie信息要大很多，傳輸過程中需要消耗更多流量，占用更多帶寬，

2. 和所有的客戶端認證方式一樣，如果想要在服務端控制token的注銷有難度，而且也很難解決客戶端的劫持問題。

3. 由于token信息在服務端增加了一次驗證數據完整性的操作，所以比session的認證方式增加了cpu的開銷。

但是整體來看，基于token的認證方式還是比session和cookie方式要有很大優勢。在所知的token認證中，jwt是一種優秀的解決方案

jwt

JSON Web Token (JWT)是一個開放標準(RFC 7519)，它定義了一種緊湊的、自包含的方式，用于作為JSON對象在各方之間安全地傳輸信息。該信息可以被驗證和信任，因為它是數字簽名的。

一個JWT實際上就是一個字符串，它由三部分組成，頭部、載荷與簽名。

頭部

header典型的由兩部分組成：token的類型（“JWT”）和算法名稱（比如：HMAC SHA256或者RSA等等）。

{"alg":?"HS256","typ":?"JWT" }

Payload

Payload 部分也是一個JSON對象，用來存放實際需要傳遞的數據。JWT 規定了7個官方字段，供選用。

iss (issuer)：簽發人 exp?(expiration?time)：過期時間 sub?(subject)：主題 aud (audience)：受眾 nbf?(Not?Before)：生效時間 iat (Issued At)：簽發時間 jti (JWT ID)：編號

除了以上字段之外，你完全可以添加自己想要的任何字段，這里還是提醒一下，由于jwt的標準，信息是不加密的，所以一些敏感信息最好不要添加到json里面

{"Name":"菜菜","Age":18 }

Signature

為了得到簽名部分，你必須有編碼過的header、編碼過的payload、一個秘鑰（這個秘鑰只有服務端知道），簽名算法是header中指定的那個，然對它們簽名即可。

HMACSHA256(base64UrlEncode(header)?+?"."?+?base64UrlEncode(payload),?secret)

算出簽名以后，把 Header、Payload、Signature 三個部分拼成一個字符串，每個部分之間用"點"（.）分隔，就可以返回給用戶。需要提醒一下：base64是一種編碼方式，并非加密方式。

寫在最后

基于token的認證方式，大體流程為：

1. 客戶端攜帶用戶的登錄憑證（一般為用戶名密碼）提交請求

2. 服務端收到登錄請求，驗證憑證正確性，如果正確則按照協議規定生成token信息，經過簽名并返回給客戶端

3. 客戶端收到token信息，可以保存在cookie或者其他地方，以后每次請求的時候都攜帶上token信息

4. 業務服務器收到請求，驗證token的正確性，如果正確則進行下一步操作

這里再重復一次，無論是token認證，cookie認證，還是session認證，一旦別人拿到客戶端的標識，還是可以偽造操作。所以采用任何一種認證方式的時候請考慮加入來源ip或者白名單，過期時間，另外有條件的情況下一定要使用https。

完

●程序員過關斬將--cookie和session的關系其實很簡單
●程序員修神之路--用NOSql給高并發系統加速●程序員修神之路--高并發系統設計負載均衡架構●程序員修神之路--做好分庫分表其實很難之一（繼續送書）●程序員修神之路--做好分庫分表其實很難之二（送書繼續）●程序員過關斬將--你為什么還在用存儲過程？●程序員過關斬將--小小的分頁引發的加班血案●程序員修神之路--問世間異步為何物？●程序員修神之路--提高網站的吞吐量?

總結

以上是生活随笔為你收集整理的程序员过关斩将--更加优雅的Token认证方式JWT的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。