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