文章目錄

• • 1. 前言
  • 2. 過時的身份識別技術
  • • 2.1 HTTP 首部
    • 2.2 客戶端 IP
    • 2.3 用戶登錄
    • 2.4 胖 URL
  • 3. 常用的身份識別技術
  • • 3.1 cookie
    • 3.2 session
    • 3.3 token
  • 4. 總結

1. 前言

由于 HTTP 協議是匿名的、無狀態的協議，所以當服務端需要記錄用戶的狀態時，就需要用某種機制來識別具體的用戶。這也是一系列web身份識別技術如cookie、session 和 token 出現的原因。

在 HTTP 協議中，一共存在以下幾種方式來實現：

• 承載用戶身份信息的 HTTP 首部
• 客戶端 IP 地址跟蹤，通過用戶的 IP 地址對其進行識別
• 用戶登錄，用認證方式來識別用戶
• 胖 URL，一種在 URL 中嵌入識別信息的技術
• cookie, 一種功能強大且高效的持久身份識別技術
• session，一種服務端存儲的身份識別
• token, 一種無狀態的身份識別技術

目前，前4種方式由于其存在的不足而幾乎不再使用了，一般采用 session-cookie 或 token 或 token-session-cookie模式。

下面首先簡單簡述一下前4種，然后詳細解析后面三種。

2. 過時的身份識別技術

2.1 HTTP 首部

• From —— 包含用戶的 Email 地址
• User-Agent —— 瀏覽器信息
• Referer —— 來源

From 首部包含了用戶的E-mail地址。每個用戶都有不同的E-mail地址，所以在理想情況下，可以將這個地址作為可行的源端來識別用戶。但由于擔心那些不講武德的服務器會搜集這些E-mail，用于垃圾郵件的散發，所以很少有瀏覽器會發送From首部。實際上From首部一般由自動化的機器人或蜘蛛發送的，這樣在出現問題時，網管還有個地方可以發送憤怒的投訴郵件。

User-Agent 首部可將用戶所用瀏覽器的相關信息告知服務器，包括程序的名稱和版本，通常還包含操作系統的相關信息。要實現定制內容與特定的瀏覽器及其屬性間的良好互操作時，這個首部非常有用，但它并沒有為識別特定的用戶提供太多有意義的幫助。

Referer首部提共了用戶來源頁面的 URL。Referer 首部自身并不能完全識別用戶，但它卻是說明了用戶之前訪問過哪個頁面。通過它可以更好地理解用戶的瀏覽行為，以及用戶的興趣所在。比如，如果你是從一個籃球網站抵達某個Web服務器的，這個服務器可能會推斷你是個籃球迷。

這三個首部都不足以實現可靠的識別。

2.2 客戶端 IP

早期的Web先鋒曾嘗試將客戶端 IP 地址作為一種標識行為使用，如果每個用戶都有不同的 IP 地址，IP地址（如果會發生變化的話）也很少會發生變化，而且Web 服務器可以判斷出每條請求的客戶端 IP 地址的話這種方案是可行的。通常在HTTP 首部并不提供客戶端的 IP 地址，但Web 服務器可以找到承載 HTTP請求的 TCP 連接另一端的 IP 地址。

但是，使用客戶端 IP 地址來識別用戶存在著很多缺點，限制了將其作為用戶識別技術的效能。

• 客戶端 IP 地址描述的是所用的機器，而不是用戶。如果多個用戶共享同一臺機器，就無法對其進行區分了。
• 很多因特網服務提供商都會在用戶登錄時動態為其動態分配 IP 地址。用戶每次登錄時，都會得到一個不同的地址，因此 Web 服務器不能假設 IP 地址可以在各登錄會話之前標識用戶。
• 為了提高安全性，并對稀缺的地址資源進行管理，很多用戶都是通過網絡地址轉換（NAT）防火墻來瀏覽網絡請求的。這些 NAT 設備隱藏了防火墻后面那些實際客戶端的 IP 地址，將實際的客戶端 IP 地址轉換成一個共享的防火墻 IP 地址（和不通過的端口號）。
• HTTP 代理和網關通常會打開一些新的、到原始服務器的 TCP 連接。 Web 服務器看到的將是代理服務器的 IP 地址，而不是客戶端的。有些代理為了繞過這個問題會添加特殊的 Client-IP 或者 X-Forwarded-For 擴展首部來保存原始的 IP 地址。但并不是所有的代理都支持這種行為。

