原文鏈接：前后端接口鑒權全解

不知不覺也寫得比較長了，一次看不完建議收藏夾！本文主要解釋與請求狀態相關的術語（cookie、session、token）和幾種常見登錄的實現方式，希望大家看完本文后可以有比較清晰的理解，有感到迷惑的地方請在評論區提出。

Cookie

眾所周知，http 是無狀態協議，瀏覽器和服務器不可能憑協議的實現辨別請求的上下文。

于是 cookie 登場，既然協議本身不能分辨鏈接，那就在請求頭部手動帶著上下文信息吧。

舉個例子，以前去旅游的時候，到了景區可能會需要存放行李，被大包小包壓著，旅游也不開心啦。在存放行李后，服務員會給你一個牌子，上面寫著你的行李放在哪個格子，離開時，你就能憑這個牌子和上面的數字成功取回行李。

cookie 做的正是這么一件事，旅客就像客戶端，寄存處就像服務器，憑著寫著數字的牌子，寄存處（服務器）就能分辨出不同旅客（客戶端）。

你會不會想到，如果牌子被偷了怎么辦，cookie 也會被偷嗎？確實會，這就是一個很常被提到的網絡安全問題——CSRF。可以在這篇文章了解關于 CSRF 的成因和應對方法。

cookie 誕生初似乎是用于電商存放用戶購物車一類的數據，但現在前端擁有兩個 storage（local、session），兩種數據庫（websql、IndexedDB），根本不愁信息存放問題，所以現在基本上 100% 都是在連接上證明客戶端的身份。例如登錄之后，服務器給你一個標志，就存在 cookie 里，之后再連接時，都會自動帶上 cookie，服務器便分清誰是誰。另外，cookie 還可以用于跟蹤一個用戶，這就產生了隱私問題，于是也就有了“禁用 cookie”這個選項（然而現在這個時代禁用 cookie 是挺麻煩的事情）。

設置方式

現實世界的例子明白了，在計算機中怎么才能設置 cookie 呢？一般來說，安全起見，cookie 都是依靠 set-cookie 頭設置，且不允許 JavaScript 設置。 

Set-Cookie: <cookie-name>=<cookie-value>  
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>  
Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit>  
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>  
Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>  
Set-Cookie: <cookie-name>=<cookie-value>; Secure  
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly  
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict  
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax  
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=None; Secure  
// Multiple attributes are also possible, for example:  
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly 

其中 <cookie-name>=<cookie-value> 這樣的 kv 對，內容隨你定，另外還有 HttpOnly、SameSite 等配置，一條 Set-Cookie 只配置一項 cookie。

 

•  Expires 設置 cookie 的過期時間（時間戳），這個時間是客戶端時間。
•  Max-Age 設置 cookie 的保留時長（秒數），同時存在 Expires 和 Max-Age 的話，Max-Age 優先
•  Domain 設置生效的域名，默認就是當前域名，不包含子域名
•  Path 設置生效路徑，/ 全匹配
•  Secure 設置 cookie 只在 https 下發送，防止中間人攻擊
•  HttpOnly 設置禁止 JavaScript 訪問 cookie，防止XSS
•  SameSite 設置跨域時不攜帶 cookie，防止CSRF

Secure 和 HttpOnly 是強烈建議開啟的。SameSite 選項需要根據實際情況討論，因為 SameSite 可能會導致即使你用 CORS 解決了跨越問題，依然會因為請求沒自帶 cookie 引起一系列問題，一開始還以為是 axios 配置問題，繞了一大圈，然而根本沒關系。

其實因為 Chrome 在某一次更新后把沒設置 SameSite 默認為 Lax，你不在服務器手動把 SameSite 設置為 None 就不會自動帶 cookie 了。

發送方式

參考 MDN，cookie 的發送格式如下（其中 PHPSESSID 相關內容下面會提到）： 

Cookie: <cookie-list>  
Cookie: name=value  
Cookie: name=value; name2=value2; name3=value3  
Cookie: PHPSESSID=298zf09hf012fh2; csrftoken=u32t4o3tb3gg43; _gat=1 

在發送 cookie 時，并不會傳上面提到的配置到服務器，因為服務器在設置后就不需要關心這些信息了，只要現代瀏覽器運作正常，收到的 cookie 就是沒問題的。

Session

從 cookie 說到 session，是因為 session 才是真正的“信息”，如上面提到的，cookie 是容器，里面裝著 PHPSESSID=298zf09hf012fh2;，這就是一個 session ID。

