1.授權與認證的作用

1.1.資源保護

網路資源保護機制是一個鮮為人知的基本措施，比如我們會對網路相簿設定密碼並指定部分使用者才可訪問，又比如我們網盤的資源分享時設定的訪問密碼等等措施。這種資源保護的機制不光體現於此，作為軟體從業人員對於我們開發的API的訪問也是有一套保護機制的，那麼對應到API的保護機制，也就是實現了一套完整的授權與認證體系，這也是基本的API介面標準。

實現了授權與認證的API有以下的防護作用：

1.2.傳統授權

在我們傳統的單機伺服器架構模式中（應用程式只部署在一臺伺服器上），大多數Web應用都採用的是一種Seesion的身份驗證方式。其中的效驗流程概況如下：

1.使用者在客戶端瀏覽器第一次登陸系統時，Web伺服器首先會效驗使用者名稱和密碼的正確性，在效驗成功後，Web伺服器就會為當前使用者建立一個Session物件，並將使用者資訊儲存在Session中。

 2.當Session在伺服器建立成功後，Web伺服器會將生成的sessionID返回給客戶端瀏覽器，客戶端瀏覽器會將sessionID儲存在Cookie中。

 3.當客戶端瀏覽器再次訪問伺服器時，就會向伺服器傳送sessionID。伺服器在接收處理請求時就會判斷這個sessionID對應的Session資訊，是否進行登入過並有相應的身份資訊。然後根據對應的身份資訊，進行對該使用者的許可權判斷，看是否能訪問相應的資源。

1.3.傳統授權的侷限

當網站業務規模和訪問量的逐步發展擴張後，傳統的單機伺服器架構模式不在滿足應用需求，這個時候伺服器架構就會從單臺演變為多臺伺服器的架構模式（叢集、分散式等）。

 那麼在這種多臺伺服器的架構模式中，對於傳統的session的身份驗證方式就會產生“侷限”。因為基於Seesion預設的規則上，session是不能跨伺服器共享資料的。

 這就是意味著，使用者在第一次訪問應用時，分配到A伺服器登陸驗證成功後，第二次訪問應用時分配到B伺服器時，對於B伺服器而言，使用者就是一個未登陸未驗證的使用者。

當然，如何去解決session跨伺服器共享資料的方案也存在，但這種“補救式”的措施並非一套標準規範的授權認證體系。而本文將有講解的重點JWT，它就是一套標準化授權認證體系，並且可以解決session身份驗證方式存在的短板問題。

2.介紹JWT

2.1.什麼是JWT

JWT（JSON Web Token），但從字義上來解釋的話，它其實就是用於在Web應用中的一種JSON格式令牌。它一般傳遞在“身份提供者”和“服務提供者”之間，“身份提供者”需要通過JWT作為一種宣告自身安全資訊的令牌，從而得到“服務提供者”的信任，以便於從伺服器獲取相應的資源。

 JWT不光體現在令牌資訊本身，它更是一種標準化的資料傳輸規範，以及作為一個開放的標準(RFC 7519)，定義了一種簡潔的、自包含的方法。只要是在系統之間傳輸簡短，但卻需要一定安全等級的資料時，都可以使用JWT規範來傳輸。

 所以JWT作為了時下流行的授權與認證方案，它並不侷限於某個開發平臺，在其他語言框架中都有基於JWT規範的實現方案。另外在應用層面，JWT還被廣泛的適用於分散式站點的單點登陸中。

2.2.JWT具有的好處

1.通用：基於JSON格式的通用性，所以JWT是可以進行跨語言的，像Java、JavaScript、PHP、Python等很多語言都可以使用。

2.緊湊：JWT的構成非常簡單，佔用的位元組很小，可以將其方在HTTP請求報文頭Header、URL、Cookie中進行傳輸。

3.擴充套件：JWT包含了常用的身份驗證結構資訊，並且支援自定義結構，另外不在依賴服務端建立Seesion儲存資訊，非常易於應用的擴充套件。

 2.3.JWT在Web中的請求流程

對上圖的流程補充描述如下：

1.客戶端在登陸時向授權服務系統發起請求，以便申請“令牌”；

2.授權服務根據使用者身份，生成一張專屬“令牌”，該“令牌”以JWT格式規範返回給客戶端；

3.客戶端將獲取到的“令牌”放到HTTP報文的Headers中後，向介面服務發起請求。

