1.授權與認證的作用 1.1.資源保護 網路資源保護機制是一個鮮為人知的基本措施，比如我們會對網路相冊設置密碼並指定部分用戶才可訪問，又比如我們網盤的資源分享時設置的訪問密碼等等措施。這種資源保護的機制不光體現於此，作為軟體從業人員對於我們開發的API的訪問也是有一套保護機制的，那麼對應到API的保 ...
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的授權與認證。
知識改變命運
