目前絕大多數的系統都少不了登錄驗證的功能，這主要是為了保存用戶的狀態，以此來限制用戶的各種行為，從而方便有效的控制用戶的權限。比如一個用戶登陸微博，發布、關注、評論的操作都應是在登錄后的用戶狀態下進行的。
實現登錄驗證的功能主要有Cookie&Session、JWT兩種方式，這一節我們將先對 Cookie&Session的工作原理 做詳細的介紹，在之后的文章中會陸續對JWT，以及如何使用Cookie&Session和JWT來完善前幾節我們搭建的簡易用戶管理系統進行講解。
Cookie&Session
我們知道，HTTP 是無狀態的。也就是說，HTTP 請求方和響應方間無法維護狀態，都是一次性的，它不知道前后的請求都發生了什么。但有的場景下，我們需要維護狀態。最典型的，一個用戶登陸微博，發布、關注、評論，都應是在登錄后的用戶狀態下的。
這個時候就可以引入Cookie與Session來保存用戶的登錄狀態。
本篇文章主要介紹使用
Cookie-Session來做登錄驗證的工作原理，關于Cookie與Session的詳細介紹可查閱這位大佬的文章：Cookie和Session詳解
為什么不單獨使用Cookie？
Cookie是存放在瀏覽器中的，可以在瀏覽器中打開控制臺，選擇應用，找到存儲中的Cookie進行查看：
當客戶端向服務端發送網絡請求時瀏覽器會自動將Cookie添加到請求頭中，這樣服務端就能獲取這個Cookie，如下：
知道了這個原理后，我們就可以想到，如果在用戶登錄系統時：客戶端由用戶的部分登錄信息（比如username、id等）生成一個Cookie存放到瀏覽器中，那么在這之后的每一次網絡請求都會自動攜帶上該Cookie。
之后讓服務端根據請求中是否攜帶Cookie并且攜帶的Cookie中是否存在有效的username、id來判斷用戶是否已經登錄過了，這樣一來用戶的登錄狀態不就被保存下來了嗎。
回到上面我們提到的微博的例子，按照這種過程來說，當用戶登錄過后Cookie已經被保存，這時當用戶進行發布、關注、評論等需要登錄才能使用的操作時我們就能提前判斷是否存在Cookie，如果存在并且Cookie中含有該用戶的id，那么我們就可以允許該用戶的這些操作（這些操作一般都是需要用戶的id的，這時就可以從Cookie中進行獲取）。相反的，如果Cookie不存在或者Cookie無效，那么就禁止該用戶的這些操作。
說到這，你可能會問：既然一個Cookie就能實現我們想要的效果，那為何還要使用Session呢？
這是因為 Cookie很容易被偽造！ ，如果我們知道了Cookie中存放的信息是username和id（就算不知道，也可以在登錄后的網絡請求的請求體中找到Cookie），那么我們完全可以在不登錄的情況下手動向瀏覽器存儲一個偽造的Cookie：
說到這，你應該就能明白為什么不能單獨使用Cookie了吧。
Session是如何與Cookie結合的？
Session其實是基于Cookie實現的，并且Session存儲在服務端的內存或者數據庫中。
當用戶登錄成功時，使用Cookie&Session的登錄驗證會進行以下操作：
由服務端生成
Session與SessionId；
Session一般是根據用戶登錄的信息，如用戶名、id等進行生成。如果把
Session比作是一把鎖，那么SessionId就相當于是這把鎖的鑰匙。服務端將
Session存儲到內存或者數據庫中；服務端將
SessionId存放到請求的響應頭（response對象）中的Set-Cookie字段中發送給客戶端；客戶端收到
Set-Cookie后會自動將Set-Cookie的值（也就是SessionId）存放到Cookie中；之后的每次網絡請求都會自動帶上
Cookie，也就是帶上這個SessionId；服務端收到后續請求時獲取請求上的
Cookie，也就是獲取到了SessionId，然后通過SessionId查詢并校驗服務端存儲的Session，若校驗成功說明這個SessionId有效則通過此次請求，反之則阻止此次請求。
圖示：
Cookie&Session的缺陷
存儲問題
為了保存用戶的登錄狀態，我們需要為每一位登錄的用戶生成并存儲Session，這勢必就會造成以下問題：
如果Session存放到內存中，那么當服務端重啟時，這些內存中的Session都將被清除，那么所有用戶的登錄狀態都將會過期，并且當用戶量較大時，過多的內存占用也勢必會影響服務端的性能。
如果Session存放到數據庫中，雖然能夠解決因服務端重啟造成用戶登錄狀態過期的問題，但當用戶量較大時，對于這個數據庫的維護也會變得相對困難。
如果前端頁面中調用的接口來自兩個服務器（也就是兩套數據庫），為了實現Session在兩個服務器間共享通常會將Session存放到一個單獨的數據庫中，這樣就使得整個項目變得更為復雜也更加難以維護。
CSRF問題
CSRF全稱為 Cross-site request forgery 即 跨站請求偽造，使用Cookie進行驗證的網站都會面臨或大或小的CSRF威脅，我們以一個銀行網站的例子來介紹CSRF的攻擊原理：
假如一家銀行網站A的登錄驗證采用的是Cookie&Session，并且該網站上用以運行轉賬操作的Api地址為：http://www.grillbankapi.com/?account=AccoutName&amount=1000
api參數：account代表賬戶名，amount代表轉賬金額。
那么，一個惡意攻擊者可以在另一個網站B上放置如下代碼：
<img src="http://www.grillbankapi.com/?account=Ailjx&amount=1000">
注意：img標簽的src是網站A轉賬操作的api地址，并且參數account為Ailjx，amount為1000，也就是說這個api地址相當于是賬戶名為 Ailjx 轉賬1000 時調用的api。
如果有賬戶名為 Ailjx 的用戶剛訪問過網站A不久，登錄信息尚未過期（網站A的Cookie存在且有效）。
那么當 Ailjx 訪問了這個惡意網站B時，上面的img標簽將被加載，瀏覽器就會自動請求img標簽的src路由，也就是請求http://www.grillbankapi.com/?account=Ailjx&amount=1000 （我們將這個請求記為請求Q），并且因為Cookie存放在瀏覽器中且瀏覽器發送請求時會自動帶上Cookie，所以請求Q上就會自動攜帶 Ailjx 在網站A上的Cookie憑證，結果就是這個 請求Q將會被通過，那么 Ailjx 就會損失1000資金。
這種惡意的網址可以有很多種形式，藏身于網頁中的許多地方。 此外，攻擊者也不需要控制放置惡意網址的網站。例如他可以將這種地址藏在論壇，博客等任何用戶生成內容的網站中。這意味著如果服務端沒有合適的防御措施的話，用戶即使訪問熟悉的可信網站也有受攻擊的危險。
透過例子能夠看出，攻擊者并不能通過CSRF攻擊來直接獲取用戶的賬戶控制權，也不能直接竊取用戶的任何信息。他們能做到的，是欺騙用戶瀏覽器，讓其以用戶的名義運行操作。
這些就是使用Cookie&Session來做登錄驗證的問題所在，那么我們如何解決這些問題呢？這就需要引入JWT的概念，使用token來做登錄驗證，這些我們將在之后的文章中進行講解。