不知道 session 和 session id 會不會讓你看得有點頭暈？

當初 session 的存在就是要為客戶端和服務器連接提供的信息，所以我將 session 理解為信息，而 session id 是獲取信息的鑰匙，通常是一串唯一的哈希碼。

接下來分析兩個 node.js express 的中間件，理解兩種 session 的實現方式。

session 信息可以儲存在客戶端，如 cookie-session，也可以儲存在服務器，如 express-session。使用 session ID 就是把 session 放在服務器里，用 cookie 里的 id 尋找服務器的信息。

客戶端儲存

對于 cookie-session 庫，比較容易理解，其實就是把所有信息加密后塞到 cookie 里。其中涉及到 cookies 庫。在設置 session 時其實就是調用 cookies.set，把信息寫到 set-cookie 里，再返回瀏覽器。換言之，取值和賦值的本質都是操作 cookie。

瀏覽器在接收到 set-cookie 頭后，會把信息寫到 cookie 里。在下次發送請求時，信息又通過 cookie 原樣帶回來，所以服務器什么東西都不用存，只負責獲取和處理 cookie 里的信息，這種實現方法不需要 session ID。

這是一段使用 cookie-session 中間件為請求添加 cookie 的代碼： 

const express = require('express')  
var cookieSession = require('cookie-session')  
const app = express()  
app.use(  
  cookieSession({  
    name: 'session',  
    keys: [  
      /* secret keys */  
      'key',  
    ],  
    // Cookie Options  
    maxAge: 24 * 60 * 60 * 1000, // 24 hours  
  })  
)  
app.get('/', function(req, res) {  
  req.session.test = 'hey'  
  res.json({ 
    wow: 'crazy',  
  })  
})  
app.listen(3001) 

在通過 app.use(cookieSession()) 使用中間件之前，請求是不會設置 cookie 的，添加后再訪問（并且在設置 req.session 后，若不添加 session 信息就沒必要寫、也沒內容寫到 cookie 里），就能看到服務器響應頭部新增了下面兩行，分別寫入 session 和 session.sig： 

Set-Cookie: session=eyJ0ZXN0IjoiaGV5In0=; path=/; expires=Tue, 23 Feb 2021 01:07:05 GMT; httponly  
Set-Cookie: session.sig=QBoXofGvnXbVoA8dDmfD-GMMM6E; path=/; expires=Tue, 23 Feb 2021 01:07:05 GMT; httponly 

然后你就能在 DevTools 的 Application 標簽看到 cookie 成功寫入。session 的值 eyJ0ZXN0IjoiaGV5In0= 通過 base64 解碼（不了解 base64 的話可以看這里）即可得到 {"test":"hey"}，這就是所謂的“將 session 信息放到客戶端”，因為 base64 編碼并不是加密，這就跟明文傳輸沒啥區別，所以請不要在客戶端 session 里放用戶密碼之類的機密信息。

即使現代瀏覽器和服務器做了一些約定，例如使用 https、跨域限制、還有上面提到 cookie 的 httponly 和 sameSite 配置等，保障了 cookie 安全。但是想想，傳輸安全保障了，如果有人偷看你電腦里的 cookie，密碼又恰好存在 cookie，那就能無聲無息地偷走密碼。相反的，只放其他信息或是僅僅證明“已登錄”標志的話，只要退出一次，這個 cookie 就失效了，算是降低了潛在危險。

說回第二個值 session.sig，它是一個 27 字節的 SHA1 簽名，用以校驗 session 是否被篡改，是 cookie 安全的又一層保障。

服務器儲存

既然要儲存在服務器，那么 express-session 就需要一個容器 store，它可以是內存、redis、mongoDB 等等等等，內存應該是最快的，但是重啟程序就沒了，redis 可以作為備選，用數據庫存 session 的場景感覺不多。

express-session 的源碼沒 cookie-session 那么簡明易懂，里面有一個有點繞的問題，req.session 到底是怎么插入的？

不關注實現可以跳過這段，有興趣的話可以跟著思路看看 express-session 的源碼。

我們可以從 .session = 這個關鍵詞開始找，找到：

•  store.generate 否決這個，容易看出這個是初始化使用的
•  Store.prototype.createSession 這個是根據 req 和 sess 參數在 req 中設置 session 屬性，沒錯，就是你了

于是全局搜索 createSession，鎖定 index 里的 inflate （就是填充的意思）函數。

最后尋找 inflate 的調用點，是使用 sessionID 為參數的 store.get 的回調函數，一切說得通啦——

