實現(xiàn)用戶登錄認證的方式常見的有兩種：一種是基于 cookie 的認證微饥，另外一種是基于 token 的認證。
傳統(tǒng)的基于 cookie 的認證方式
基本有下面幾個步驟：
用戶輸入用戶名和密碼素挽，發(fā)送給服務(wù)器
服務(wù)器驗證一下用戶名和密碼掷伙，正確的話就創(chuàng)建一個會話（ session ）
-
同時會把這個會話的 ID 保存到客戶端瀏覽器中，因為保存的地方是瀏覽器的 cookie 献联，所以這種認證方式叫做基于 cookie
的認證方式
后續(xù)的請求中茴恰，瀏覽器會發(fā)送會話 ID 到服務(wù)器销钝，服務(wù)器上如果能找到對應(yīng) ID 的會話，那么服務(wù)器就會返回需要的數(shù)據(jù)給瀏覽器
當用戶退出登錄琐簇，會話會同時在客戶端和服務(wù)器端被銷毀
多年以來這種方式都是很流行的蒸健，例如座享，前幾年我使用 Ruby On Rails 做開發(fā)，這個是 Rails 默認的認證方式似忧。
當代的基于 token 的認證方式
對比上面的方式渣叛，有比較明顯的不同：
- 用戶輸入用戶名密碼，發(fā)送給服務(wù)器
- 服務(wù)器驗證一下用戶名和密碼盯捌，正確的話就返回一個簽名過的 token（ token 可以認為就是個長長的字符串）
- 客戶端瀏覽器拿到這個 token
- 后續(xù)每次請求中淳衙，瀏覽器會把 token 作為 http header 發(fā)送給服務(wù)器
- 服務(wù)器可以驗證一下簽名是否有效，如果有效那么認證就成功了饺著，可以返回客戶端需要的數(shù)據(jù)
- 這種方式的特點就是客戶端的 token 中自己保留有大量信息箫攀，服務(wù)器沒有存儲這些信息，而只負責驗證
- 所以一旦用戶退出登錄幼衰，只需要客戶端銷毀一下 token 即可靴跛，服務(wù)器端不需要有任何操作
我們做當代的 nodejs 開發(fā)，一般都用這樣的方式進行認證渡嚣∩揖Γ基于 token 的認證，一般會用到 JWT 技術(shù)识椰，我們下一集里面詳細介紹一下 JWT 绝葡。
為何我們的項目會采用后者？
簡單來說一句話：
基于 Token 的認證方式才適合像 Angular, React, Vue 這樣的 SPA（單頁面應(yīng)用）框架腹鹉。
具體來說藏畅，cookie-based 的方案有以下缺點：
- 服務(wù)器端要為每個用戶保留 session 信息，連接用戶多了功咒，服務(wù)器內(nèi)存壓力巨大
- 適合單一域名愉阎，不適合第三方請求的形式，這個在當代是個大問題
token-based 的方案的優(yōu)勢是：
- 讓我們的后臺 API 更容易被移動 App 使用
- token 自己存儲所有需要的各種信息航瞭，每次認證的時候服務(wù)器上不必進行數(shù)據(jù)庫查詢诫硕，執(zhí)行效率大大提高
參考
- https://auth0.com/blog/cookies-vs-tokens-definitive-guide/
- https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication
文章來源：好奇貓
