IdentityServer4之JWT簽名(RSA加密證書)及驗籤
一、前言
在IdentityServer4中有兩種令牌，一個是JWT和Reference Token，在IDS4中預設用的是JWT，那麼這兩者有什麼區別呢？
二、JWT與Reference Token的區別
1、JWT(不可撤回)
JWT是一個非常輕巧的規範，一般被用來在身份提供者和服務提供者間傳遞安全可靠的資訊。JWT令牌是一個自包含的訪問令牌 - 它是一個帶有宣告和過期的受保護資料結構。一旦API瞭解了金鑰材料，它就可以驗證自包含的令牌，而無需與發行者進行通訊。這使得JWT難以撤銷。它們將一直有效，直到它們過期。
JWT常被用於前後端分離，可以和 Restful API 配合使用，常用於構建身份認證機制，一個 JWT 實際上就是一個字串，它包含了使用.分隔的三部分： Header 頭部 Payload 負載 Signature 簽名（格式：Header.Payload.Signature）
在這個三個部分中最關鍵的就是signature。
signature：被用來確認JWT資訊的傳送者是誰，並保證資訊沒有被篡改，使用header中指定的演算法將編碼後的header、編碼後的payload、一個secret進行加密。因此簽名演算法推薦使用RSA或ECDSA非對稱加密演算法。
JWT特點：
A、JWT 預設是不加密，但也是可以加密的。生成原始 Token 以後，可以用金鑰再加密一次。
B、為了減少盜用，JWT 不應該使用 HTTP 協議明碼傳輸，要使用 HTTPS 協議傳輸
C、jwt去中心化的思想：api資源收到第一個請求之後，會去id4伺服器獲取公鑰，然後用公鑰驗證token是否合法，如果合法進行後面的有效性驗證。有且只有第一個請求才會去id4伺服器請求公鑰，後面的請求都會用第一次請求的公鑰來驗證，這也是jwt去中心化驗證的思想。（注：如果簽名證書發生改變則需要重啟有請求ids4伺服器的資源伺服器。）
D、JWT 本身包含了認證資訊，一旦洩露，任何人都可以獲得該令牌的所有許可權。為了減少盜用，JWT 的有效期應該設定得比較短。對於一些比較重要的許可權，使用時應該再次對使用者進行認證。
2、Reference Token(不攜帶任何使用者資料，可撤回)
當使用 Reference token 的時候，服務端會對 Token 進行持久化，當客戶端請求資源端（API）的時候，資源端需要每次都去服務端通訊去驗證 Token 的合法性[/connect/introspect]，IdentityServer4.AccessTokenValidation 中介軟體中可以配置快取一定的時候去驗證,並且 Token 是支援撤銷[/connect/revocation]的。
使用引用令牌時 - IdentityServer會將令牌的內容儲存在資料儲存中，並且只會將此令牌的唯一識別符號發回給客戶端。接收此引用的API必須開啟與IdentityServer的反向通道通訊以驗證令牌。如下：access_token就是唯一標識。（注不攜帶任何資料）
當 AccessTokenType 定義為 Reference 的時候，驗證資源端要注意配置 ApiSecrets 以確保 POST /connect/introspect HTTP/1.1 介面能驗證通過,當 AccessTokenType 定義為 Jwt 的時候則資源端可不配置 options.ApiSecret 選項。如下圖：
Reference Token官方圖如下：
以上就是JWT與Reference token的區別。為了減少訪問中心伺服器的資源，使用JWT還是非常棒的，畢竟與伺服器互動的資源還是非常的昂貴的。不過具體的還得視實際情況而定。
那麼我們來看一下在IDS4中API使用JWT以及Reference Token的互動流程圖
三、IDS4中API使用JWT以及Reference Token與認證中心的互動流程圖
此圖為：JWT，當然大家可以通過fiddler 抓包工具來檢視一下具體的資料流就能明白其中的道理。
注：資源伺服器在第一次解析AccessToken的時候會先到授權伺服器獲取配置資料（例如會訪問：http://localhost:5000/.well-known/openid-configuration 獲取配置的，http://localhost:5000/.well-known/openid-configuration/jwks 獲取jwks）），之後解析AccessToken都會使用第一次獲取到的配置資料，因此如果授權服務的配置更改了(加密證書等等修改了)，那麼應該重啟資源伺服器使之重新獲取新的配置資料；
此圖為：Reference Token
以上即JWT與Reference Token 流程圖。
四、JWT中使用RSA加密
在說明JWT使用RSA加密之前我們先來比較一下其他的加密演算法
1、HS256與RS256的區別
HS256 使用金鑰生成固定的簽名，RS256 使用成非對稱進行簽名。簡單地說，HS256 必須與任何想要驗證 JWT的 客戶端或 API 共享祕密。即 如下圖
RS256 生成非對稱簽名，這意味著必須使用私鑰來籤簽名 JWT，並且必須使用對應的公鑰來驗證簽名。與對稱演算法不同，使用 RS256 可以保證服務端是 JWT 的簽名者，因為服務端是唯一擁有私鑰的一方。這樣做將不再需要在許多應用程式之間共享私鑰
2、建立自簽名證書(操作步驟)
生產環境（負載叢集）一般需要使用固定的證書籤名與驗籤,以確保重啟服務端或負載的時候 Token 都能驗籤通過。（不使用臨時證書）
那麼證書如何生成請看下面分解步驟：
第一種：使用OpenSSL生成證書，注：RSA加密證書長度要2048以上，否則服務執行會拋異常
#Linux系統生成證書：（推薦使用） sudo yum install openssl (CentOS) #生成私鑰檔案 openssl genrsa -out idsrv4.key 2048 #建立證書籤名請求檔案 CSR（Certificate Signing Request），用於提交給證書頒發機構（即 Certification Authority (CA)）即對證書籤名，申請一個數字證書。 openssl req -new -key idsrv4.key -out idsrv4.csr #生成自簽名證書（證書頒發機構（CA）簽名後的證書，因為自己做測試那麼證書的申請機構和頒發機構都是自己,crt 證書包含持有人的資訊，持有人的公鑰，以及簽署者的簽名等資訊。當用戶安裝了證書之後，便意味著信任了這份證書，同時擁有了其中的公鑰。） openssl x509 -req -days 365 -in idsrv4.csr -signkey idsrv4.key -out idsrv4.crt （包含公鑰） #自簽名證書與私匙合併成一個檔案（注：.pfx中可以加密碼保護，所以相對安全些） openssl pkcs12 -export -in idsrv4.crt -inkey idsrv4.key -out idsrv4.pfx (注：在生成的過程中會讓我們輸入Export Password)
證書截圖如下：
第二種:
openssl req -newkey rsa:2048 -nodes -keyout idsrv4.key -x509 -days 365 -out idsrv4.cer openssl pkcs12 -export -in idsrv4.cer -inkey idsrv4.key -out idsrv4.pfx
生成如下：
3、證書生成之後就可進入VS2017中配置
拷貝生成的證書，放到認證/授權伺服器專案中。(VS中配置檔案設定檔案始終複製)，最後把證書路徑和密碼配置到 IdentityServer 中，因為我們自簽名的證書是 PKCS12 (個人數字證書標準，Public Key Cryptography Standards #12) 標準包含私鑰與公鑰）標準，包含了公鑰和私鑰。
A、在appsetting.json 配置檔案中新增如下：此處需要配置password，自定義即可。
B、在starup.cs中ConfigureServices方法中配置如下即可。
配置完後即可。我們啟動IDS4專案即可生成加密的token。
將得到的token在jwt.io 網站來認證一下：把字尾為 crt 公鑰、key私鑰複製到驗證中，發現認證ok。這樣即可實現防篡改。
五、總結
在實際環境中應該使用加密的token，而不應該使用臨時令牌。以及儘量設定token的過期時間短，以及重新整理token的機制，這樣可以儘可能的保護token以及資料安全。
asp.net core 交流群：787464275 歡迎加群交流
如果您認為這篇文章還不錯或者有所收穫，您可以點選右下角的【推薦】按鈕精神支援，因為這種支援是我繼續寫作，分享的最大動力！
來源：https://www.cnblogs.com/guolianyu/p/9872661.html