摘要：服務器檢查該，以此來辨認用戶狀態。如果為，表示刪除該。防篡改簽名服務器為每個項生成簽名。服務端根據接收到的內容和簽名，校驗內容是否被篡改。算法得到的簽名和請求中數據的簽名不一致，則證明數據被篡改。

隨著互聯網的不斷發展，無論是網站還是app，一般都會要求用戶注冊/登錄。主要的登錄方式有賬戶密碼登錄、第三方登錄（微信登錄、QQ登錄、微博登錄等）

登錄可分為三個階段（登錄驗證、登錄持續、退出登錄）；
登錄驗證指客戶端提供賬號/密碼（或第三方平臺（微信、qq）獲取openid/unionid）向服務器提出登錄請求，服務器應答請求判斷能否登錄并返回相應數據；
登錄持續指客戶端登錄后， 服務器能夠分辨出已登錄的客戶端，并為其持續提供登錄權限的服務器。
退出登錄指客戶端退出登錄狀態。

由于HTTP是一種無狀態的協議，服務器單從網絡連接上無從知道客戶身份。怎么辦呢？就給客戶端們頒發一個通行證吧，每人一個，無論誰訪問都必須攜帶自己通行證

方案：客戶端登錄成功后， 服務器為其分配一個唯一的憑證, 客戶端每次請求資源時都帶上這個憑證；

實現方案

cookie 會話機制

session 會話機制

token 會話機制

Cookie實際上是一小段的文本信息。客戶端請求服務器，如果服務器需要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個Cookie。客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給服務器。服務器檢查該Cookie，以此來辨認用戶狀態。服務器還可以根據需要修改Cookie的內容。

cookie其實是補充http協議的無狀態性的缺點，底層是通過服務器端在http響應消息中增加set-cookie字段來將cookie信息發送給瀏覽器端，因為它只能存4k，一般用來存瀏覽器的身份信息，瀏覽器在訪問服務器的某些資源的時候，會在http請求頭中將cookie數據傳給服務器，這樣服務器就知道是誰請求的了，但是如果用戶清除了cookie，那就啥都沒有了

1、Expires:該Cookie失效的時間，單位秒。

如果為正數，則該Cookie在maxAge秒之后失效(持久級別Cookie)。

如果為負數，該Cookie為臨時Cookie，關閉瀏覽器即失效(會話級別Cookie)，瀏覽器也不會以任何形式保存該Cookie。

如果為0，表示刪除該Cookie。默認為–1;

2、Domain:
我們現在有二個域名。域名A：b.f.com，域名B：d.f.com；顯然域名A和域名B都是f.com的子域名

如果我們在域名A中的Cookie的domain設置為.f.com，那么.f.com及其子域名都可以獲取這個Cookie，即域名A和域名B都可以獲取這個Cookie

如果域名A沒有顯式設置Cookie的domain方法，那么domain就為.b.f.com，不一樣的是，這時，域名A的子域名將無法獲取這個Cookie

HttpOnly: 這個屬性是面試的時候常考的，如果這個屬性設置為true，就不能通過js腳本來獲取cookie的值，能有效的防止xss攻擊

封裝cookie的常用操作方法

設置cookie

讀取cookie

刪除cookie

var cookieUtil = {
    getItem: function (name) {
        var cookieName = encodeURIComponent(name) + "=",
            cookieStart = document.cookie.indexOf(cookieName),
            cookieValue = null;
        if (cookieStart > -1) {
            var cookieEnd = document.cookie.indexOf(";", cookieStart);
            if (cookieEnd == 1) {
                cookieEnd = document.cookie.length;
            }
            cookieValue = decodeURIComponent(document.cookie.substring(cookieStart + cookieName.length, cookieEnd))
        }
        return cookieValue;
    },
    setItem: function (name, value, expires, path, domain, secure) {
        var cookieText = encodeURIComponent(name) + "=" + encodeURIComponent(value);
        if (expires) {
            cookieText += ";expires=" + expires.toGMTString();
        }
        if (path) {
            cookieText += ";path=" + path;
        }
        if (domain) {
            cookieText += ";domain=" + domain;
        }
        if (secure) {
            cookieText += ";secure";
        }
        document.cookie = cookieText;
    },
    unset: function (name, path, domain, secure) {
        this.setItem(name, "", new Date(0), path, domain, secure)
    }
}
CookieUtil.setItem("name", "tom"); // 設置cookie
console.log(CookieUtil.getItem("name"));//讀取cookie
CookieUtil.unset("name")//刪除cookie

因為Cookie是存儲在客戶端，用戶可以隨意修改。所以，存在一定的安全隱患。
防篡改簽名：服務器為每個Cookie項生成簽名。如果用戶篡改Cookie，則與簽名無法對應上。以此，來判斷數據是否被篡改。

原理如下：

服務端提供一個簽名生成算法secret

根據方法生成簽名secret(wall)=34Yult8i

將生成的簽名放入對應的Cookie項username=wall|34Yult8i。其中，內容和簽名用|隔開。

服務端根據接收到的內容和簽名，校驗內容是否被篡改。