4.介面服務收到請求後，會從HTTP報文的Headers中獲取“令牌”，並從“令牌”中解析出該使用者的身份許可權資訊，然後判斷做出相應的處理，從而決定是否允許訪問對應的資料資源

3.JWT資訊結構

JWT主要由三部分組成：頭資訊(Header)、訊息體(Payload)、簽名(Signature)。

3.1.頭資訊(Header)

頭資訊(Header)主要由兩個部分組成：alg、typ。alg表示JWT的簽名演算法，一般有兩個選擇，預設使用的是HS256，另外一種是RS256。typ代表的是Token的型別。對應的JSON表現形式如下：

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

3.2.訊息體(Payload)

訊息體(Payload)又叫做“載荷”，可以根據JWT的預定義結構或自定義的結構存放資訊，一般包括使用者資訊或產品資訊等。另外Payload中的存放的資訊，在ASP.NET Core的驗證模型“Claims Based Authentication”又有一種概念叫做“Claim(宣告)”。

什麼是Claim

Claim是對被驗證主體特徵的一項描述，就拿登陸中的被驗證主體使用者而言，那麼對應的Claim包括：

“使用者名稱是zhangsan”，“email是[email protected]”，“手機號碼是15654541212”。在Claim當中還包括ClaimType，ClaimType代表描述資訊的型別，以上的例子而言，其中ClaimType包括：使用者名稱、email、手機號碼。

 將上面Claim和ClaimType概念對應到現實中的事物來看，比如“檢查駕照”，駕駛員對於交警就是一個被驗證的主體，駕照中的“駕駛員姓名：章某某”、“身份證號碼：4545454545”等一些描述資訊就相當於是一個Claim。

 對於一個被驗證主體(使用者)而言，肯定不會僅僅存在單個Claim，而會存在多個Claim。那麼對於多個Claim構成的資料結構就是“ClaimsIdentity”，可以把“ClaimsIdentity”理解為是被驗證主體的“證件”。另外，“ClaimsIdentity”的持有者也就是被驗證主體被稱為“ClaimsPrincipal”。

通常一個簡單的載荷JSON如下：

{
 "iss":"WebApi",
 "aud":"JD-ERP", 
 "exp":"1650445011"
}

3.3.簽名(Signature)

簽名實際上是一個加密的過程，基於特定內容和指定演算法生成的一段標識，作為驗證接收方傳遞資訊是否被篡改的依據。JWT簽名作為JWT結構的一部分，其中的內容是包括：Header、PayLoad、金鑰，然後通過簽名演算法將三者生成特定字串。

在JWT簽名演算法中，一般有兩個選擇，一種是預設的HS256，另一種就是RS256。

RS256是一種“非對稱加密演算法”，它擁有一組金鑰（公鑰和私鑰），私鑰用於加密(簽名)，公鑰用於解密(驗證簽名)。而HS256則是一種“對稱加密演算法”，加密(簽名)和解密(驗證簽名)都使用同一種金鑰。基於這兩種演算法的理解，在實際的應用當中使用RS256簽名方式會更加安全。

3.4.內容表現形式

JWT會基於一種物件結構生成特定格式的字串，字串中根據JWT的結構也對應了有三個部分，分別由“.”號分割。我們可以通過JWT官方的站點（https://jwt.io/）來檢視JWT全部表現形式，以及可以對其進行分析。

 上圖左側區域的資料，其中紅色部分是“訊息頭”，紫色部分是“載荷”，它們都是基於JSON格式的資料上進行了base64的編碼，才變成了一種特定的字元。藍色部分就是“簽名”，它是由：訊息頭、載荷、金鑰，三個JSON格式資料進行簽名生成的一種特定字元。

上圖右側區域的資料，是將JWT的Token字串放在左側區域解析出來的，通過解析出來的JSON資料就可以方便做一些除錯分析。另外，在底部的“簽名”區域，就可以清晰的看出我們簽名字串是通過什麼樣的方式生成的。其中的金鑰部分是需要我們手動輸入的，輸入後就可以驗證左側的Token是否有效。

 4.結尾

本文主要介紹了關於JWT的理論部分，其中主要包括：作用、應用場景、概念、以及對應的結構等。其中弄懂這些概念也不是一蹴而就的，需要結合實際的操作進行演練才能更有深刻的體會。那麼在下一個章節，我會主要介紹如何通過程式碼一步步在ASP.NET Core中實現JWT的授權與認證。