?2016-2026 Matools All rights reserved,
粵ICP備17059708號
菜菜，上次你講的cookie和session認證方式，我這次面試果然遇到了
結(jié)果怎么樣？
結(jié)果面試官問我還有沒有更好的方式？
看來你又掛了
別說了，傷心呀。到底還有沒有更好的方式呢？
你猜？
基于Token的認證
通過上一篇你大體已經(jīng)了解session和cookie認證了，session認證需要服務端做大量的工作來保證session信息的一致性以及session的存儲，所以現(xiàn)代的web應用在認證的解決方案上更傾向于客戶端方向，cookie認證是基于客戶端方式的，但是cookie缺點也很明顯，到底有哪些缺點可以跳轉(zhuǎn)上一次的文章。那有沒有一種比較折中的方案呢？有的
把認證信息保存在客戶端，關(guān)鍵點就是安全的驗證，如果能解決認證信息的安全性問題，完全可以把認證信息保存在客戶端，服務端完全無認證狀態(tài)，這樣的話服務端擴展起來要方便很多。關(guān)于信息的安全解決方案，現(xiàn)在普遍的做法就是簽名機制，像微信公眾接口的驗證方式就基于簽名機制。
簽名，就是只有信息的發(fā)送者才能產(chǎn)生的別人無法偽造的一段數(shù)字串，這段數(shù)字串同時也是對信息的發(fā)送者發(fā)送信息真實性的一個有效證明。
當用戶成功登陸系統(tǒng)并成功驗證有效之后，服務器會利用某種機制產(chǎn)生一個token字符串，這個token中可以包含很多信息，例如來源IP，過期時間，用戶信息等，
把這個字符串下發(fā)給客戶端，客戶端在之后的每次請求中都攜帶著這個token，攜帶方式其實很自由，無論是cookie方式還是其他方式都可以，但是必須和服務端協(xié)商一致才可以。當然這里我不推薦cookie。當服務端收到請求，取出token進行驗證（可以驗證來源ip，過期時間等信息），如果合法則允許進行操作。
基于token的驗證方式也是現(xiàn)代互聯(lián)網(wǎng)普通使用的認證方式，那它有什么優(yōu)點嗎？
1. 支持跨域訪問，Cookie是不允許垮域訪問的，這一點對Token機制是不存在的，前提是傳輸?shù)挠脩粽J證信息通過HTTP頭傳輸.
2.
無狀態(tài):Token機制在服務端不需要存儲session信息，因為Token自身包含了所有登錄用戶的信息，只需要在客戶端的cookie或本地介質(zhì)存儲狀態(tài)信息.
3. 解耦 不需要綁定到一個特定的身份驗證方案。Token可以在任何地方生成，只要在你的API被調(diào)用的時候，你可以進行Token生成調(diào)用即可.
4. 適用性更廣：只要是支持http協(xié)議的客戶端，就可以使用token認證。
5. 服務端只需要驗證token的安全，不必再去獲取登錄用戶信息，因為用戶的登錄信息已經(jīng)在token信息中。
6. 基于標準化:你的API可以采用標準化的 JSON Web Token (JWT). 這個標準已經(jīng)存在多個后端庫（.NET, Ruby,
Java,Python,PHP）和多家公司的支持（如：Firebase,Google, Microsoft）.
那基于token的認證方式有哪些缺點呢？
1. 網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量增大：由于token中存儲了大量的用戶和安全相關(guān)的信息，所以比單純的cookie信息要大很多，傳輸過程中需要消耗更多流量，占用更多帶寬，
2. 和所有的客戶端認證方式一樣，如果想要在服務端控制token的注銷有難度，而且也很難解決客戶端的劫持問題。
3. 由于token信息在服務端增加了一次驗證數(shù)據(jù)完整性的操作，所以比session的認證方式增加了cpu的開銷。
但是整體來看，基于token的認證方式還是比session和cookie方式要有很大優(yōu)勢。在所知的token認證中，jwt是一種優(yōu)秀的解決方案
jwt
JSON Web Token (JWT)是一個開放標準(RFC
7519)，它定義了一種緊湊的、自包含的方式，用于作為JSON對象在各方之間安全地傳輸信息。該信息可以被驗證和信任，因為它是數(shù)字簽名的。
一個JWT實際上就是一個字符串，它由三部分組成，頭部、載荷與簽名。
頭部
header典型的由兩部分組成：token的類型（“JWT”）和算法名稱（比如：HMAC SHA256或者RSA等等）。
{
??"alg":?"HS256",
??"typ":?"JWT"
}
Payload
Payload 部分也是一個JSON對象，用來存放實際需要傳遞的數(shù)據(jù)。JWT 規(guī)定了7個官方字段，供選用。
iss?(issuer)：簽發(fā)人
exp?(expiration?time)：過期時間
sub?(subject)：主題
aud?(audience)：受眾
nbf?(Not?Before)：生效時間
iat?(Issued?At)：簽發(fā)時間
jti?(JWT?ID)：編號
除了以上字段之外，你完全可以添加自己想要的任何字段，這里還是提醒一下，由于jwt的標準，信息是不加密的，所以一些敏感信息最好不要添加到j(luò)son里面
{
????"Name":"菜菜",
????"Age":18
}
Signature
為了得到簽名部分，你必須有編碼過的header、編碼過的payload、一個秘鑰（這個秘鑰只有服務端知道），簽名算法是header中指定的那個，然對它們簽名即可。
HMACSHA256(base64UrlEncode(header)?+?"."?+?base64UrlEncode(payload),?secret)
算出簽名以后，把 Header、Payload、Signature
三個部分拼成一個字符串，每個部分之間用"點"（.）分隔，就可以返回給用戶。需要提醒一下：base64是一種編碼方式，并非加密方式。
寫在最后
基于token的認證方式，大體流程為：
1. 客戶端攜帶用戶的登錄憑證（一般為用戶名密碼）提交請求
2. 服務端收到登錄請求，驗證憑證正確性，如果正確則按照協(xié)議規(guī)定生成token信息，經(jīng)過簽名并返回給客戶端
3. 客戶端收到token信息，可以保存在cookie或者其他地方，以后每次請求的時候都攜帶上token信息
4. 業(yè)務服務器收到請求，驗證token的正確性，如果正確則進行下一步操作
這里再重復一次，無論是token認證，cookie認證，還是session認證，一旦別人拿到客戶端的標識，還是可以偽造操作。所以采用任何一種認證方式的時候請考慮加入來源ip或者白名單，過期時間，另外有條件的情況下一定要使用https。
?
熱門工具 換一換