在監測到客戶端送來的 cookie 之后，可以從 cookie 獲取 sessionID，再使用 id 在 store 中獲取 session 信息，掛到 req.session，經過這個中間件，你就能順利地使用 req 中的 session。

那賦值怎么辦呢？這就和上面儲存在客戶端不同了，上面要修改客戶端 cookie 信息，但是對于儲存在服務器的情況，你修改了 session 那就是“實實在在地修改”了嘛，不用其他花里胡哨的方法，內存中的信息就是修改了，下次獲取內存里的對應信息也是修改后的信息。（僅限于內存的實現方式，使用數據庫時仍需要額外的寫入）

在請求沒有 session id 的情況下，通過 store.generate 創建新的 session，在你寫 session 的時候，cookie 可以不改變，只要根據原來的 cookie 訪問內存里的 session 信息就可以了。 

var express = require('express')  
var parseurl = require('parseurl')  
var session = require('express-session')  
var app = express()  
app.use(  
  session({  
    secret: 'keyboard cat',  
    resave: false,  
    saveUninitialized: true,  
  })  
)  
app.use(function(req, res, next) {  
  if (!req.session.views) {  
    req.session.views = {}  
  }  
  // get the url pathname  
  var pathname = parseurl(req).pathname  
  // count the views  
  req.session.views[pathname] = (req.session.views[pathname] || 0) + 1  
  next()  
})  
app.get('/foo', function(req, res, next) {  
  res.json({  
    session: req.session,  
  })  
})   
app.get('/bar', function(req, res, next) {  
  res.send('you viewed this page ' + req.session.views['/bar'] + ' times')  
})  
app.listen(3001) 

兩種儲存方式的對比

首先還是計算機世界最重要的哲學問題：時間和空間的抉擇。

儲存在客戶端的情況，解放了服務器存放 session 的內存，但是每次都帶上一堆 base64 處理的 session 信息，如果量大的話傳輸就會很緩慢。

儲存在服務器相反，用服務器的內存拯救了帶寬。

另外，在退出登錄的實現和結果，也是有區別的。

儲存在服務器的情況就很簡單，如果 req.session.isLogin = true 是登錄，那么 req.session.isLogin = false 就是退出。

但是狀態存放在客戶端要做到真正的“即時退出登錄”就很困難了。你可以在 session 信息里加上過期日期，也可以直接依靠 cookie 的過期日期，過期之后，就當是退出了。

但是如果你不想等到 session 過期，現在就想退出登錄！怎么辦？認真想想你會發現，僅僅依靠客戶端儲存的 session 信息真的沒有辦法做到。

即使你通過 req.session = null 刪掉客戶端 cookie，那也只是刪掉了，但是如果有人曾經把 cookie 復制出來了，那他手上的 cookie 直到 session 信息里的過期時間前，都是有效的。

說“即時退出登錄”有點標題黨的意味，其實我想表達的是，你沒辦法立即廢除一個 session，這可能會造成一些隱患。

Token

session 說完了，那么出現頻率超高的關鍵字 token 又是什么？

不妨谷歌搜一下 token 這個詞，可以看到冒出來幾個（年紀大的人）比較熟悉的圖片：密碼器。過去網上銀行不是只要短信認證就能轉賬，還要經過一個密碼器，上面顯示著一個變動的密碼，在轉賬時你需要輸入密碼器中的代碼才能轉賬，這就是 token 現實世界中的例子。憑借一串碼或是一個數字證明自己身份，這事情不就和上面提到的行李問題還是一樣的嗎……

其實本質上 token 的功能就是和 session id 一模一樣。你把 session id 說成 session token 也沒什么問題（Wikipedia 里就寫了這個別名）。

其中的區別在于，session id 一般存在 cookie 里，自動帶上；token 一般是要你主動放在請求中，例如設置請求頭的 Authorization 為 bearer:<access_token>。

然而上面說的都是一般情況，根本沒有明確規定！

劇透一下，下面要講的 JWT（JSON Web Token）！他是一個 token！但是里面放著 session 信息！放在客戶端，并且可以隨你選擇放在 cookie 或是手動添加在 Authorization！但是他就叫 token！

個人覺得你不能通過存放的位置判斷是 token 或是 session id，也不能通過內容判斷是 token 或是 session 信息，session、session id 以及 token 都是很意識流的東西，只要你明白他是什么、怎么用就好了，怎么稱呼不太重要。

另外在搜索資料時也看到有些文章說 session 和 token 的區別就是新舊技術的區別，好像有點道理。

