聊聊NET之JWT理解
開篇語
本文內容參考多位大佬的文章編寫而成。
介紹
jwt是一個基于json的、用于在網(wǎng)絡上聲明某種主張的令牌，jwt通常是用三部分組成：頭信息，消息體，簽名。他是一種雙方之間傳遞安全信息的表述性聲明規(guī)范。主要用于集群分布式中。
作用：可以做權限驗證的使用，是一種標準化的數(shù)據(jù)傳輸規(guī)范，但是目的不是為了數(shù)據(jù)加密和保護。
使用場景
- 授權：用于授權而并非是身份驗證。通過身份驗證，我們驗證用戶的用戶名和密碼是否有效，并將用戶登錄到系統(tǒng)中，通過授權，我們可以驗證發(fā)送到服務器的請求是否屬于通過身份驗證登錄的用戶，從而可以授予該用戶訪問系統(tǒng)的權限，繼而批準該用戶使用獲取的token訪問路由、服務和資源。
- 信息交換：json web token是在雙方之間安全地傳輸信息的一種好方法。因為jwt可以被簽名，所以使您能夠確保發(fā)送方是他們聲稱的那一方，由于簽名使用header和payload計算的，因此還使您能驗證發(fā)送的內容沒有被篡改。
對比token+redis
JWT就是Json Web Token，就是Token的典型方式。JWT和Token+Redis的區(qū)別，其實都是Token，只是JWT的可靠性保障是來源于加密算法(對稱加密和非對稱兩種)，而Token+Redis的方案是依靠的后臺數(shù)據(jù)存儲。這兩個本質也就帶來了使用上的區(qū)別：
1 JWT是去中心化的，不需要任何后臺數(shù)據(jù)的共享，第三方認證、跨數(shù)據(jù)中心認證、微服務等，都適合采用JWT的方式，當然，因為是去中心化的，不是實時驗證，所以本質上來說token的主動過期是做不到的(要做到就會違背初衷)
2 Token+Redis是中心化的，要能識別token必須能訪問該Redis，除非是有特別需求，要求每次token都實時檢測，否則的話還是選擇JWT，畢竟是成熟通用的技術，溝通維護成本也低，對開發(fā)者也友好一些。
這點我忘記是摘錄哪個大佬的文章了，所以沒有給出引用地址很抱歉。
流程
用戶通過登錄去向服務系統(tǒng)發(fā)起請求，然后生成帶一定用戶信息的數(shù)據(jù)作為令牌(jwt)返回給用戶，用戶拿到返回過來的信息在請求接口的時候放入頭部，服務系統(tǒng)會從頭部獲取到令牌后驗證簽名的有效性，對客戶端做出相應的響應。
- Authorization: Bearer <token>
如果想在接口中獲取jwt令牌，可以使用
- var tokenHeader = HttpContext.Request.Headers["Authorization"].ToString().Replace("Bearer ", "");
現(xiàn)在感覺作用就是可以通過jwt實現(xiàn)權限，在系統(tǒng)中定義好有哪些權限，然后在方法頭部去設置哪些角色可以去訪問這個東西。如果存放token，我的想法是把用戶的信息放到jwt內部，然后前端通過登錄去獲取這東西，然后我返回這個東西到前臺，每次調用接口時候把這個東西傳出過來，然后我通過將這個解密獲取到我登錄時候存進去的信息。然后進行我自己的操作。
注意：
生成jwt時候的key必須在16位以上，否則會因為長度不夠拋出異常
jwt本身是不加密的，里面包含的信息任何人都可以讀取到。
jwt的簽名部分是對前兩部分的簽名，防止數(shù)據(jù)被篡改，
Bearer認證
Bearer認證(也叫做令牌認證)是一種HTTP認證方案，其中包含的安全令牌的叫做Bearer Token。因此Bearer認證的核心是Token。那如何確保Token的安全是重中之重。一種方式是使用Https，另一種方式就是對Token進行加密簽名。而JWT就是一種比較流行的Token編碼方式。
驗證
- //全局增加配置
- services.AddControllers((options) =>
- {
- options.Filters.Add(new AuthorizeFilter());//添加全局的Authorize
- });
- //控制器或者方法增加配置
- [Authorize]
原理
- 獲取token
- 第一步：對token進行切割
- 第二步：對第二段解碼，獲取payload，檢測token是否超時
- 第三步：把前兩段拼接再次執(zhí)行HS256加密，把加密后的密文和第三段比較。如果相等，認證通過
參考文檔
曉晨：https://www.cnblogs.com/stulzq/p/7417548.html
老張的哲學：https://www.cnblogs.com/laozhang-is-phi/category/1413402.html