舉個栗子：
比如服務器接收到請求中的Cookie項username=pony|34Yult8i，然后使用簽名生成算法secret(pony)=666。 算法得到的簽名666和請求中數據的簽名不一致，則證明數據被篡改。

session是一種服務器機制，是存儲在服務器上的信息，主要配合cookie完成瀏覽器的身份認證和狀態存儲方式多種多樣，可以是服務器的內存中，或者是mongo數據庫，redis內存數據庫中。為了獲得更高的存取速度，服務器一般把Session放在內存里。每個用戶都會有一個獨立的Session。如果Session內容過于復雜，當大量客戶訪問服務器時可能會導致內存溢出。因此，Session里的信息應該盡量精簡。

Session相對于cookie較安全點，當用戶請求服務器的時候，服務器會把數據臨時存下來，如果退出網站后，session會被銷毀。

Session是基于cookie實現的，瀏覽器第一次訪問服務器時，服務器創建一個Session，同時生成一個唯一的會話key，即sessionID。接著sessionID及session分別作為key和value保存到緩存中，也可以保存到數據庫中，然后服務器把sessionID通過set-cookie的方式寫入瀏覽器，瀏覽器下次訪問服務器時直接攜帶上cookie中的sessionID，服務器再根據sessionID找到對應的session進行匹配，來判斷用戶是否登錄

【1】 客戶端發起登錄請求，服務器端創建session，并通過set-cookie將生成的sessionID寫入的客戶端的cookie中。
【2】 在發起其他需要權限的接口的時候，客戶端的請求體的Header部分會攜帶sessionID發送給服務端。然后根據這個sessionId去找服務器端保存的該客戶端的session，然后判斷該請求是否合法。

token的意思是“令牌”，是用戶身份的驗證方式，最簡單的token組成:uid(用戶唯一的身份標識)、time(當前時間的時間戳)、sign(簽名，由token的前幾位+鹽以哈希算法壓縮成一定長的十六進制字符串，可以防止惡意第三方拼接token請求服務器)。還可以把不變的參數也放進token，避免多次查庫

瀏覽器第一次訪問服務器，根據傳過來的唯一標識userId，服務端會通過一些算法，如常用的HMAC-SHA256算法，然后加一個密鑰，生成一個token，然后通過BASE64編碼一下之后將這個token發送給客戶端；客戶端將token保存起來，下次請求時，帶著token，服務器收到請求后，然后會用相同的算法和密鑰去驗證token，如果通過，執行業務操作，不通過，返回不通過信息；

瀏覽器第一次訪問服務器時，服務器根據傳過來的唯一標識userId，通過一些算法，加一個密鑰，生成一個token，接著通過base64編碼將token返回給客戶端。客戶端將token保存起來，下次請求時需要帶著token，服務器收到請求后，用相同的算法和密鑰去驗證token

token和session其實都是為了身份驗證，session一般翻譯為會話，而token更多的時候是翻譯為令牌；
session服務器會保存一份，可能保存到緩存，文件，數據庫；同樣，session和token都是有過期時間一說，都需要去管理過期時間；
其實token與session的問題是一種時間與空間的博弈問題，session是空間換時間，而token是時間換空間。兩者的選擇要看具體情況而定。
雖然確實都是“客戶端記錄，每次訪問攜帶”，但 token 很容易設計為自包含的，也就是說，后端不需要記錄什么東西，每次一個無狀態請求，每次解密驗證，每次當場得出合法 /非法的結論。這一切判斷依據，除了固化在 CS 兩端的一些邏輯之外，整個信息是自包含的。這才是真正的無狀態。
而 sessionid ，一般都是一段隨機字符串，需要到后端去檢索 id 的有效性。萬一服務器重啟導致內存里的 session 沒了呢？萬一 redis 服務器掛了呢？

sessionID是基于cookie實現的，而token不需要基于cookie。這就導致了sessionID只能用在瀏覽器上，對于原生的應用無法實現。原生的應用是不具備cookie的特性的。另外sessionID可以實現服務端注銷會話，而token不能(當然你可以把用戶登陸的token存入到redis中，但是不推薦token入庫)

Token作為用戶認證的處理方式，有幾個優點：

無狀態，可擴展：不會在服務端存儲用戶的登錄狀態，可以很容易的實現服務器的增減

支持移動設備，對多類型客戶端的支持良好

支持跨程序調用，各個接口之間的調用更方便

安全可靠

JSON web Token,簡稱JWT，本質是一個token，是一種緊湊的URL安全方法，用于在網絡通信的雙方之間傳遞。一般放在HTTP的headers參數里面的authorization里面，值的前面加Bearer關鍵字和空格。除此之外，也可以在url和request body中傳遞。

Json web token (JWT), 是為了在網絡應用環境間傳遞聲明而執行的一種基于JSON的開放標準（(RFC 7519).該token被設計為緊湊且安全的，特別適用于分布式站點的單點登錄（SSO）場景。JWT的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便于從資源服務器獲取資源，也可以增加一些額外的其它業務邏輯所必須的聲明信息，該token也可直接被用于認證，也可被加密。

如果你覺得這篇文章對你有所幫助，那就順便點個贊吧，點點關注不迷路~

黑芝麻哇，白芝麻發，黑芝麻白芝麻哇發哈！

前端哇發哈