摘要：服務(wù)器檢查該，以此來(lái)辨認(rèn)用戶狀態(tài)。如果為，表示刪除該。防篡改簽名服務(wù)器為每個(gè)項(xiàng)生成簽名。服務(wù)端根據(jù)接收到的內(nèi)容和簽名，校驗(yàn)內(nèi)容是否被篡改。算法得到的簽名和請(qǐng)求中數(shù)據(jù)的簽名不一致，則證明數(shù)據(jù)被篡改。

隨著互聯(lián)網(wǎng)的不斷發(fā)展，無(wú)論是網(wǎng)站還是app，一般都會(huì)要求用戶注冊(cè)/登錄。主要的登錄方式有賬戶密碼登錄、第三方登錄（微信登錄、QQ登錄、微博登錄等）

登錄可分為三個(gè)階段（登錄驗(yàn)證、登錄持續(xù)、退出登錄）；
登錄驗(yàn)證指客戶端提供賬號(hào)/密碼（或第三方平臺(tái)（微信、qq）獲取openid/unionid）向服務(wù)器提出登錄請(qǐng)求，服務(wù)器應(yīng)答請(qǐng)求判斷能否登錄并返回相應(yīng)數(shù)據(jù)；
登錄持續(xù)指客戶端登錄后， 服務(wù)器能夠分辨出已登錄的客戶端，并為其持續(xù)提供登錄權(quán)限的服務(wù)器。
退出登錄指客戶端退出登錄狀態(tài)。

由于HTTP是一種無(wú)狀態(tài)的協(xié)議，服務(wù)器單從網(wǎng)絡(luò)連接上無(wú)從知道客戶身份。怎么辦呢？就給客戶端們頒發(fā)一個(gè)通行證吧，每人一個(gè)，無(wú)論誰(shuí)訪問(wèn)都必須攜帶自己通行證

方案：客戶端登錄成功后， 服務(wù)器為其分配一個(gè)唯一的憑證, 客戶端每次請(qǐng)求資源時(shí)都帶上這個(gè)憑證；

實(shí)現(xiàn)方案

cookie 會(huì)話機(jī)制

session 會(huì)話機(jī)制

token 會(huì)話機(jī)制

Cookie實(shí)際上是一小段的文本信息。客戶端請(qǐng)求服務(wù)器，如果服務(wù)器需要記錄該用戶狀態(tài)，就使用response向客戶端瀏覽器頒發(fā)一個(gè)Cookie。客戶端瀏覽器會(huì)把Cookie保存起來(lái)。當(dāng)瀏覽器再請(qǐng)求該網(wǎng)站時(shí)，瀏覽器把請(qǐng)求的網(wǎng)址連同該Cookie一同提交給服務(wù)器。服務(wù)器檢查該Cookie，以此來(lái)辨認(rèn)用戶狀態(tài)。服務(wù)器還可以根據(jù)需要修改Cookie的內(nèi)容。

cookie其實(shí)是補(bǔ)充http協(xié)議的無(wú)狀態(tài)性的缺點(diǎn)，底層是通過(guò)服務(wù)器端在http響應(yīng)消息中增加set-cookie字段來(lái)將cookie信息發(fā)送給瀏覽器端，因?yàn)樗荒艽?k，一般用來(lái)存瀏覽器的身份信息，瀏覽器在訪問(wèn)服務(wù)器的某些資源的時(shí)候，會(huì)在http請(qǐng)求頭中將cookie數(shù)據(jù)傳給服務(wù)器，這樣服務(wù)器就知道是誰(shuí)請(qǐng)求的了，但是如果用戶清除了cookie，那就啥都沒(méi)有了

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

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

如果為負(fù)數(shù)，該Cookie為臨時(shí)Cookie，關(guān)閉瀏覽器即失效(會(huì)話級(jí)別Cookie)，瀏覽器也不會(huì)以任何形式保存該Cookie。

如果為0，表示刪除該Cookie。默認(rèn)為–1;

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

如果我們?cè)谟蛎鸄中的Cookie的domain設(shè)置為.f.com，那么.f.com及其子域名都可以獲取這個(gè)Cookie，即域名A和域名B都可以獲取這個(gè)Cookie

如果域名A沒(méi)有顯式設(shè)置Cookie的domain方法，那么domain就為.b.f.com，不一樣的是，這時(shí)，域名A的子域名將無(wú)法獲取這個(gè)Cookie

HttpOnly: 這個(gè)屬性是面試的時(shí)候?？嫉模绻@個(gè)屬性設(shè)置為true，就不能通過(guò)js腳本來(lái)獲取cookie的值，能有效的防止xss攻擊

封裝cookie的常用操作方法

設(shè)置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"); // 設(shè)置cookie
console.log(CookieUtil.getItem("name"));//讀取cookie
CookieUtil.unset("name")//刪除cookie

因?yàn)镃ookie是存儲(chǔ)在客戶端，用戶可以隨意修改。所以，存在一定的安全隱患。
防篡改簽名：服務(wù)器為每個(gè)Cookie項(xiàng)生成簽名。如果用戶篡改Cookie，則與簽名無(wú)法對(duì)應(yīng)上。以此，來(lái)判斷數(shù)據(jù)是否被篡改。

原理如下：

服務(wù)端提供一個(gè)簽名生成算法secret

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

將生成的簽名放入對(duì)應(yīng)的Cookie項(xiàng)username=wall|34Yult8i。其中，內(nèi)容和簽名用|隔開。

