鑑權理論知識學習

前置知識

1. 認證
2. 授權
3. 鑑權
4. 許可權控制
5. 以上四個的關係

鑑權方法

1. HTTP基本授權認證【不安全、瞭解即可】
2. Session-Cookie認證【適用中大型網站，會增加伺服器費用】
3. Token認證 【Session-Cookie的升級改良版】
4. JWT認證 【JSON Web Token】
5. 單點登入 【應用於多個子系統的專案，不同系統只需登入一次即可】
6. OAuth2開發授權
7. 聯合登入和信任登入
8. 唯一登入（一般後端處理）
9. 掃碼登入（三端配合）
10. 一鍵登入（適用於APP端）

前提概念知識

名稱	概念	理解
認證	指根據宣告者所特有的識別資訊，確認宣告者的身份。	你需要用身份證證明你自己是你自己
授權	在資訊保安領域是指資源所有者委派執行者���賦予執行者指定範圍的資源操作許可權，以便對資源的相關操作。	銀行卡（由銀行派發）、門禁卡（由物業管理處派發）、鑰匙（由房東派發）
鑑權	在資訊保安領域是指對於一個宣告者所宣告的身份權利，對其所宣告的真實性進行鑑別確認的過程。	門禁卡需要透過門禁卡識別器，銀行卡需要透過銀行卡識別器；
許可權控制	將可執行的操作定義為許可權列表，然後判斷操作是否允許/禁止	以門禁卡的許可權實現為例，一個門禁卡，擁有開公司所有的門的許可權；一個門禁卡，擁有管理員角色的許可權，因而可以開公司所有的門。

認證、授權、鑑權、許可權控制這四個環節前後依次發生、上下游的關係。

需要說明的是，這四個環節在有些時候會同時發生。 例如在下面的幾個場景：

• • 使用門禁卡開門： 認證、授權、鑑權、許可權控制四個環節一氣呵成，在瞬間同時發生
  • 使用者的網站登入： 使用者在使用使用者名稱和密碼進行登入時，認證和授權兩個環節一同完成，而鑑權和許可權控制則發生在後續的請求訪問中，比如在選購物品或支付時。

1、HTTP基本鑑權

在 HTTP 中，基本認證方案（Basic Access Authentication) 是允許客戶端（通常指的就是網頁瀏覽器）在請求時，透過使用者提供使用者名稱和密碼的方式，實現對使用者身份的驗證。

因為幾乎所有的線上網站都不會走該認證方案，所以該方案大家瞭解即可

1.1認證流程圖

1.2 認證步驟解析 1) 客戶端(如瀏覽器)： 向伺服器請求一個受限的列表資料或資源，例如欄位如下 GET /list/ HTTP/1.1 Host: www.baidu.com Authorization: Basic aHR0cHdhdGNoOmY= 2）伺服器：客戶端你好，這個資源在安全區 baidu.com 裡，是受限資源，需要基本認證； 並且向客戶端返回 401 狀態碼（Unauthorized 未被授權的）以及附帶提供了一個認證域 www-Authenticate: Basic realm=”baidu.com”要求進行身份驗證； 其中Basic 就是驗證的模式，而 realm="baidu.com" 說明客戶端需要輸入這個安全域的使用者名稱和密碼，而不是其他域的 　　HTTP/1.1 401 Unauthorized 　　www-Authenticate: Basic realm= "baidu.com" 3) 客戶端： 伺服器，我已經攜帶了使用者名稱和密碼給你了，你看一下；（注：如客戶端是瀏覽器，那麼此時會自動彈出一個彈窗，讓使用者輸入使用者名稱和密碼）； 輸入完使用者名稱和密碼後，則客戶端將使用者名稱及密碼以 Base64 加密方式傳送給伺服器 傳送的格式如下 (其中 Basic 內容為：使用者名稱:密碼 的 ase64 形式)： GET /list/ HTTP/1.1 　　Authorization: Basic Ksid2FuZzp3YW5n== 4) 伺服器： 客戶端你好，我已經校驗了Authorization 欄位你的使用者名稱和密碼，是正確的，這是你要的資源。 　　　HTTP/1.1 200 OK ...

優點：

簡單，基本所有流行的瀏覽器都支援

缺點

1. 不安全

• 由於是基於 HTTP 傳輸，所以它在網路上幾乎是裸奔的，雖然它使用了 Base64 來編碼，但這個編碼很容易就可以解碼出來。
• 即使認證內容無法被解碼為原始的使用者名稱和密碼也是不安全的，惡意使用者可以再獲取了認證內容後使用其不斷的享伺服器發起請求，這就是所謂的重放攻擊。

　　2. 無法主動登出：

1. • 由於 HTTP 協議沒有提供機制清除瀏覽器中的 Basic 認證資訊，除非標籤頁或瀏覽器關閉、或使用者清除歷史記錄。

使用場景：

