一、概述
在IdentityServer4中有兩種令牌，一個是JWT和Reference Token，在IDS4中默認用的是JWT，那么這兩者有什么區別呢？
二、JWT與Reference Token的區別
1、JWT
JWT不可撤回。JWT令牌是一個自包含的訪問令牌 - 它是一個帶有聲明和過期的受保護數據結構。一旦API了解了密鑰材料，它就可以驗證自包含的令牌，而無需與發行者進行通信。這使得JWT難以撤銷。它們將一直有效，直到它們過期。JWT常被用於前后端分離，可以和 Restful API 配合使用，常用於構建身份認證機制，一個 JWT 實際上就是一個字符串，它包含了使用.分隔的三部分： Header 頭部 Payload 負載 Signature 簽名。在這個三個部分中最關鍵的就是signature。signature被用來確認JWT信息的發送者是誰，並保證信息沒有被篡改，使用header中指定的算法將編碼后的header、編碼后的payload、一個secret進行加密。因此簽名算法推薦使用RSA或ECDSA非對稱加密算法。
JWT特點：
- JWT 默認是不加密，但也是可以加密的。生成原始 Token 以后，可以用密鑰再加密一次。
- 為了減少盜用，JWT 不應該使用 HTTP 協議明碼傳輸，要使用 HTTPS 協議傳輸
- jwt去中心化的思想：api資源收到第一個請求之后，會去id4服務器獲取公鑰，然后用公鑰驗證token是否合法，如果合法進行后面的有效性驗證。有且只有第一個請求才會去id4服務器請求公鑰，后面的請求都會用第一次請求的公鑰來驗證，這也是jwt去中心化驗證的思想。（注：如果簽名證書發生改變則需要重啟有請求ids4服務器的資源服務器。）
- JWT 本身包含了認證信息，一旦泄露，任何人都可以獲得該令牌的所有權限。為了減少盜用，JWT 的有效期應該設置得比較短。對於一些比較重要的權限，使用時應該再次對用戶進行認證。
2、Reference Token
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還是非常棒的，畢竟與服務器交互的資源還是非常的昂貴的。
三、交互流程圖
資源服務器在第一次解析AccessToken的時候會先到授權服務器獲取配置數據（例如會訪問：http://localhost:5000/.well-known/openid-configuration 獲取配置的，http://localhost:5000/.well-known/openid-configuration/jwks 獲取jwks）），之后解析AccessToken都會使用第一次獲取到的配置數據，因此如果授權服務的配置更改了(加密證書等等修改了)，那么應該重啟資源服務器使之重新獲取新的配置數據。
1、API使用JWT與認證中心的交互流程圖
2、API使用Reference Token與認證中心的交互流程圖
四、JWT中使用RSA加密
在說明JWT使用RSA加密之前我們先來比較一下其他的加密算法
1、HS256與RS256的區別
HS256 使用密鑰生成固定的簽名，RS256 使用成非對稱進行簽名。簡單地說，HS256 必須與任何想要驗證 JWT的 客戶端或 API 共享秘密。即 如下圖
RS256 生成非對稱簽名，這意味着必須使用私鑰來簽簽名 JWT，並且必須使用對應的公鑰來驗證簽名。與對稱算法不同，使用 RS256 可以保證服務端是 JWT 的簽名者，因為服務端是唯一擁有私鑰的一方。這樣做將不再需要在許多應用程序之間共享私鑰。
五、生成證書
1、前言
services.AddIdentityServer()
.AddDeveloperSigningCredential()
.AddTemporarySigningCredential();
IDS4提供了以上兩種臨時證書生成的方案，既然有提供了生成證書的方案，為什么還要自己生成證書呢？原因如下：
- IDS4項目啟動時，AddDeveloperSigningCredential或AddTemporarySigningCredential都會創建一個新的臨時證書，這時候就會導致一個問題，重啟之前生成的
access_token，在重啟之后，就不適用了，因為證書改變了，對應的加密方式也改變了，所以，就會出現下面這個問題：
- IDS4項目啟動時， AddDeveloperSigningCredential或AddTemporarySigningCredential都會創建一個新的臨時證書，它默認會存到硬盤上，但是這個方法只適合用於IDS4在單機運行的場景，如果是負載集群中，每台服務器上隨機產生的證書都是不一樣的。
綜合以上兩點，所以在生產環境我們還是要生成一個統一的證書。然后使用AddSigningCredential()方法將證書注入程序。
2、使用OpenSSL創建證書（Windows）
- 安裝OpenSSL工具 ，官網下載地址：https://slproweb.com/products/Win32OpenSSL.html
- 下載完成后，雙擊exe傻瓜式完成安裝，將安裝的bin目錄加入到系統環境變量
- 管理員身份打開cmd，輸入下面命令：
openssl req -newkey rsa:2048 -nodes -keyout cas.clientservice.key -x509 -days 365 -out cas.clientservice.cer
- 如上圖，根據提示輸入相應的注冊信息。執行上面命令之后，我們可以在C:\Users\lenovo目錄下面找到cas.clientservice.cer和cas.clientservice.key兩個文件：
- 下面的命令是將生成的證書和Key封裝成一個文件，以便IDS4可以使用它們去正確地簽名tokens，文件會生成在CMD執行目錄“C:\Users\lenovo”中。
openssl pkcs12 -export -in cas.clientservice.cer -inkey cas.clientservice.key -out IS4.pfx
IS4.pfx是證書名稱，可以自己修改，中途會提示讓你輸入Export Password，這個password在IS4中會用到，需要記下來。
3、項目中配置證書
- 拷貝生成的證書，放到認證/授權服務器項目中。證書屬性改為始終復制。
- 在appsetting.json 配置文件配置如下信息：
- 在starup.cs中ConfigureServices方法中配置如下即可。
