上壹篇文章我們了解了壹下 cookie 與 session 的產生、作用與原理。盡管二者在歷史中已經服役過很長壹段時間，但不論什麽技術，都會有後來的優秀者取而代之。
前面說到，cookie 因為是保存在客戶端，所以有安全隱患，因而誕生了 session，session 保存在服務器端，相對安全很多。但 session 每次都要為用戶開辟壹個空間用於其身份校驗，且每次瀏覽器的請求過來服務器都要進行校驗請求，十分耗費服務器的空間與性能。
於是，另壹種身份校驗工具誕生了，這就是 token。
本質上還是用戶身份驗證的工具。但與 cookie、session 明文似的形式不同，token 是經過壹系列加密手段加密過的，最後表現為壹串“無意義”的字符串。但裏面包含了許多信息，可能包括用戶登錄的終端的地址、用戶身份 ID、時間戳以及壹個簽名。所謂簽名就是信息發送者給這段信息進行簽名，讓信息接收方知道請求 token 是屬於誰。可以理解為在妳的身份證上簽名字，證件加筆跡雙重認證。
為了避免上述 CSRF 攻擊，瀏覽器對網頁資源的訪問提出了限制，URL 請求必須是與頁面壹樣來自同壹 協議 、 域名 、 端口 才給予訪問權限。這樣三者相同的站點被認為是有相同的“源”，是壹個獨立的“域”。即使 “localhost” 與 “ip” 都指向了本機，但也會被認為是非同源。瀏覽器在某個“域”下不會執行其他“域”的腳本。因而這也產生了前端領域裏壹個重要的話題：跨域。
session 的產生來自於用戶登錄後服務器生成的壹個 session 對象，保存在服務器端，這個 session 只適用於該“域”。但實際情況是，壹個網站的請求大多數情況下都會跨域，每臺服務器的端口不同，甚至是域名就不同，每當跨域時就會形成新的會話，生成新的 session，這是非常影響用戶體驗的，所以也會有許多保存、***享或中央存儲 session 的方案。
但上述兩種限制在 token 這裏就不再是問題。
與 cookie 類似。
首先，用戶輸入賬號密碼，發起登錄請求，服務器校驗賬號密碼合法性，成功則返回 token 給客戶端。
客戶端收到響應後拿到 token，將其通過 localStorage 等本地存儲方式進行保存。
當瀏覽器再次請求時，需要在請求頭中添加 token，這樣服務器在接收到請求後便可以識別該請求的身份是否合法，合法則返回響應數據。
在實際應用中，配合 axios 的請求攔截器使用起來會很方便：
這樣，就不用每次請求都手動添加 token，axios 會自動幫助我們完成添加，十分方便。
其實前端程序員對 token 的涉及沒有多深，只需要在需要授權的請求中攜帶 token 即可。token 的生成、加密等都是後端去處理。所以，這裏也就不在贅述 token 的加密原理，以筆者的能力也很難去講述清楚。
token 運用也不是上文中描述的那麽簡單，涉及到壹些過期處理、refresh 等操作。這些日後有機會再詳談。