在 session 的 Wikipedia 頁面上 HTTP session token 這一欄，舉例都是 JSESSIONID (JSP)、PHPSESSID (PHP)、CGISESSID (CGI)、ASPSESSIONID (ASP) 等比較傳統的技術，就像 SESSIONID 是他們的代名詞一般；而在研究現在各種平臺的 API 接口和 OAuth2.0 登錄時，都是使用 access token 這樣的字眼，這個區別著實有點意思。

理解 session 和 token 的聯系之后，可以在哪里能看到“活的” token 呢？

打開 GitHub 進入設置，找到 Settings / Developer settings，可以看到 Personal access tokens 選項，生成新的 token 后，你就可以帶著它通過 GitHub API，證明“你就是你”。

在 OAuth 系統中也使用了 Access token 這個關鍵詞，寫過微信登錄的朋友應該都能感受到 token 是個什么啦。

Token 在權限證明上真的很重要，不可泄漏，誰拿到 token，誰就是“主人”。所以要做一個 Token 系統，刷新或刪除 Token 是必須要的，這樣在盡快彌補 token 泄漏的問題。

在理解了三個關鍵字和兩種儲存方式之后，下面我們正式開始說“用戶登錄”相關的知識和兩種登錄規范——JWT 和 OAuth2.0。

接著你可能會頻繁見到 Authentication 和 Authorization 這兩個單詞，它們都是 Auth 開頭，但可不是一個意思，簡單來說前者是驗證，后者是授權。在編寫登錄系統時，要先驗證用戶身份，設置登錄狀態，給用戶發送 token 就是授權。

JWT

全稱 JSON Web Token（RFC 7519），是的，JWT 就是一個 token。為了方便理解，提前告訴大家，JWT 用的是上面客戶端儲存的方式，所以這部分可能會經常用到上面提到的名稱。

結構

雖說 JWT 就是客戶端儲存 session 信息的一種，但是 JWT 有著自己的結構：Header.Payload.Signature（分為三個部分，用 . 隔開）

Header 

{  
  "alg": "HS256",  
  "typ": "JWT"  
} 

typ 說明 token 類型是 JWT，alg 代表簽名算法，HMAC、SHA256、RSA 等。然后將其 base64 編碼。

Payload 

{  
  "sub": "1234567890",  
  "name": "John Doe",  
  "admin": true  
} 

Payload 是放置 session 信息的位置，最后也要將這些信息進行 base64 編碼，結果就和上面客戶端儲存的 session 信息差不多。

不過 JWT 有一些約定好的屬性，被稱為 Registered claims，包括：

•  iss (issuer)：簽發人
•  exp (expiration time)：過期時間
•  sub (subject)：主題
•  aud (audience)：受眾
•  nbf (Not Before)：生效時間
•  iat (Issued At)：簽發時間
•  jti (JWT ID)：編號

Signature

最后一部分是簽名，和上面提到的 session.sig 一樣是用于防止篡改，不過 JWT 把簽名和內容組合到一起罷了。

JWT 簽名的生成算法是這樣的： 

HMACSHA256(  
  base64UrlEncode(header) + "." +  
  base64UrlEncode(payload),  
  secret) 

使用 Header 里 alg 的算法和自己設定的密鑰 secret 編碼 base64UrlEncode(header) + "." + base64UrlEncode(payload)

最后將三部分通過 . 組合在一起，你可以通過 jwt.io Debugger 形象地看到 JWT 的組成原理：

如何使用

在驗證用戶，順利登錄后，會給用戶返回 JWT。因為 JWT 的信息沒有加密，所以別往里面放密碼，詳細原因在客戶端儲存的 cookie 中提到。

用戶訪問需要授權的連接時，可以把 token 放在 cookie，也可以在請求頭帶上 Authorization: Bearer <token>。（手動放在請求頭不受 CORS 限制，不怕 CSRF）

這樣可以用于自家登錄，也可以用于第三方登錄。單點登錄也是 JWT 的常用領域。

JWT 也因為信息儲存在客戶端造成無法讓自己失效的問題，這算是 JWT 的一個缺點。

HTTP authentication

HTTP authentication 是一種標準化的校驗方式，不會使用 cookie 和 session 相關技術。請求頭帶有 Authorization: Basic <credentials> 格式的授權字段。

其中 credentials 就是 Base64 編碼的用戶名 + : + 密碼（或 token），以后看到 Basic authentication，意識到就是每次請求都帶上用戶名密碼就好了。

