token，就是令牌，最大的特點就是隨機性，不可**。一般黑客或軟體無法猜測出來。
那麼，token有什麼作用？又是什麼原理呢？
token一般用在兩個地方:
兩者在原理上都是通過session token來實現的。當客戶端請求頁面時，伺服器會生成乙個隨機數token，並且將token放置到session當中，然後將token發給客戶端（一般通過構造hidden表單）。下次客戶端提交請求時，token會隨著表單一起提交到伺服器端。
然後，如果應用於「anti csrf攻擊」，則伺服器端會對token值進行驗證，判斷是否和session中的token值相等，若相等，則可以證明請求有效，不是偽造的。
不過，如果應用於「防止表單重複提交」，伺服器端第一次驗證相同過後，會將session中的token值更新下，若使用者重複提交，第二次的驗證判斷將失敗，因為使用者提交的表單中的token沒變，但伺服器端session中token已經改變了。
上面的session應用相對安全，但也叫繁瑣，同時當多頁面多請求時，必須採用多token同時生成的方法，這樣占用更多資源，執行效率會降低。因此，也可用cookie儲存驗證資訊的方法來代替session token。比如，應對「重複提交」時，當第一次提交後便把已經提交的資訊寫到cookie中，當第二次提交時，由於cookie已經有提交記錄，因此第二次提交會失敗。
不過，cookie儲存有個致命弱點，如果cookie被劫持（xss攻擊很容易得到使用者cookie），那麼又一次gameover。黑客將直接實現csrf攻擊。
所以，安全和高效相對的。具體問題具體對待吧。
此外，要避免「加token但不進行校驗」的情況，在session中增加了token，但服務端沒有對token進行驗證，根本起不到防範的作用。
還需注意的是，對資料庫有改動的增刪改操作，需要加token驗證，對於查詢操作，一定不要加token，防止攻擊者通過查詢操作獲取token進行csrf攻擊。但並不是這樣攻擊者就無法獲得token，只是增大攻擊成本而已。
介面安全 Token
token 認證的來龍去脈 前後端分離使用 token 登入解決方案 理解cookie和session機制 基於 cookie session 的認證方案 cookie cookie的工作原理 由於http是一種無狀態的協議，伺服器單從網路連線上無從知道客戶身份。怎麼辦呢？就給客戶端們頒發乙個通行證...
前端安全 關於token
1.將荷載payload，以及header資訊進行base64加密，形成密文payload密文，header密文。2.將形成的密文用句號鏈結起來，用服務端秘鑰進行hs256加密，生成簽名.3.將前面的兩個密文後面用句號鏈結簽名形成最終的token返回給服務端 1.使用者登入校驗，校驗成功後就返回to...
安全的cookie和token機制
單獨使用cookie或者token都是不夠安全的。單獨使用token做驗證 不夠安全，只要xss就會被竊取token，黑客可以隨意執行任何操作。單獨使用cookie做驗證 會遭遇csrf攻擊 正確的策略 使用cookie，並配置httponly，可以防止被js讀取cookie。設定csrftoken...