HTTP Basic, Session, Token 三種認證方法簡介

1. 概述

本文簡介 HTTP Basic，Session，Token 三種認證方法。

• Basic 認證：戶籍部門已給你簽發了一張身份證。你每次去辦事，都要帶上身份證證，後臺要拿你的身份證去系統上查一下。
• Session 認證：戶籍部門已給你簽發了一張身份證，但只告訴你身份證號碼。你每次去辦事，只要報出你的身份證號碼，後臺要查一個即否有效。
• Token 認證：戶籍部門已給你簽發了一張有防僞功能的身份證。你每次去辦事，只要出示這張卡片，它就知道你必定是本身人。

2. HTTP Basic 認證

這是一種最基本的認證方法。

在這種認證方法下，用戶每次發送請求時，請求頭中都必須攜帶能經過認證的身份信息。

其交互過程以下：

1. 開始時，客戶端發送未攜帶身份信息的請求。
2. 服務端返回 401 Unauthorized 狀態，並在返回頭中說明要用 Basic 方法進行認證： WWW-Authenticate: Basic。
3. 客戶端從新發送請求，並將身份信息包含在請求頭中: Authorization: Basic aHk6bXlwYXNzd29yZA==。
4. 服務端驗證請求頭中的身份信息，並相應返回 200 OK 或 403 Forbidden 狀態。
5. 以後，客戶端每次發送請求都在請求頭中攜帶該身份信息。

客戶端                                                          服務端
------                                                          ------

1----------------------------------------->
GET / HTTP/1.1

                                           <-------------------------2
                                            HTTP/1.1 401 Unauthorized
                                            WWW-Authenticate: Basic

3----------------------------------------->
GET / HTTP/1.1
Authorization: Basic aHk6bXlwYXNzd29yZA==

                                            <------------------------4
                                                       HTTP/1.1 200 OK

5----------------------------------------->
GET /another-path/ HTTP/1.1
Authorization: Basic aHk6bXlwYXNzd29yZA==

其中傳送的身份信息是 <username>:<password> 經 base64 編碼後的字串。如本例中的 aHk6bXlwYXNzd29yZA==， 經 base64 解碼後爲 hy:mypassword。

這種認證方法的優勢是簡單，容易理解。

缺點有：

• 不安全：認證身份信息用明文傳送，所以需結合 https 使用。
• 效率低：服務端處理請求時，每次都須要驗證身份信息，如用戶名和密碼。

3. Session 認證

這種認證方法結合了 Session 和 Cookie。服務端將本次會話信息以 Session 對象的形式保存在服務端的內存、數據庫或文件系統中，並將對應的 Session 對象 ID 值 SessionID 以 Cookie 形式返回給客戶端，SessionID 保存在客戶端的 Cookie 中。

這是一種有狀態的認證方法：服務端保存 Session 對象，客戶端以 Cookie 形式保存 SessionID。

其交互過程以下：

1. 客戶端在登陸頁面輸入身份信息，如用戶名/密碼。
2. 服務端驗證身份信息，經過後生成一個 Session 對象，保存到服務端，並將 SessionID 值以 Cookie 形式返回給客戶端。
3. 客戶端將接收到的 SessionID 保存到 Cookie 中，而且以後每次請求都在請求頭中攜帶 SessionID Cookie。
4. 服務端從請求的 Cookie 中獲取 SessionID，並查詢其對應的 Session 對象，從而得到身份信息。
5. 客戶端退出本次會話後，客戶端刪除 SessionID 的 Cookie，服務端刪除 Session 對象。
6. 若是客戶端以後要從新登陸，需從新生成 Session 對象和 SessionID。

優勢：

• 較安全：客戶端每次請求時無需發送身份信息，只需發送 SessionID。
• 較高效：服務端無需每次處理請求時都要驗證身份信息，只需經過 SessionID 查詢 Session 對象。

缺點：

• 擴展性差，Session 對象保存在服務端，若是是保存在多個服務器上，有一致性問題，若是保存在單個服務器上，沒法適應用戶增加。
• 基於 Cookie 的 SessionID 不能跨域共享，同一用戶的多個客戶端（如瀏覽器客戶端和 APP）不能共享 SessionId。
• 基於 Cookie 的 SessionID 易被截獲生成 CSRF 攻擊。

4. Token 認證

這是一種 SPA 應用和 APP 常常使用的認證方法。它是一種無狀態的認證方法。

客戶端首先將用戶信息發送給服務端，服務端根據用戶信息+私鑰生成一個惟一的 Token 並返回給客戶端。Token 只保存在客戶端，以後客戶端的每一個請求頭中都攜帶 Token，而服務端只經過運算（無需查詢）來驗證用戶。

客戶端                                                          服務端
------                                                          ------

1----------------------------------------->
GET / HTTP/1.1

                                           <-------------------------2
                                            HTTP/1.1 401 Unauthorized
                                            WWW-Authenticate: Token

3----------------------------------------->
GET / HTTP/1.1
Authorization: Token f613d789819ff93537ee6a

                                            <------------------------4
                                                       HTTP/1.1 200 OK

5----------------------------------------->
GET /another-path/ HTTP/1.1
Authorization: Token f613d789819ff93537ee6a

優勢：

• Token 只保存在客戶端，所以不影響服務端擴展性。
• 爲用戶生成的 Token 能夠在多個客戶端共用。

缺點：

• Token 包含了用戶的所有信息，不僅是如 SessionID 相似的一個 ID 值，所以會增長每次請求包的大小。

目前使用較多的是基於JWT(JSON Web Tokens) 的 Token 認證法。

資源

• Django for beginners
• Session、Token身份驗證方法