Basic authentication 大概比較適合 serverless，畢竟他沒有運行著的內存，無法記錄 session，直接每次都帶上驗證就完事了。

OAuth 2.0

OAuth 2.0（RFC 6749）也是用 token 授權的一種協議，它的特點是你可以在有限范圍內使用別家接口，也可以借此使用別家的登錄系統登錄自家應用，也就是第三方應用登錄。（注意啦注意啦，OAuth 2.0 授權流程說不定面試會考哦！）

既然是第三方登錄，那除了應用本身，必定存在第三方登錄服務器。在 OAuth 2.0 中涉及三個角色：用戶、應用提供方、登錄平臺，相互調用關系如下： 

+--------+                               +---------------+  
|        |--(A)- Authorization Request ->|   Resource    |  
|        |                               |     Owner     |  
|        |<-(B)-- Authorization Grant ---|               |  
|        |                               +---------------+ 
|        |  
|        |                               +---------------+  
|        |--(C)-- Authorization Grant -->| Authorization |  
| Client |                               |     Server    |  
|        |<-(D)----- Access Token -------|               |  
|        |                               +---------------+  
|        |  
|        |                               +---------------+  
|        |--(E)----- Access Token ------>|    Resource   |  
|        |                               |     Server    |  
|        |<-(F)--- Protected Resource ---|               |  
+--------+                               +---------------+ 

很多大公司都提供 OAuth 2.0 第三方登錄，這里就拿小聾哥的微信舉例吧——

準備

一般來說，應用提供方需要先在登錄平臺申請好 AppID 和 AppSecret。（微信使用這個名稱，其他平臺也差不多，一個 ID 和一個 Secret）

獲取 code

什么是授權臨時票據（code）？ 答：第三方通過 code 進行獲取 access_token 的時候需要用到，code 的超時時間為 10 分鐘，一個 code 只能成功換取一次 access_token 即失效。code 的臨時性和一次保障了微信授權登錄的安全性。第三方可通過使用 https 和 state 參數，進一步加強自身授權登錄的安全性。

在這一步中，用戶先在登錄平臺進行身份校驗。 

https://open.weixin.qq.com/connect/qrconnect?  
appid=APPID&  
redirect_uri=REDIRECT_URI&  
response_type=code&  
scope=SCOPE&  
state=STATE  
#wechat_redirect 

參數	是否必須	說明
appid	是	應用唯一標識
redirect_uri	是	請使用 urlEncode 對鏈接進行處理
response_type	是	填 code
scope	是	應用授權作用域，擁有多個作用域用逗號（,）分隔，網頁應用目前僅填寫 snsapi_login
state	否	用于保持請求和回調的狀態，授權請求后原樣帶回給第三方。該參數可用于防止 csrf 攻擊（跨站請求偽造攻擊）

注意一下 scope 是 OAuth2.0 權限控制的特點，定義了這個 code 換取的 token 可以用于什么接口。

正確配置參數后，打開這個頁面看到的是授權頁面，在用戶授權成功后，登錄平臺會帶著 code 跳轉到應用提供方指定的 redirect_uri： 

redirect_uri?code=CODE&state=STATE 

授權失敗時，跳轉到 

redirect_uri?state=STATE 

也就是失敗時沒 code。

獲取 token

在跳轉到重定向 URI 之后，應用提供方的后臺需要使用微信給你的code獲取 token，同時，你也可以用傳回來的 state 進行來源校驗。

要獲取 token，傳入正確參數訪問這個接口： 

https://api.weixin.qq.com/sns/oauth2/access_token?  
appid=APPID& 
secret=SECRET&  
code=CODE&  
grant_type=authorization_code 

參數	是否必須	說明
appid	是	應用唯一標識，在微信開放平臺提交應用審核通過后獲得
secret	是	應用密鑰 AppSecret，在微信開放平臺提交應用審核通過后獲得
code	是	填寫第一步獲取的 code 參數
grant_type	是	填 authorization_code，是其中一種授權模式，微信現在只支持這一種

正確的返回： 

{  
  "access_token": "ACCESS_TOKEN",  
  "expires_in": 7200,  
  "refresh_token": "REFRESH_TOKEN",  
  "openid": "OPENID",  
  "scope": "SCOPE",  
  "unionid": "o6_bmasdasdsad6_2sgVt7hMZOPfL"  
} 

得到 token 之后你就可以根據之前申請 code 填寫的 scope 調用接口了。

使用 token 調用微信接口

