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的授權與認證，
知識改變命運轉載請註明出處，本文鏈接：https://www.uj5u.com/net/460727.html
標籤：.NET技术