token的意思是“令牌”，是用戶身份的驗證方式，當用戶第一次登錄後，服務器生成一個token並將此token返回給客戶端，客戶端保存此token，之後請求只需帶上這個token前來請求數據即可，無需再次帶上用戶名和密碼，服務端收到請求，然後去驗證客戶端請求裏面帶着token，如果驗證成功，就向客戶端返回數據。
一、有效期
需要有效期：在登錄中，一般要求定期更改密碼，以防泄漏；安全認證SSL證書有有效期，目的是爲了解決吊銷問題
有效期多長：
①若太短，10s，息屏則要重新輸入密碼，不合理；根據用戶體驗，一般爲1周
②在1周情況下，到期時用戶正在使用，就讓登錄，不合理
方案一：服務端保存token狀態，用戶每次操作就自動刷新時間（類似session）。存在的問題是若前後端分離，一直刷新，時間成本高；若持久化到數據庫中，代價更大。爲了減少消耗，一般放在緩存或內存中。
方案二：Refresh Token，來避免頻繁讀寫。一旦過期，前端使用Refresh Token來申請新Token
二、無狀態
所有狀態信息放在 Token上，服務器可以不保留 Token，但服務器需要驗證 Token有效。
因爲簽發和驗收都是服務器方，所以可以用對稱加密算法。
這樣做引發的問題：若使用無狀態token，還需要記錄在有效期內主動註銷的token，很麻煩，一般不這樣做。
解決方式：前端註銷，就丟掉本地保存的 Token和 Refresh Token。這樣服務器收到的就是一定是沒註銷的。
三、分離認證服務
可見，雖然認證和業務分離了，實際即並沒產生多大的差異。當然，這是建立在認證服務器信任業務服務器的前提下，因爲認證服務器產生 Token 的密鑰和業務服務器認證 Token 的密鑰和算法相同。換句話說，業務服務器同樣可以創建有效的 Token。
四、可以避免 CSRF
CSRF 攻擊原理
你這可以這麼理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發送惡意請求。CSRF能夠做的事情包括：以你名義發送郵件，發消息，盜取你的賬號，甚至於購買商品，虛擬貨幣轉賬…造成的問題包括：個人隱私泄露以及財產安全。
五、防禦CSRF
1.驗證 HTTP Referer 字段
從原理圖我們知道，攻擊的來源是來自第三方網站，如果我們能判斷當前HTTP請求的來源地址，並只允許來自本網站的的請求才能訪問，那麼CSRF攻擊就失效了。根據 HTTP 協議，在 HTTP 頭中有一個字段叫 Referer，它記錄了該 HTTP 請求的來源地址，要防禦 CSRF 攻擊，wan.sogou.com網站只需要對於每一個請求驗證其 Referer 值，如果是以wan.sogou.com 開頭的域名，則說明該請求是來自搜狗遊戲（再來一波廣告）自己的請求，是合法的。如果 Referer 是其他網站的話，則有可能是黑客的 CSRF 攻擊，拒絕該請求。
**優點：**簡單易行，開發人員不需要操心 CSRF 的漏洞，只需要在最後給所有安全敏感的請求統一增加一個攔截器來檢查 Referer 的值就可以，不需要改變當前系統的任何已有代碼和邏輯，沒有風險。
**缺點：**Referer的值是由瀏覽器提供的，相當於安全性都依賴於第三方（即瀏覽器）來保障，實際上某些瀏覽器可以被篡改Referer的值。
2. token
CSRF攻擊之所以能夠成功，是因爲攻擊者可以完全僞造用戶的請求，該請求中所有的用戶驗證信息都存在cookie中，因此攻擊者可以在不知道這些驗證信息的情況下直接利用用戶自己的cookie來通過安全驗證。要防止CSRF，關鍵在於在請求中放入黑客所不能僞造的信息，並且該信息不存在於cookie之中。可以在HTTP請求中以參數的形式加入一個隨機產生的token，並在服務器建立一個攔截器來驗證這個token，如果請求中沒有token或者token不正確，則認爲可能是CSRF攻擊而拒絕該請求。
現在業界一致的做法就是使用Anti CSRF Token來防禦CSRF。
①用戶訪問某個表單頁面。
②服務端生成一個Token，放在用戶的Session中，或者瀏覽器的Cookie中。
③在頁面表單附帶上Token參數。
④用戶提交請求後，服務端驗證表單中的Token是否與用戶Session（或Cookies）中的Token一致，一致爲合法請求，不是則非法請求。
這個Token值必須是隨機的，不可預測的。由於Token的存在，攻擊者無法再構造一個帶有合法Token的請求實施CSRF攻擊。另外使用Token應注意Token的保密性，儘量把敏感操作由GET改成POST，以form或者AJAX形式提交，避免Token泄露。