【轉自】https://stayhungrystayfoolish.github.io/Token/
基本概念了解
狀態
請求的狀態是 瀏覽器（Client） 與 服務端（Server） 交互過程中，保存下來的相關信息，客戶端的保存在 page/request/session/application 或者全局作用域中，而 Server 的一般存在 Session 中。
有狀態 API
服務端（Server）保存了 瀏覽器（Client） 的請求狀態，Server 通過 Client 傳遞的 sessionID 在其 Session 作用域內找到之前交互的信息并應答。
無狀態 API
無狀態是 RESTFul 架構設計的一個非常主要的原則。
每一個請求都是獨立的，它要求由 瀏覽器 保存所有需要的認證信息，每次發請求都要帶上自己的狀態，以 URL 的形式提交包含了 Cookies 等狀態的數據。
關鍵詞解讀
Token
在計算機領域，Token 通常指的是一種令牌，用于身份安全認證。
最簡單的 Token 組成：uid（用戶唯一的身份標識）、time（當前時間的時間戳）、sign（簽名，由 Token 的前幾位 + 鹽以哈希算法壓縮成一定長的十六進制字符串，可以防止惡意第三方拼接token請求服務器）。
Cookie
Cookie 通過在瀏覽器記錄信息確定用戶身份，存儲在瀏覽器
一種在瀏覽器記錄用戶信息的技術，由服務器發送給瀏覽器并保存相關信息（超過4kb 不可讀）。因為 Http 協議是無狀態的，為了解決這個問題而產生了 Cookie 。
Cookie的組成有：名稱（Key）、值（Value）、有效域（Domain）、路徑（域的路徑，一般設置為全局:”\”）、失效時間（Expires）、安全標志（指定后，cookie只有在使用SSL連接時才發送到服務器（Https））。
Session
Session 通過在服務器記錄信息確定用戶身份，存儲在文件、數據庫或內存之中
一種服務器與瀏覽器的會話機制，瀏覽器發送一個請求到服務器，服務器記錄當前用戶信息，產生一個 session id，用來在服務器端共享數據。
Session 的生命周期一般自己設置，當超過設置的有效時間，該會話狀態關閉。
傳統身份認證與基于 Token 的認證
傳統身份認證
HTTP Basic Auth
HTTP Basic Auth 是每次請求API時都提供用戶的 username 和 password ，簡言之，Basic Auth 是最簡單的認證方式，只需提供用戶名密碼即可，但由于有把用戶名密碼暴露給第三方瀏覽器的風險，在生產環境下被使用的越來越少。因此，不推薦采用 HTTP Basic Auth。
Cookie Auth
Cookie Auth 機制 是當用戶請求登錄的時候，如果沒有問題，我們在服務端生成一條記錄，這個記錄里可以說明一下登錄的用戶是誰，然后把這條記錄的 ID 號發送給瀏覽器，瀏覽器收到將 ID 存儲在 Cookie 里，下次這個用戶再向服務端發送請求的時候，可以帶著這個 Cookie ，這樣服務端會驗證一個這個 Cookie 里的信息，看看能不能在服務端這里找到對應的記錄，如果可以，說明用戶已經通過了身份驗證，就把用戶請求的數據返回給瀏覽器
Cookie 與 Session 合作：
因為如果我們把所有信息全都存在 Cookie，很容易被用戶在瀏覽器看到或者在 JS 腳本修改，Cookie 存儲數據大小也受限，太大傳輸效率就低了，所以我們把一些敏感或者量大的數據存在 Session里。
-
將兩者信息進行匹配驗證，即瀏覽器（Cookie）和服務器端（Session）之間的驗證。
為什么需要這兩者的合作？ HTTP是一種無狀態無連接的協議，即請求是不知道是誰請求，需要在這兩者之間做一層身份的識別。 就如原本是去商場用現金交易，付款后就不知道用戶是誰了， 現在變成線上支付，加了一層身份識別，我們就可以對用戶進行追蹤了。
認證過程
瀏覽器使用戶用戶名和密碼訪問，通過了驗證
服務端將瀏覽器信息進行處理加密（簽名，專業術語叫信息摘要算法）
把記錄這些信息的 ID 發送給瀏覽器
瀏覽器收到 ID 后存儲在 Cookie 中
下次瀏覽器重新訪問服務端時，帶上 Cookie 信息
服務端驗證 Cookie 里面的信息，如果能找到對應的記錄，則用戶通過了驗證
Cookie Auth 認證暴露的問題
-
擴展性
用戶認證之后，服務端做認證記錄，如果認證的記錄被保存在內存中的話， 這意味著用戶下次請求還必須要請求在這臺服務器上,這樣才能拿到授權的資源， 這樣在分布式的應用上，相應的限制了負載均衡器的能力。這也意味著限制了應用的擴展能力。 -
CSRF
因為是基于 Cookie 來進行用戶識別的, Cookie 如果被截獲，用戶就會很容易受到跨站請求偽造的攻擊。 -
CORS
因為瀏覽器引入了`同源策略`（同域, 同協議, 同端口）， 但在實際需求中，又不得做一些跨域的請求。跨域又會引起上述的 CSRF 。 提示：CORS 并不能防止 CSRF 攻擊。CORS 機制是為了解決腳本跨域請求的問題，無法防止 CSRF。 CSRF 攻擊的發起有多種方式，如html資源標簽、form表單提交、JS代碼發起請求
基于 Token 認證
使用基于 Token 的身份驗證方法，在服務端不需要存儲用戶的登錄記錄。
認證過程：
瀏覽器使用用戶名跟密碼請求登錄
服務端收到請求，去驗證用戶名與密碼
驗證成功后，服務端會簽發一個 Token，再把這個 Token 發送給瀏覽器
瀏覽器收到 Token 以后可以把它存儲起來，比如放在 Cookie 里或者 Local Storage 里
瀏覽器每次向服務端請求資源的時候需要帶著服務端簽發的 Token
服務端收到請求，然后去驗證瀏覽器請求里面帶著的 Token，如果驗證成功，就向瀏覽器返回請求的數據
Token 優勢
-
無狀態，可擴展性
如前所述，服務器端不存儲會話，可擴展性強，如果有多臺服務器，會話信息存儲地方不只一個的話， 就需要某種同步機制，或者想辦法知道用戶和 Session 存儲地的對應關系。 -
支持跨域
Cookie是不允許垮域訪問的，瀏覽器有跨域問題，如果有好幾個不同的網站的話，Cookie Auth 需要在 login 的時候給 所有的 Domain 寫上 Cookie，通常做法應該是有個 SSO Endpoint，登陸成功后跳轉到專門的頁面， 頁面上用iframe之類的分別調用各個 Domain 的 Cookie Endpoint。 這一點對 Token 機制是不存在的，前提是傳輸的用戶認證信息通過HTTP頭傳輸。 -
解耦
無需使用特定的身份驗證方案，只要擁有生成 Token 所需的驗證信息， 在何處都可以調用相應接口生成 Token，無需繁瑣的耦合的驗證操作，是一次生成，永久使用。 -
性能
Token 不用查 DB ，然后用戶角色的劃分，也可以通過 Token 中的數據進行查看。 -
支持非瀏覽器環境，更適應移動應用
原生平臺（iOS, Android 等），Cookie 是不被支持的（你需要通過Cookie容器進行處理）， 采用 Token 認證機制比較合適。 -
標準化
你的API可以采用標準化的 JSON Web Token (JWT). 這個標準已經存在多個后端庫（.NET, Ruby, Java,Python, PHP）和 多家公司的支持（如：Firebase,Google, Microsoft）.
參考文獻：
http://tech.colla.me/zh/show/token_session_cookie
https://b1ngz.github.io/csrf-and-cors/
https://my.oschina.net/hosee/blog/903665
- **版權聲明： **本博客所有文章除特別聲明外，均采用 CC BY 4.0 CN協議 許可協議。轉載請注明出處！