　　內部網路，或者對安全要求不是很高的網路。

2、Session-Cookie鑑權

Session-Cookie 認證是利用服務端的 Session（會話）和 瀏覽器（客戶端） 的 Cookie 來實現的前後端通訊認證模式。

什麼是cookie?

眾所周知，HTTP 是無狀態的協議（對於事務處理沒有記憶能力，每次客戶端和服務端會話完成時，服務端不會儲存任何會話資訊）；

所以為了讓伺服器區分不同的客戶端，就必須主動的去維護一個狀態，這個狀態用於告知服務端前後兩個請求是否來自同一瀏覽器。而這個狀態可以透過 Cookie 去實現。

特點：

• • Cookie 儲存在客戶端，可隨意篡改，不安全
  • 有大小限制，最大為 4kb
  • 有數量限制，一般一個瀏覽器對於一個網站只能存不超過 20 個 Cookie，瀏覽器一般只允許存放 300個 Cookie
  • Android 和 IOS 對 Cookie 支援性不好
  • Cookie 是不可跨域的，但是一級域名和二級域名是允許共享使用的（靠的是 domain）

什麼是session?

Session 的抽象概念是會話，是無狀態協議通訊過程中，為了實現中斷/繼續操作，將使用者和伺服器之間的互動進行的一種抽象；

具體來說，是伺服器生成的一種 Session 結構，可以透過多種方式儲存，如記憶體、資料庫、檔案等，大型網站一般有專門的 Session 伺服器叢集來儲存使用者會話；

原理流程：

1. 1. 客戶端： 使用者向伺服器首次傳送請求；
   2. 伺服器： 接收到資料並自動為該使用者建立特定的 Session / Session ID，來標識使用者並跟蹤使用者當前的會話過程；
   3. 客戶端： 瀏覽器收到響應獲取會話資訊，並且會在下一次請求時帶上 Session / Session ID；
   4. 伺服器： 伺服器提取後會與本地儲存的 Session ID進行對比找到該特定使用者的會話，進而獲取會話狀態；
   5. 至此客戶端與伺服器的通訊變成有狀態的通訊；

特點：

• • Session 儲存在伺服器上；
  • 透過伺服器自帶的加密協議進行；

session與 Cookie 的差異：

• 安全性： Cookie 由於儲存在客戶端，可隨意篡改，Session 則不同儲存在伺服器端，無法偽造，所以 Session 的安全性更高；
• 存取值的型別不同： Cookie 只支援字串資料，Session 可以存任意資料型別；
• 有效期不同： Cookie 可設定為長時間保持，Session 一般失效時間較短；
• 儲存大小不同： Cookie 儲存的資料不能超過 4K；

Session-Cookie 就是把 Session 儲存在了客戶端的 Cookie 中

1.Session-Cookie 的認證流程圖

2.Session-Cookie 的認證步驟解析 客戶端： 向伺服器傳送登入資訊使用者名稱/密碼來請求登入校驗； 伺服器： 驗證登入的資訊，驗證透過後自動建立 Session（將 Session 儲存在記憶體中，也可以儲存在 Redis 中），然後給這個 Session 生成一個唯一的標識字串會話身份憑證 session_id(通常稱為 sid)，並在響應頭 Set-Cookie 中設定這個唯一識別符號； 注：可以使用簽名對 sid 進行加密處理，服務端會根據對應的 secret 金鑰進行解密 （非必須步驟） 客戶端： 收到伺服器的響應後會解析響應頭，並自動將 sid 儲存在本地 Cookie 中，瀏覽器在下次 HTTP 請求時請求頭會自動附帶上該域名下的 Cookie 資訊； 伺服器： 接收客戶端請求時會去解析請求頭 Cookie 中的 sid，然後根據這個 sid 去找服務端儲存的該客戶端的 sid，然後判斷該請求是否合法；

優點：

• Cookie 簡單易用
• Session 資料儲存在服務端，相較於 JWT 方便進行管理，也就是當使用者登入和主動登出，只需要新增刪除對應的 Session 就可以了，方便管理
• 只需要後端操作即可，前端可以無感等進行操作；

缺點：

• 依賴 Cookie，一旦使用者在瀏覽器端禁用 Cookie，那麼就 GG 思密達了；
• 非常不安全，Cookie 將資料暴露在瀏覽器中，增加了資料被盜的風險（容易被 CSRF 等攻擊）；
• Session 儲存在服務端，增大了服務端的開銷，使用者量大的時候會大大降低伺服器效能；
• 對移動端的支援性不友好；

使用場景：

• 一般中大型的網站都適用（除了 APP 移動端）；
• 由於一般的 Session 需集中儲存在記憶體伺服器上（如 Redis），這樣就會增加伺服器的預算，所以預算不夠請謹慎選擇；

前端常用的 Session 庫推薦

• 使用 express：express-session
• 使用 koa：koa-session

3、Token鑑權