授權作用域（scope）	接口	接口說明
snsapi_base	/sns/oauth2/access_token	通過 code 換取 access_token、refresh_token 和已授權 scope
snsapi_base	/sns/oauth2/refresh_token	刷新或續期 access_token 使用
snsapi_base	/sns/auth	檢查 access_token 有效性
snsapi_userinfo	/sns/userinfo	獲取用戶個人信息

例如獲取個人信息就是 GET https://api.weixin.qq.com/sns...

注意啦，在微信 OAuth 2.0，access_token 使用 query 傳輸，而不是上面提到的 Authorization。

使用 Authorization 的例子，如 GitHub 的授權，前面的步驟基本一致，在獲取 token 后，這樣請求接口：

curl -H "Authorization: token OAUTH-TOKEN" https://api.github.com 

說回微信的 userinfo 接口，返回的數據格式如下： 

{  
  "openid": "OPENID",  
  "nickname": "NICKNAME",  
  "sex": 1,  
  "province":"PROVINCE",  
  "city":"CITY",  
  "country":"COUNTRY",  
  "headimgurl":"https://thirdwx.qlogo.cn/mmopen/g3MonUZtNHkdmzicIlibx6iaFqAc56vxLSUfpb6n5WKSYVY0ChQKkiaJSgQ1dZuTOgvLLrhJbERQQ4eMsv84eavHiaiceqxibJxCfHe/46", 
   "privilege":[ "PRIVILEGE1" "PRIVILEGE2" ],  
  "unionid": "o6_bmasdasdsad6_2sgVt7hMZOPfL"  
} 

后續使用

在使用 token 獲取用戶個人信息后，你可以接著用 userinfo 接口返回的 openid，結合 session 技術實現在自己服務器登錄。 

// 登錄  
req.session.id = openid  
if (req.session.id) {  
  //   已登錄  
} else {  
  //   未登錄  
}  
// 退出  
req.session.id = null  
// 清除 session 

總結一下 OAuth2.0 的流程和重點：

•  為你的應用申請 ID 和 Secret
•  準備好重定向接口
•  正確傳參獲取 code <- 重要
•  code 傳入你的重定向接口
•  在重定向接口中使用 code 獲取 token <- 重要
•  傳入 token 使用微信接口

OAuth2.0 著重于第三方登錄和權限限制。而且 OAuth2.0 不止微信使用的這一種授權方式，其他方式可以看阮老師的OAuth 2.0 的四種方式。

其他方法

JWT 和 OAuth2.0 都是成體系的鑒權方法，不代表登錄系統就一定要這么復雜。

簡單登錄系統其實就以上面兩種 session 儲存方式為基礎就能做到。

1.  使用服務器儲存 session 為基礎，可以用類似 req.session.isLogin = true 的方法標志該 session 的狀態為已登錄。
2.  使用客戶端儲存 session 為基礎，設置 session 的過期日期和登錄人就基本能用了。 

{  
  "exp": 1614088104313,  
  "usr": "admin"  
} 

（就是和 JWT 原理基本一樣，不過沒有一套體系）

1.  甚至你可以使用上面的知識自己寫一個 express 的登錄系統：

•  初始化一個 store，內存、redis、數據庫都可以
•  在用戶身份驗證成功后，隨機生成一串哈希碼作為 token
•  用 set-cookie 寫到客戶端
•  再在服務器寫入登錄狀態，以內存為例就是在 store 中添加哈希碼作為屬性
•  下次請求帶著 cookie 的話檢查 cookie 帶來的 token 是否已經寫入 store 中即可 

let store = {}  
// 登錄成功后  
store[HASH] = true  
cookie.set('token', HASH)  
// 需要鑒權的請求鐘  
const hash = cookie.get('token')  
if (store[hash]) {  
  // 已登錄  
} else {  
  // 未登錄  
}   
// 退出  
const hash = cookie.get('token')  
delete store[hash] 

總結

以下列出本文重點：

•  cookie 是儲存 session/session id/token 的容器
•  cookie 設置一般通過 set-cookie 請求頭設置
•  session 信息可以存放在瀏覽器，也可以存放在服務器
•  session 存放在服務器時，以 session id 為鑰匙獲取信息
•  token/session/session id 三者的界限是模糊的
•  一般新技術使用 token，傳統技術使用 session id
•  cookie/token/session/session id 都是用于鑒權的實用技術  JWT 是瀏覽器儲存 session 的一種
•  JWT 常用于單點登錄（SSO）
•  OAuth2.0 的 token 不是由應用端頒發，存在另外的授權服務器
•  OAuth2.0 常用于第三方應用登錄