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，自定義即可。