### token token 也稱作令牌，由uid+time+sign\[+固定參數\] token 的認證方式類似于**臨時的證書簽名**, 并且是一種服務端無狀態的認證方式, 非常適合于 REST API 的場景；所謂無狀態就是服務端并不會保存身份認證相關的數據 token在客戶端一般存放于localStorage，cookie，或sessionStorage中。在服務器一般存于數據庫中 #### 組成 * uid: 用戶唯一身份標識 * time: 當前時間的時間戳 * sign: 簽名, 使用 hash/encrypt 壓縮成定長的十六進制字符串，以防止第三方惡意拼接 * 固定參數(可選): 將一些常用的固定參數加入到 token 中是為了避免重復查庫 ### token認證流程 token 的認證流程與cookie很相似 * 用戶登錄，成功后服務器返回Token給客戶端。 * 客戶端收到數據后保存在客戶端 * 客戶端再次訪問服務器，將token放入headers中 * 服務器端采用filter過濾器校驗。校驗成功則返回請求數據，校驗失敗則返回錯誤碼 ### token優點 * 在Token中包含足夠多的用戶信息，JWT能輕松實現單點登錄，因為用戶的狀態已經被傳送到了客戶端。 * 不存在Cookie跨域的限制問題，也不存在Cookie相關的一些攻擊漏洞，例如CSRF。 * 因為有簽名，所以JWT可以防止被篡改。 * 適用于API的安全機制，適用于移動客戶端與PC客戶端的開發，此時Cookie是不被支持的；Token方案則簡單有效，可以用一套Token認證代碼來應對瀏覽器類客戶端和非瀏覽器類客戶端。 * Token已經標準化，有成熟的標準化規范——JSON Web Token（JWT），多種主流語言也都提供了支持（如.NET、Ruby、Java、Python、PHP）。 ## token可以抵抗csrf，cookie+session不行 假如用戶正在登陸銀行網頁，同時登陸了攻擊者的網頁，并且銀行網頁未對csrf攻擊進行防護。攻擊者就可以在網頁放一個表單，該表單提交src為`http://www.bank.com/api/transfer`，body為`count=1000&to=Tom`。倘若是session+cookie，用戶打開網頁的時候就已經轉給Tom1000元了.因為form 發起的 POST 請求并不受到瀏覽器同源策略的限制，因此可以任意地使用其他域的 Cookie 向其他域發送 POST 請求，形成 CSRF 攻擊。在post請求的瞬間，cookie會被瀏覽器自動添加到請求頭中。但token不同，token是開發者為了防范csrf而特別設計的令牌，瀏覽器不會自動添加到headers里，攻擊者也無法訪問用戶的token，所以提交的表單無法通過服務器過濾，也就無法形成攻擊