少數站點甚至將客戶端 IP 地址作為一種安全特性使用，它們只向來自特定 IP 地址的用戶提供文檔。在內部網絡中可能可以這么做，但在因特網上就不行了，主要是因為因特網上 IP 地址太容易被欺騙（偽造）了。

2.3 用戶登錄

Web 服務器無需被動地根據用戶的 IP 地址來猜測他的身份，它可以要求用戶通過用戶名和密碼進行認證（登錄）來顯示地詢問用戶是誰。

為了使 Web 站點的登錄更加簡便，HTTP 中包含了一種內建機制，可以用 www-Authenticate 首部和 Authorization 首部向 Web 站點傳送用戶的相關信息。一旦登錄，瀏覽器就可以不斷地在每條發往這個站點的請求中發送這個登錄信息了，這樣，就總是有登錄信息可以用了。

其實這種方式跟之后出現的 cookie 在機制上十分類似，都是將用戶名和密碼添加在請求首部中，然后在每次請求中都向服務器發送Authorization首部作為一種身份的標識，也可以說是 cookie 的前身，但是這種方式存在很大的不足。

• 無法存儲起來
• 十分容易破解

之前我并未了解到還存在這種方式，是在《http權威指南》276頁中學習到，但是其中并未給出這種方式明顯的缺陷，上面兩點是我總結而來。同時我并未完全想明白為何不完善這種方式而發展出 cookie。

2.4 胖 URL

所謂的胖 URL 也就是Web站點根據每個用戶而給 URL 添加了一些額外的數據，服務器通過這些數據可識別用戶身份。

舉例來說www.arrow-zb.cn?nameId=“paopao”， nameId 標識符為paopao，服務器可以用這個數據來識別客戶端。

但是這種方式存在的不足十分明顯：

• 丑陋的 URL

• 無法共享 URL

  URL 中包含特定用戶和會話有關的狀態信息，如果將這個URL發送給其他人，可能就在無意中將個人信息共享出去了。

• 破壞緩存 —— 因為每個用戶 URL 都不相同

• 服務器負擔

• 非持久

但是，當瀏覽器不支持cookies時，自己又不想模擬cookie機制時，胖URL也是一種選擇。

以上幾種方式都存在對應的不足，因此幾乎不會再使用了。

3. 常用的身份識別技術

3.1 cookie

在身份識別中，cookie 就好像服務器給用戶貼的 “嗨，我叫”的貼紙一樣，用戶訪問一個Web 站點時，這個 Web 站點就可以讀取服務器貼在用戶身上的所有貼紙。

用戶首次訪問Web站點時，通過用戶名和密碼向服務器發起登錄請求，驗證通過后，Web 服務器希望在這個用戶下次回來的時候能識別出這個用戶，就想著給這個用戶“拍上”一個獨有的cookie，這樣以后他就可以識別這個用戶了。cookie 中包含了一個由名字 = 值 （key=value）這樣的信息構成的任意列表，并通過 Set-Cookie 或者 Set-Cookie2 HTTP響應（擴展）首部將其貼到用戶身上去。大致過程如下圖所示：

cookie中可以包含任意信息，但他們通常都只包含一個服務器為了進行跟蹤而產生的獨特的識別碼，比如id=12345。服務器就可以通過這個數字來查找服務器為其訪問者積累的數據庫信息（購物歷史，地址信息啥的）。

瀏覽器會記住從服務器返回的 Set-Cookie 或 Set-Cookie2 首部中的 cookie 內容，并將不同站點的 cookie分站點的存儲在瀏覽器的cookie數據庫中。

關于cookie的具體屬性可到《HTTP權威指南》283頁查看，包含了過期時間，域名，path，secure等。

cookie 還是存在一些不足的：

• cookie無法承載較大數據，瀏覽器對cookie的數量和大小都存在不同的限制。同時訪問時攜帶cookie也無形中增加了瀏覽器的流量。一般說來每個domain最多只能有20條cookie，每個cookie長度不能超過4KB，否則會被截掉。
• 安全性問題。如果cookie被人攔截了，那人就可以取得所有的信息。即使加密也與事無補，因為攔截者并不需要知道cookie的意義，他只要原樣轉發cookie就可以達到目的了。
• 有些狀態不可能保存在客戶端。例如，為了防止重復提交表單，我們需要在服務器端保存一個計數器。如果我們把這個計數器保存在客戶端，那么它起不到任何作用。

