㈠ 自動化token過期場景如何設計用例
自動化token過期場景如何設計用例有三種方案：
1、每一次請求都進行重新生成一個新的token頻率過高，性能不好。
2、每次登錄的時候生成兩個token給前端進行返回，一個是用於鑒別用戶身份的token，另外一個token則是用於刷新token用的。
3、登錄過後給前端進行返回token並設置了過期時間30分鍾，每次請求的時候前端把token存在請求頭裡面進行發請求，後端接收請求的時候獲取請求頭出來進行jwt解析判斷過期時間是否小於10分鍾，如果小於10分鍾就生成新的token在responseHearde進行。
㈡ Token是什麼和session、cookie相比，使用場景有什麼區別
在Web開發領域，相信大家對於Cookie和Session都很熟悉，Cookie和Session都是會話保持技術的解決方案。隨著技術的發展，Token機制出現在我們面前，不過很多開發者對於Token和Cookie、Session的區別及使用場景分辨不清。
Cookie和Session的用途 要知道我們訪問網站都是通過HTTP協議或HTTPS協議來完成的， HTTP協議它本身是無狀態的協議 （即：伺服器無法分辨哪些請求是來源於同個客戶）。而業務層面會涉及到客戶端與伺服器端的交互（同網站下多個頁面間能共享數據），此時伺服器端必須要保持會話狀態，這樣才能進行用戶身份的鑒別。
由於HTTP無狀態的特性，如果要實話客戶端和伺服器端的會話保持，那就需要其它機制來實現，於是Cookie和Session應運而生。
通常情況下， Session和Cookie是搭配在一起使用的 。
Token是什麼上面說到的Session和Cookie機制來保持會話，會存在一個問題：客戶端瀏覽器只要保存自己的SessionID即可，而 伺服器卻要保存所有用戶的Session信息，這對於伺服器來說開銷較大，而且不利用伺服器的擴展 （比如伺服器集群時，Session如何同步存儲就是個問題）！
於是有人思考，如果把Session信息讓客戶端來保管而且無法偽造不就可以解決這個問題了？進而有了Token機制。
Token俗稱為「令牌」 ，它的構成是：
Token機制下的認證流程 Token機制其實和Cookie機制極其相似 ，主要有以下流程：
1、用戶登錄進行身份認證，認證成功後伺服器端生成Token返回給客戶端；
2、客戶端接收到Token後保存在客戶端（可保存在Cookie、LocalStorage、SessionStorage中）；
3、客戶端再次請求伺服器端時，將Token作為請求頭放入Headers中；
4、伺服器端接收請求頭中的Token，將用戶參數按照既定規則再進行一次簽名，兩次簽名若一致則認為成功，反之數據存在篡改請求失敗。
（生成簽名示例圖）
（驗證簽名示例圖）
Token與Cookie+Session的區別Cookie其實也充當的是令牌作用，但它是「有狀態」的； 而Token令牌是無狀態的，更利於分布式部署。
session和cookie
在講Token之前，先簡單說說什麼是session和cookie。
Token
但是這里會有個問題， 伺服器要保存所有用戶的session信息，開銷會很大，如果在分布式的架構下，就需要考慮session共享的問題，需要做額外的設計和開發 ，例如把session中的信息保存到Redis中進行共享；所以因為這個原因，有人考慮這些信息是否可以讓客戶端保存，可以保存到任何地方，並且保證其安全性，於是就有了Token。
Token是服務端生成的一串字元串，可以看做客戶端進行請求的一個令牌。
基於Token的認證流程
整體的流程是這樣的：
總結 希望我的回答，能夠幫助到你！我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
Token顧名思義就是令牌、憑證、鑰匙 。只有這把鑰匙，你才能打開門。token一般都是服務端生成，比如一個web系統，用戶登錄的時候，服務端校驗用戶名密碼通過以後，會生成一個token，同時會生成refreshToken和一個過期時間。然後將refreshToken和token返回給客戶端。客戶端會將token保存下來。後續所有的請求都會攜帶這個token。服務端會判斷當前token是否存在已經是否過期。如果token不存在或者過期就會拒絕本次請求。如果token過期怎麼辦，就用refreshToken刷新時間。當然這里可能還有別的方案。比如只生成token，每次請求的時候都刷新過期時間。如果長時間沒有刷新過期時間，那token就會過期。
session就是回話，這是服務端的一種操作。當你第一次訪問一個web網站的時候，服務端會生成一個session，並有一個sessionid和他對應。這個session是存儲到內存中的，你可以向這個session中寫入信息，比如當前登錄用戶的信息。sessionid會被返回到客戶端，客戶端一般採用cookie來保存。當然這個cookie不用人為寫入。用tomcat容器來舉個例子。 當後端調用HttpServletRequest對象的getSession的方法的時候，tomcat內部會生成一個jsessonid（tomcat sessionid的叫法）。這個jsessonid會隨本次請求返回給客戶端。響應頭信息
這個jessionid就會寫到cookie中。之後jessionid就會通過cookie傳遞到服務端。
這里我們就會很清楚了， session的數據是存儲到內存中。那問題就來了，如果我們的服務是分布式部署，有多台機器的話，可能我們第一次登陸的時候，我們把用戶的信息存儲到了session，但是後面的請求到了B機器上，那B機器是獲取不到用戶的session的。另外就是session存儲在內存中，那伺服器重啟，session就丟失了，這就是他的弊端。現在有一些技術，例如session共享、iphash、session持久等也可以解決上述問題 。
cookie是瀏覽器的一種策略。上述講到了sessionid就是存儲在cookie中的。我們知道http協議是無狀態的，cookie就是用來解決這個問題的。cookie中可以用來保存服務端返回的一些用戶信息的，例如前文提到的token、sessionid。每一次的請求，都會攜帶這些cookie。服務端從請求頭中取到cookie中的信息，就可以識別本次請求的來源，這樣，http是不是就變成有狀態的了。
這里說幾點cookie注意事項。
1、cookie存放在客戶端，所以是不安全的。人為可以清除
2、cookie有過期時間設定。如果不設置過期時間，說明這個cookie就是當前瀏覽器的會話時間，瀏覽器關了，cookie 就存在了。如果有過期時間，cookie就會存儲到硬碟上，瀏覽器關閉不影響cookie。下次打開瀏覽器，cookie還存在
3、cookie有大小的限制，4KB。
這個問題，網上有很多的答案，相信都看過了，估計也沒有看明白。所以我就不去網上復制了，用自己的話，盡量說通俗，說重點。
cookie和session實際上是同一套認證流程，相輔相成。session保存在伺服器，cookie保存在客戶端。最常見的做法就是客戶端的cookie僅僅保存一個sessionID，這個sessionID是一個毫無規則的隨機數，由伺服器在客戶端登錄通過後隨機生產的。往後，客戶端每次訪問該網站都要帶上這個由sessionID組成的cookie。伺服器收到請求，首先拿到客戶端的sessionID，然後從伺服器內存中查詢它所代表的客戶端(用戶名，用戶組，有哪些許可權等)。
與token相比，這里的重點是，伺服器必須保存sessionID以及該ID所代表的客戶端信息。這些內容可以保存在內存，也可以保存到資料庫(通常是內存資料庫)。
而token則可以伺服器完全不用保存任何登錄信息。
token的流程是這樣的。客戶端登錄通過後，伺服器生成一堆客戶端身份信息，包括用戶名、用戶組、有那些許可權、過期時間等等。另外再對這些信息進行簽名。之後把身份信息和簽名作為一個整體傳給客戶端。這個整體就叫做token。之後，客戶端負責保存該token，而伺服器不再保存。客戶端每次訪問該網站都要帶上這個token。伺服器收到請求後，把它分割成身份信息和簽名，然後驗證簽名，若驗證成功，就直接使用身份信息(用戶名、用戶組、有哪些許可權等等)。
可以看出，相對於cookie/session機制，token機制中，伺服器根本不需要保存用戶的身份信息(用戶名、用戶組、許可權等等)。這樣就減輕了伺服器的負擔。
我們舉個例來說，假如目前有一千萬個用戶登錄了，在訪問不同的網頁。如果用cookie/session，則伺服器內存(或內存資料庫)中要同時記錄1千萬個用戶的信息。每次客戶端訪問一個頁面，伺服器都要從內存中查詢出他的登錄信息。而如果用token，則伺服器內存中不記錄用戶登錄信息。它只需要在收到請求後，直接使用客戶端發過來的登錄身份信息。
可以這么說， cookie/session是伺服器說客戶端是誰，客戶端才是誰。而token是客戶端說我(客戶端)是誰，我就是誰 。當然了，token是有簽名機制的。要是客戶端偽造身份，簽名通不過。這個簽名演算法很簡單，就是將客戶端的身份信息加上一個只有伺服器知道的鹽值(不能泄露)，然後進行md5散列演算法(這里只是簡化，方便理解，實際細節要稍復雜一些)。
cookie/session在單伺服器，單域名時比較簡單，否則的話，就要考慮如何將客戶端的session保存或同步到多個伺服器。還要考慮一旦宕機，內存中的這些信息是否會丟失。token因為伺服器不保存用戶身份，就不存在這個問題。這是token的優點。
token因為伺服器不保存用戶身份信息，一切都依賴當初那個簽名。所以存在被盜用的風險。也就是說一旦盜用，伺服器可能毫無辦法，因為它只認簽名演算法。而session機制，伺服器看誰不爽，可以隨時把他踢出(從內存中刪掉)。正是因為如此，token高度依賴過期時間。過期時間不能太長。過期短，可以減少被盜用的風險。
除了上面所說的，我個人認為，如果開發的系統足夠小，傾向於使用cookie/session。如果系統同時登錄用戶多，集群伺服器多，有單點登錄需求，則傾向於使用token。
萬維網的發展 歷史
Token, 令牌，代表執行某些操作的權利的對象。
token主要用於鑒權使用，主要有以下幾類：
cookie主要是網站用於在瀏覽器臨時存放的數據，包括瀏覽器緩存數據以及伺服器設定的一些數據，主要存放在瀏覽器端。
session主要用於保存會話數據，一般存儲在伺服器端，同時每一條session對用一個sessionID，sessionID是存放在瀏覽器的cookie中。
傳統上的會話登陸和鑒權主要用session加cookie實現，隨著分布式系統的快速演進，尤其是微服務的應用，token+cookie的授權訪問機製得到親睞，通常在用戶登錄後，伺服器生成訪問令牌(Access token)，瀏覽器存儲cookie中，在每次請求資源時都會在請求頭中帶上token，用於伺服器授權訪問使用。
Token和session都是web網站的會話保持、認證的解決方案；
既然都一樣為什麼還有token的說法。
從token產生的背景說起1.移動端應用使得伺服器端Session失效
2.分布式系統中Session無法共享
所以說session對於以上兩種情況無效了，所以有了Token的說法
那麼什麼是token,token長什麼樣子？先給大家一個直觀的感受
token:PC-3066014fa0b10792e4a762-23-20170531133947-4f6496
說白了token保存就是用戶的信息（不能保存密碼等敏感信息）
token的組成：
客戶端標識-USERCODE-USERID-CREATIONDATE-RONDEM[6位]
USERCODE，RONDEM[6位]經過MD5加密就變成了以上字元串
token的請求流程
請求流程解析
1.前端用戶發送登錄信息至認證系統
2.驗證用戶登錄信息，判斷用戶是否存在
3.如果用戶存在，生成token信息（客戶端標識-USERCODE-USERID-CREATIONDATE-RONDEM[6位]），並存儲在redis中
4.並將該token返回前端，附加至header
驗證token客戶端
將token附加至header
服務端
最後總結一下
一般的垂直架構項目使用Session沒有任何問題，但是分布式項目或涉及到移動端則考慮使用token。
session
session的中文翻譯是「會話」，當用戶打開某個web應用時，便與web伺服器產生一次session。伺服器使用session把用戶的信息臨時保存在了伺服器上，用戶離開網站後session會被銷毀。這種用戶信息存儲方式相對cookie來說更安全，可是session有一個缺陷：如果web伺服器做了負載均衡，那麼下一個操作請求到了另一台伺服器的時候session會丟失。
cookie
cookie是保存在本地終端的數據。cookie由伺服器生成，發送給瀏覽器，瀏覽器把cookie以kv形式保存到某個目錄下的文本文件內，下一次請求同一網站時會把該cookie發送給伺服器。由於cookie是存在客戶端上的，所以瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會占據太多磁碟空間，所以每個域的cookie數量是有限的。
cookie的組成有：名稱(key)、值(value)、有效域(domain)、路徑(域的路徑，一般設置為全局:"")、失效時間、安全標志(指定後，cookie只有在使用SSL連接時才發送到伺服器(https))。下面是一個簡單的js使用cookie的例子:
用戶登錄時產生cookie:
document.cookie = "id="+result.data['id']+"; path=/";
document.cookie = "name="+result.data['name']+"; path=/";
document.cookie = "avatar="+result.data['avatar']+"; path=/";
使用到cookie時做如下解析：
var cookie = document.cookie;var cookieArr = cookie.split(";");var user_info = {};for(var i = 0; i < cookieArr.length; i++) {
user_info[cookieArr[i].split("=")[0]] = cookieArr[i].split("=")[1];
}
$('#user_name').text(user_info[' name']);
$('#user_avatar').attr("src", user_info[' avatar']);
$('#user_id').val(user_info[' id']);
token
token的意思是「令牌」，是用戶身份的驗證方式，最簡單的token組成:uid(用戶唯一的身份標識)、time(當前時間的時間戳)、sign(簽名，由token的前幾位+鹽以哈希演算法壓縮成一定長的十六進制字元串，可以防止惡意第三方拼接token請求伺服器)。還可以把不變的參數也放進token，避免多次查庫
cookie 和session的區別
1、cookie數據存放在客戶的瀏覽器上，session數據放在伺服器上。
2、cookie不是很安全，別人可以分析存放在本地的COOKIE並進行COOKIE欺騙
考慮到安全應當使用session。
3、session會在一定時間內保存在伺服器上。當訪問增多，會比較佔用你伺服器的性能
考慮到減輕伺服器性能方面，應當使用COOKIE。
4、單個cookie保存的數據不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。
5、所以個人建議：
將登陸信息等重要信息存放為SESSION
其他信息如果需要保留，可以放在COOKIE中
token 和session 的區別
session 和 oauth token並不矛盾，作為身份認證 token安全性比session好，因為每個請求都有簽名還能防止監聽以及重放攻擊，而session就必須靠鏈路層來保障通訊安全了。如上所說，如果你需要實現有狀態的會話，仍然可以增加session來在伺服器端保存一些狀態
App通常用restful api跟server打交道。Rest是stateless的，也就是app不需要像browser那樣用cookie來保存session,因此用session token來標示自己就夠了，session/state由api server的邏輯處理。 如果你的後端不是stateless的rest api, 那麼你可能需要在app里保存session.可以在app里嵌入webkit,用一個隱藏的browser來管理cookie session.
Session 是一種HTTP存儲機制，目的是為無狀態的HTTP提供的持久機制。所謂Session 認證只是簡單的把User 信息存儲到Session 里，因為SID 的不可預測性，暫且認為是安全的。這是一種認證手段。 而Token ，如果指的是OAuth Token 或類似的機制的話，提供的是 認證 和 授權 ，認證是針對用戶，授權是針對App 。其目的是讓 某App有權利訪問 某用戶 的信息。這里的 Token是唯一的。不可以轉移到其它 App上，也不可以轉到其它 用戶 上。 轉過來說Session 。Session只提供一種簡單的認證，即有此 SID，即認為有此 User的全部權利。是需要嚴格保密的，這個數據應該只保存在站方，不應該共享給其它網站或者第三方App。 所以簡單來說，如果你的用戶數據可能需要和第三方共享，或者允許第三方調用 API 介面，用 Token 。如果永遠只是自己的網站，自己的 App，用什麼就無所謂了。
token就是令牌，比如你授權（登錄）一個程序時，他就是個依據，判斷你是否已經授權該軟體；cookie就是寫在客戶端的一個txt文件，裡麵包括你登錄信息之類的，這樣你下次在登錄某個網站，就會自動調用cookie自動登錄用戶名；session和cookie差不多，只是session是寫在伺服器端的文件，也需要在客戶端寫入cookie文件，但是文件里是你的瀏覽器編號.Session的狀態是存儲在伺服器端，客戶端只有session id；而Token的狀態是存儲在客戶端。
想要全面深入地掌握Token，我們需要先了解這些：Token的概念、身份驗證過程、實現思路、使用場景，以及Cookie、Session、Token的區別。
Token是驗證用戶身份的一種方式，簡稱做「令牌」。最簡單的token組成：uid(用戶唯一的身份標識)、time(當前時間的時間戳)、sign(簽名，由token的前幾位+鹽，以哈希演算法壓縮成一定長的十六進制字元串，可以防止惡意第三方拼接token請求伺服器)。還可以把不變的參數也放進token，避免多次查庫。
每一次請求都需要Token,Token應該在HTTP的頭部發送，從而保證Http請求無狀態。我們同樣通過設置伺服器屬性Access-Control-Allow-Origin:* ，讓伺服器能接受到來自所有域的請求。
需要注意的是，在ACAO頭部標明(designating)*時，不得帶有像HTTP認證，客戶端SSL證書和cookies的證書。
當我們在程序中認證了信息，並取得Token之後，我們便能通過這個Token做許多的事情。我們甚至能基於創建一個基於許可權的token傳給第三方應用程序，這些第三方程序能夠獲取到我們的數據（當然只有在我們允許的特定的token）。
Cookie和Session的區別
綜合以上考量，建議方案：
Session和Cookie取長補短、配合使用，將登陸信息等重要信息存放為Session，其他信息如果需要保留，可以放在Cookie中。
Session和Token並不矛盾，作為身份認證，Token安全性比Session高，因為Token發送的每個請求都帶有簽名，能防止監聽，以及重放攻擊。而session就必須靠鏈路層來保障通訊安全。如上所說，如果需要實現有狀態的會話，可以通過增加session，在伺服器端保存一些狀態。
App通常用Restful API跟server打交道。Rest是Stateless的，也就是App不需要像Browser那樣用Cookie來保存Session，因此使用Session Token來標示就足夠了。Session/state由API Server的邏輯處理。如果後端不是Stateless的rest API，那麼可能需要在App里保存Session，可以在App里嵌入webkit，用一個隱藏的Browser來管理Cookie Session.
Session是一種HTTP存儲機制，目的是為無狀態的HTTP提供持久機制。 所謂的Session認證，只是簡單的把User信息存儲到Session里，因為SID的不可預測性，暫且認為是安全的，這是一種認證手段。
Session只提供一種簡單的認證，即有此SID，以及User的全部權利。是需要嚴格保密的，這個數據只在使用站點保存，不可共享給其它網站或者第三方App。所以簡單來說，如果你的用戶數據可能需要和第三方共享，或者允許第三方調用API介面，則使用Token，如果只是自己的網站或App應用，使用什麼都OK。
Token，指的是OAuth Token或類似的機制的話，提供的是認證和授權 ，認證是針對用戶，授權是針對App。其目的是讓某App有權利訪問某用戶的信息，這里的Token是唯一的，不可以轉移到其它App上，也不可以轉到其它用戶上。
Token就是令牌，比如你授權（登錄）一個程序時，他就是個依據，判斷你是否已經授權該軟體。Cookie就是寫在客戶端的一個txt文件，記錄下用戶的訪問、登錄等信息，下次用戶再登錄某個網站時，伺服器接收到請求，就會自動調用Cookie，自動登錄用戶名。
Session和Cookie差不多，只是Session是寫在伺服器端的文件，也需要在客戶端寫入Cookie文件，但是文件里是用戶的瀏覽器編號.Session的狀態是存儲在伺服器端，客戶端只有session id，而Token的狀態是存儲在客戶端的。
以上，是關於Token、Session、Cookie的知識點介紹，更加深入的詳解，感興趣的童鞋，可查看我持續分享的【BAT架構技術專題合集500+】，回復【架構】，即可領取。
Token是什麼？
Token是令牌、憑證、鑰匙，在Web領域中進行 身份驗證 ，關鍵點在驗證！！，說驗證就必須了解一下Web領域的發展史呢。
2. 隨著人們需求的改變，比如在線購物系統，需要登陸的網站等，這時候需要進行 交互 性，伺服器接收到請求的時候，要根據你是否登陸，以及判斷你是誰，來給你響應，這時候問題就來了，怎麼知道每次請求的誰呢，所以就出來了一個 會話標識（session id），就是一個隨機的字元串 ，每個人登陸的時候，伺服器都會返回一個會話標識，這是再請求的時候，只要帶上會話標識，伺服器就知道請求的是誰。
3. 這樣子每個人只要保存自己的session id就可以啦，伺服器要保存 所有人 的session id！！！如果有成千上萬的人訪問伺服器，那對伺服器是巨大的開銷，嚴重限制了伺服器端的擴展能力，比如機器A跟機器B組成了伺服器集群，那麼訪問了機器A，會話標識在機器A上，如果轉到機器B，就不能訪問了，也許會說，那復制呢，機器A搬到機器B，也有說統一把標識放在一個機器上，但是萬一這個機器掛了呢，那體驗就很差了。
4. 這個時候就有人想，用戶自己保存自己的標識，就是Token，訪問的時候帶上這個Token，這個 Token是用戶id+簽名 ，驗證時，伺服器只要相同的演算法和伺服器才知道的密鑰進行簽名，如果結果跟Token中的簽名一樣，那就可以證明是登陸過的用戶。
這樣一來，伺服器不保存session id，只要生成Token，訪問時，只要對Token進行判斷，Token也是有有效期的，所以也要進行refreshToken的。
Token,Cookie,Session三者使用場景的區別？Token主要是Web領域的身份認證 ，最常見的就是Web API這個功能：
Cookie 就是餅干， 它是伺服器生產，永久保存在瀏覽器的數據，以kv的形式 ，你可以打開你的瀏覽器（這里以win10 edge為例），點擊上方的三個點的按鈕，再點擊更多工具，再點擊開發人員工具，再點擊網路，此時內容選擇文檔，然後刷新頁面，找Cookie即可。
Session是會話標識，是伺服器用來判斷正在會話的用戶是誰，伺服器生產的隨機數 ，保存在伺服器中，用戶端也要進行保存，雖然能實現會話的共能，但對伺服器的擴展能力限制，同時當伺服器是兩台機器組成以上的時候，會導致兩台機器以上保存的session同步問題，會導致用戶體驗極差。
Token跟Session最大的區別就是Token服務端不用保存，同時是通過簽名等技術實現的，Session因為是隨機數，導致伺服器要進行保存。
㈢ 前端登陸獲取保存token再添加到請求頭中
登陸獲取token保存在本地，在請求頭添加參數
登陸：
$.ajax({
url : 'http://119.254.155.151:8768/yq/dy/login',// 獲取自己系統後台用戶信息介面
data :data,
type : "post",
dataType: "json",
success : function(data) {
const token = data.data.token
window.localStorage.setItem('yq_token', token)
}
}）
內部頁面添加請求頭：
var userToken = window.localStorage.getItem("yq_token");
$.ajax({
headers: {
"token":userToken//此處放置請求到的用戶token
},
type: "get",
url: "http://119.254.155.151:8768/yq/important/data?schemeId=247248",//請求url
contentType: "application/x-www-form-urlencoded",
success: (data) => {
}
}）
㈣ 登錄時對於token的處理
在前後端完全分離的情況下，Vue項目中實現token驗證大致思路如下：
1、用戶輸入賬號密碼，前端調後端的登陸介面，發送用戶名和密碼，
2、後端收到請求，驗證用戶名和密碼，驗證通過後（即登錄成功），後端返回token給前端；
3、前端拿到token，將token存儲到localStorage和vuex中，並跳轉路由頁面；
4、前端每次跳轉路由，都要判斷 localStroage 中有無 token ，沒有就跳轉到登錄頁面，有則跳轉到對應路由頁面（ 通過router.beforeEach((to, from, next)=>{.....}）)
5、每次調後端介面，都要在請求頭中加上token；
6、後端判斷請求頭中有無token，有token，就拿到token並驗證token，驗證成功就返回數據，驗證失敗（例如：token過期）就返回編碼401（編碼由前台和後台約定好），請求頭中沒有token也返回編碼401；
7、如果前端拿到狀態碼為401，則清除token信息並跳轉到登錄頁面，並彈框提示用戶當前缺少token或者token已失效，請重新登錄；
一、調登錄介面成功，在回調函數中將token存儲到localStorage和vuex中
login.vue
store文件夾下的index.js
二、路由導航守衛
main.js
三、請求頭加token，如果前端拿到狀態碼為401，就清除token信息並跳轉到登錄頁面
㈤ 前端登陸實現
四種方式
Cookie 出現的原因： HTTP 協議是無狀態的，每次請求都會建立一個新的鏈接，請求結束就會斷開鏈接，優點就是可以節省鏈接資源，缺點就是無法保存用戶狀態。Cookie 的出現就是為了解決這個問題。
Cookie 是存儲在瀏覽器中的，可以通過 Js 和 set-cookie 這個響應欄位來進行設置。
cookie 的限制：
有了 cookie 之後，服務端就可以從客戶端獲取到信息，如果需要對信息進行驗證，那麼還需要 session
服務端在收到客戶端的請求之後，會在伺服器中開辟一片內存空間來存放 session
第一次登陸之後，下次再訪問的時候就會攜帶這個 cookie，服務端就可以根據 sessionId 進行驗證用戶是否登陸（判斷這個 sessionId 和服務端保存的 sessionId 是否一致，是否有這個 sessionId 的記錄或者記錄是否有效）
客戶端瀏覽器訪問伺服器的時候，伺服器把客戶端信息以某種形式記錄在伺服器上。這就是 Session。客戶端瀏覽器再次訪問時只需要從該 Session 中查找該客戶的狀態就可以了。
Token 是 伺服器 生成的一個字元串，作為客戶端請求的一個令牌。第一次登陸之後，伺服器會生成一個 Token 返回給客戶端，客戶端後續訪問的時候，只需帶上這個 Token 進行身份認證
缺點
JWT（Json Web Token）
服務端不需要存儲 Token 那麼服務端是怎麼驗證客戶端傳遞過來的 Token 是否有效的呢？
答案：
Token 並不是雜亂無章的字元串，而是通過多種演算法拼接而成的字元串
header 部分指定了這個 Token 所使用的簽名演算法
payload 部分表明了這個 JWT 的意圖
signature 部分為 JWT 的簽名，主要是為了讓 JWT 不被隨意的篡改
簽名的部分有兩個步驟
一：
二:
最後的 Token 計算如下：
單點登陸指的是公司會搭建一個公共的認證中心，公司里的所有產品的認證都可以在這個認證中心中完成，一個產品在認證中心認證之後，再去訪問其他產品時就不需要再次認證
這個時候，由於 a.com 存在已登錄的 Cookie 信息，所以伺服器端直接認證成功。
這個時候由於認證中心存在之前登陸過的 cookie，所以不需要再輸入賬號密碼，直接從第四步開始執行
目前我們已經完成了單點登錄，在同一套認證中心的管理下，多個產品可以共享登錄態。現在我們需要考慮退出了，即：在一個產品中退出了登錄，怎麼讓其他的產品也都退出登錄？
原理也不難，其實就是在攜帶 ticket 去請求認證中心的時候，再去請求一下認證中心的退出登陸的 api 即可
當某個產品 c.com 退出登陸時
sso 就是一個集中地驗證系統。你項目內請求時，向 sso 發一個請求，他給你個 token 你扔到游覽器緩存里，請求的時候放在請求頭里帶著。和其他驗證介面一樣。 他好就好在，一個賬號在不同系統里都可以登錄，因為不同項目可以共用這個 token。並且通過 sso 集中管理一些用戶信息，你可以方便的拿用戶信息。
以微信為例子
㈥ token什麼意思 前端如何使用token
大家好，從網上找了很多關於token的文章，都是提到要生成一個token，然後前端每次請求的時候，要使用這個token，請問下如何在前端使用生成的token？
前端能就使用jQuery搞定，還是需要其他的前端框架配合？能有這方面的完整示例嗎？
做後端的，對前端的東西有些不太懂，請見諒
先謝謝大家了！！
解決方案1:
一般是後端有個結構給你拿token的，然後你請求的時候，根據約定
把token
放在header中
放uri參數中
放body表單里
給後端
解決方案2:
因為http協議是無狀態的 token是後台給你發的一個唯一標識 你再去訪問後台時帶上這個token 後台就知道你是誰了
同session的作用
解決方案3:
前台生成的token，可能會存在安全性問題吧
解決方案4:
你做後台應該很了解token才對呀。
用戶登錄後，生成一個session_id，即token，可以存在redis里。然後前端或客戶端保存起來，存cookie或者LS都行，然後所有的請求作為基類參數帶上（也有通過cookie帶的），然後server端再取到後，驗證你是不是你。
解決方案5:
使用領域很多，以表單為例子：
後台生成token.
前端列印表單,並且講該token變成隱藏項。<input type="hide" value="{{token}}">
客戶提交表單。
後台驗證提交的token合法性。
驗證成功，處理表單。驗證失敗，返回錯誤處理頁面。
解決方案6:
token一般都是後端生成的，在登陸之後返回，前端保存token，之後每次請求都帶上token來驗證身份。
解決方案7:
問題是前端生成的token給後台有用嗎
解決方案8:
一般token都是伺服器端生成，做csrf的。我在補充下我見過前端生成的栗子，雖然沒啥卵用，但讓我廢了好大的勁才發現。
譬如你有一個驗證碼的表單，你在傳遞驗證碼的時候，新增一個隱藏域，將驗證碼用你本地的js加密後，作為參數傳遞，這樣在伺服器端可以檢測驗證碼是不是被篡改過。
但這樣沒啥卵用，因為在提交的時候用同樣的js模擬即可。
解決方案9:
大多數情況下，token作為一種令牌，都是在伺服器端生成，生成的方法很多，從簡單點的對時間或者id或者兩個混合起來進行哈希運算的值到自己設計更復雜的演算法都可以，生成的目的是為了給前端下一次通信時使用這個token作為令牌，當作為一個請求資源的許可的標識，而伺服器則會視這個token在一段時間內都是有效的，並且還可以額外看情況加上是否是同一個ip之類的其它的限制，從而防止某種資源被非法訪問
偶有前端（包括本地客戶端或者app）生成token的情況是已經約定好了一個好的加密機制，伺服器可以信任客戶端的這個輸入的情況下可以由前端或者客戶端生成
㈦ 11 | 登錄前端實現
前端任務點，編寫登錄請求函數，和 用戶注冊 類似，前端拿到用戶名和密碼發起 POST 請求。
收到 token 如何持久化存儲，如何讓每次請求都攜帶 token 是這里的點。
用戶登錄的介面詳情可以點 這里 。
這里有可以優化的點，未來可能需要添加驗證碼等附加信息，這個時候就需要添加函數參數，就會比較麻煩，可以將參數數據格式包裝成一個對象。當然，這里還是使用第一種方法了。
這不是重點，重點是登錄成功後，我們要做的事情。
按照介面約定，登錄成功我們可以得到如下信息：
這里我們要用到 token 欄位，是我們現在有 token 了，但一刷新就沒了，所以我們要做一下持久化存儲，你想存哪裡就存哪裡，只要你能找到。這里就存儲 localStorage 中了，在 Chorme86 中你甚至可以存到一個本地的文本文件中，只不過讀取速度比較慢罷了。
除了 token，我們還要將用戶信息存下來，比如首頁展示用的用戶頭像等信息。
關於本地信息的安全性問題，本地保存的用戶信息並不作為數據請求的憑證，僅供展示使用，當用戶更改本地的用戶信息對於登錄的狀態不會有影響，因為後端的判斷依據是 token，token 有效就登錄成功，而不是說本地存儲的用戶信息是誰服務端就認為你是誰，前端是不可信的。這種登錄方式的危險點在於用戶 token 被盜，但這很難避免，最不安全的是人。。。
登錄成功，返回首頁，用戶名或者是用戶頭像並沒有同步更新，這是因為，這里是單頁應用，你在 login 頁面將登錄用戶信息存到 localStorage 中，然後跳轉到了首頁，此時頁面沒有刷新，而 localStorage 中的信息沒有及時更新到 DOM 中，此時的用戶信息還是你沒有進入 login 頁面的用戶信息，自然是無法展示的，怎麼解決呢？很簡單，刷新一下。
當頁面刷新時，用戶信息會從 localStorage 中讀取，顯示的就是現在的登錄用戶了，但。。。
我不想刷新。
也很簡單，搞成響應式數據就好了呀。來人呀，上Vuex。
當你將 token 存在 cookie 中，前端並不需要主動設置，默認就攜帶傳給了服務端，而這里我們存到 Authorization 中，就需要我們設置一下，攔截請求，在請求發送前添加 token。
好的，來捋一捋流程。
用戶訪問 /login，被前端路由處理，指向Login.vue，用戶看到登錄框，填入自己的賬號，當用戶填寫賬號時，name password被實時監聽，同時會對登錄按鈕的可操作產生影響，只有當用戶將賬密輸入完整時，登錄按鈕可用。
前端收集用戶信息，調用 network 中封裝的 longin 請求函數，該請求發送前被攔截，添加 token，可能為空，使用賬密登錄時，token沒實際效用。
後端檢查成功給響應，前端將響應中數據的 token 通過觸發 mutations 更新 Vuex 中 state，同時，將該 token 存到 localStorage，以免用戶關掉頁面導致 token 丟失。
登錄成功跳到應用首頁，用戶頭像等信息通過 Vuex 獲取，因為 Vuex 中的數據是響應式的，此時從 login 跳轉到首頁，用戶頭像等信息也會得到相應的更新。
當用戶新增文章時，只需向伺服器傳文章數據就可以了，而對於文章作者的相關信息則由後端從請求頭中的 token 解析得到，這里需要注意，前端不要將本地的用戶信息作為准確的作者信息，對於用戶可以偽造的信息要做最小化的信任，用戶完全有能力將本地用戶名從張三改為李四，而最終作者是那個則需要由用戶提供的 token 來判定，雖說 token 也有可能被偽造，但難度相對較大，往往是被竊取的可能性更大。
無密碼登錄其實還是需要「密碼」的，只不過是換了一個臨時性的對人不可讀的字元串來代替罷了，並且每次請求幫你填好了。
在不考慮安全性的情況下本質上其實就是你將密碼存到了瀏覽器里，然後你每次訪問網站時讓瀏覽器幫你輸入用戶名和密碼，這個過程你是無感知的，這樣自己就不用像個憨憨一樣每次刷新就要填一遍表單。
填表是一件非常無聊的事。
要學一波 TypeScript 了呀。
㈧ 前後端分離項目——登錄Token校驗思路
對token的校驗分為前端和後端
前端： Vue-Cli 2.x + axios
後端：SpringBoot 2.3.4
這里的話，userToken和userId放到sessionStorage是關鍵步驟
後端主要是使用攔截器來進行請求的攔截和校驗
解釋一下思路：
這里的話，針對需要攔截的路徑和需要放行的路徑進行配置就行
關於redisTemple的引入這里就不再贅述。
到這里為止，前後端的token就都做完了，後面就再講講前端的一些其他思路吧
對於登錄狀態的判斷，前端可以在router.foreach上對路由進行狀態判定，從而實現頁面程度的攔截（具體可以參考最後的參考文章2）
在使用攔截器後，會發現前端部分請求會無法正常到達後端，網路後發現是因為 axios發送正式請求前會先發送一個嗅探請求 ，而嗅探請求是不攜帶我們封裝的header的，所以會導致部分請求會無法成功，解決的方式有很多種，這里的話是選擇了在後端去直接處理
參考文章
1、SpringBoot加了攔截器後出現的跨域問題解析
https://blog.csdn.net/mrkorbin/article/details/104066979
2、Vue項目中實現用戶登錄及token驗證
https://www.cnblogs.com/web-record/p/9876916.html
㈨ 抖音token登錄的原理
抖音token登錄的原理：
token就相當於客戶端登錄的賬號的唯一標識，在做一些數據請求的時候，後台會要求在請求頭中攜帶token，如果沒有token，或者token過期了，那麼這時候就會對這個客戶端進行返回響應的數據，然後前端在解析這些數據，判斷是token過期，還是沒有攜帶token，然後讓用戶進行相應的操作。總而言之，token是在向後台請求數據的時候必不可少的。如果沒有token，那麼後台要麼不會返回響應的數據，要麼就會返回一些無關緊要的數據。
簡單token的組成；uid(用戶唯一的身份標識)、time(當前時間的時間戳)、sign（簽名，token的前幾位以哈希演算法壓縮成的一定長度的十六進制字元串。為防止token泄露）。