服務(wù)端根據(jù)接收到的內(nèi)容和簽名，校驗(yàn)內(nèi)容是否被篡改。

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

session是一種服務(wù)器機(jī)制，是存儲(chǔ)在服務(wù)器上的信息，主要配合cookie完成瀏覽器的身份認(rèn)證和狀態(tài)存儲(chǔ)方式多種多樣，可以是服務(wù)器的內(nèi)存中，或者是mongo數(shù)據(jù)庫(kù)，redis內(nèi)存數(shù)據(jù)庫(kù)中。為了獲得更高的存取速度，服務(wù)器一般把Session放在內(nèi)存里。每個(gè)用戶都會(huì)有一個(gè)獨(dú)立的Session。如果Session內(nèi)容過(guò)于復(fù)雜，當(dāng)大量客戶訪問(wèn)服務(wù)器時(shí)可能會(huì)導(dǎo)致內(nèi)存溢出。因此，Session里的信息應(yīng)該盡量精簡(jiǎn)。

Session相對(duì)于cookie較安全點(diǎn)，當(dāng)用戶請(qǐng)求服務(wù)器的時(shí)候，服務(wù)器會(huì)把數(shù)據(jù)臨時(shí)存下來(lái)，如果退出網(wǎng)站后，session會(huì)被銷毀。

Session是基于cookie實(shí)現(xiàn)的，瀏覽器第一次訪問(wèn)服務(wù)器時(shí)，服務(wù)器創(chuàng)建一個(gè)Session，同時(shí)生成一個(gè)唯一的會(huì)話key，即sessionID。接著sessionID及session分別作為key和value保存到緩存中，也可以保存到數(shù)據(jù)庫(kù)中，然后服務(wù)器把sessionID通過(guò)set-cookie的方式寫入瀏覽器，瀏覽器下次訪問(wèn)服務(wù)器時(shí)直接攜帶上cookie中的sessionID，服務(wù)器再根據(jù)sessionID找到對(duì)應(yīng)的session進(jìn)行匹配，來(lái)判斷用戶是否登錄

【1】 客戶端發(fā)起登錄請(qǐng)求，服務(wù)器端創(chuàng)建session，并通過(guò)set-cookie將生成的sessionID寫入的客戶端的cookie中。
【2】 在發(fā)起其他需要權(quán)限的接口的時(shí)候，客戶端的請(qǐng)求體的Header部分會(huì)攜帶sessionID發(fā)送給服務(wù)端。然后根據(jù)這個(gè)sessionId去找服務(wù)器端保存的該客戶端的session，然后判斷該請(qǐng)求是否合法。

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

瀏覽器第一次訪問(wèn)服務(wù)器，根據(jù)傳過(guò)來(lái)的唯一標(biāo)識(shí)userId，服務(wù)端會(huì)通過(guò)一些算法，如常用的HMAC-SHA256算法，然后加一個(gè)密鑰，生成一個(gè)token，然后通過(guò)BASE64編碼一下之后將這個(gè)token發(fā)送給客戶端；客戶端將token保存起來(lái)，下次請(qǐng)求時(shí)，帶著token，服務(wù)器收到請(qǐng)求后，然后會(huì)用相同的算法和密鑰去驗(yàn)證token，如果通過(guò)，執(zhí)行業(yè)務(wù)操作，不通過(guò)，返回不通過(guò)信息；

瀏覽器第一次訪問(wèn)服務(wù)器時(shí)，服務(wù)器根據(jù)傳過(guò)來(lái)的唯一標(biāo)識(shí)userId，通過(guò)一些算法，加一個(gè)密鑰，生成一個(gè)token，接著通過(guò)base64編碼將token返回給客戶端。客戶端將token保存起來(lái)，下次請(qǐng)求時(shí)需要帶著token，服務(wù)器收到請(qǐng)求后，用相同的算法和密鑰去驗(yàn)證token

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

sessionID是基于cookie實(shí)現(xiàn)的，而token不需要基于cookie。這就導(dǎo)致了sessionID只能用在瀏覽器上，對(duì)于原生的應(yīng)用無(wú)法實(shí)現(xiàn)。原生的應(yīng)用是不具備cookie的特性的。另外sessionID可以實(shí)現(xiàn)服務(wù)端注銷會(huì)話，而token不能(當(dāng)然你可以把用戶登陸的token存入到redis中，但是不推薦token入庫(kù))

Token作為用戶認(rèn)證的處理方式，有幾個(gè)優(yōu)點(diǎn)：

無(wú)狀態(tài)，可擴(kuò)展：不會(huì)在服務(wù)端存儲(chǔ)用戶的登錄狀態(tài)，可以很容易的實(shí)現(xiàn)服務(wù)器的增減

支持移動(dòng)設(shè)備，對(duì)多類型客戶端的支持良好

支持跨程序調(diào)用，各個(gè)接口之間的調(diào)用更方便

安全可靠

JSON web Token,簡(jiǎn)稱JWT，本質(zhì)是一個(gè)token，是一種緊湊的URL安全方法，用于在網(wǎng)絡(luò)通信的雙方之間傳遞。一般放在HTTP的headers參數(shù)里面的authorization里面，值的前面加Bearer關(guān)鍵字和空格。除此之外，也可以在url和request body中傳遞。

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

如果你覺(jué)得這篇文章對(duì)你有所幫助，那就順便點(diǎn)個(gè)贊吧，點(diǎn)點(diǎn)關(guān)注不迷路~

黑芝麻哇，白芝麻發(fā)，黑芝麻白芝麻哇發(fā)哈！

前端哇發(fā)哈