cookie 存在這些問題，那么能不能想辦法把會話狀態保存在服務器呢？ 存儲在服務器的話，就不再有了大小和數量的限制，因此就出現了 session 技術。

3.2 session

session 是一種將會話狀態保存在服務器端的技術。可以比喻成是銀行發放給客戶的銀行卡和銀行為每個客戶保留的賬戶檔案的結合方式 。銀行卡就相當于 session 技術中 服務端發給客戶端的一個唯一標識，這個標識簡單，唯一；銀行為每個客戶存儲的賬戶檔案就相當于 session 技術中服務器存儲的會話狀態（客戶端唯一標識對應的信息，名字，性別，買了多少車等等）。

至于客戶端怎么保存這個“身份標識”，可以有很多種方式。對于瀏覽器客戶端，大家都默認采用 cookie 的方式，服務器給客戶端發一個唯一的 sessionId。服務器使用 sessionId 把用戶的信息臨時保存在了服務器上，因此可以保存大量與此用戶有關的信息，用戶離開網站后 session 會被銷毀（當然也可以設置長期保存 session，比如保存在文件，數據庫等）。

這種用戶信息存儲方式相對 cookie 來說更安全，可是 session 有一個巨大的缺陷：

• 如果web服務器做了負載均衡，那么下一個操作請求到了另一臺服務器的時候，由于另一臺服務器沒有對應的session，會直接返回認證錯誤，進而需要用戶重新登錄。為了避免類似的問題，需要將 session 復制到所有的應用服務器，同時由于互聯網的巨量用戶必然會帶來的海量 session 信息的存儲需求，這對服務器存儲能力是一個巨大的開銷，而且嚴重限制了服務器的動態擴展能力（為了應對用戶的巨量增長，互聯網常用的做法是加服務器來保證服務能力的可用性），當然可以采用分布式緩存來對 session 信息進行集中存儲，這又會帶來新的問題，比如單點故障等。

因為上述問題的出現，那么能不能出現一種無狀態的身份識別技術呢？如果無狀態了，不僅不會出現負載的問題，也不會出現故障了。 因此出現了一種 token 技術。

3.3 token

token即“令牌”，是服務端生成的一串字符串，作為客戶端進行請求的一個標識。在識別的機制上，token 和 session cookie是一樣的，均是服務器頒發，客戶端請求時攜帶，然后客戶端驗證識別。

token 的神奇之處（關鍵）在于它是如何實現無狀態且實現防篡改的。
生成的 token 一般為三部分。

"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkYXRhIjoidGVzdCIsImV4cCI6MTYwODUxMzc1MSwiaWF0IjoxNjA4NTEwMTUxfQ.UsTVoAx9glQRP-wIyuhK5yk1EB_d0Hx_-5YNnPwQ_9o" # 第一部分 算法，類型 {"alg":"HS256","typ":"JWT"} # 第二部分 數據，過期時間，生成時間 {"data":"test","exp":1608513751,"iat":1608510151}

其中前兩部分都是都是base64加密的，可以說是明文。
第三部分是簽名，token 的關鍵就在于第三部分，簽名是根據負載（傳給客戶端的數據）和密鑰進行加密的(這里就以對稱加密簡述)，這個簽名和負載是一一對應的，而且是雪崩的，只要其中一個發生變化（篡改），那么另一個一定是雪崩式的。因此做到了防篡改。客戶端把這個token在請求時發送給服務器，服務器根據負載和密鑰同樣進行加密簽名，和客戶端發送的簽名進行校驗便可驗證身份。神奇呀！！

token具有以下好處。

• token 完全由應用管理，所以它可以避開同源策略

• token 可以很大程度避免 CSRF 攻擊

• token 可以是無狀態的，可以在多個服務間共享。

但是token同樣存在一些不足：

• 無法作廢已經頒布的令牌

  所有的認證信息都在 token 中，由于在服務端沒有狀態，即使你知道了某個 token 被盜取了，你也沒有辦法將其作廢。在 token 過期之前（你絕對應該設置過期時間），你無能為力。

• 不能完全避免 CSRF 和 XSS 攻擊

4. 總結

這里只是大致簡述了目前存在的身份識別技術，并沒有深度剖析。

關于cookie、session 和 token，沒有哪一種是最好的，只有合適不合適，程序永遠沒有銀彈。

總結

以上是生活随笔為你收集整理的浅谈Web身份识别技术 —— Cookie、Session 和 Token的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。