IdentityServer4之JWT簽名(RSA加密證書)及驗籤

時間 2019-11-17

標籤 identityserver4 identityserver jwt 簽名 rsa 加密證書欄目系統安全简体版

原文原文鏈接

1、前言

在IdentityServer4中有兩種令牌，一個是JWT和Reference Token，在IDS4中默認用的是JWT，那麼這二者有什麼區別呢？node

2、JWT與Reference Token的區別

一、JWT(不可撤回)　　算法

　　JWT是一個很是輕巧的規範，通常被用來在身份提供者和服務提供者間傳遞安全可靠的信息。JWT令牌是一個自包含的訪問令牌 - 它是一個帶有聲明和過時的受保護數據結構。一旦API瞭解了密鑰材料，它就能夠驗證自包含的令牌，而無需與發行者進行通訊。這使得JWT難以撤銷。它們將一直有效，直到它們過時。json

　　JWT常被用於先後端分離，能夠和 Restful API 配合使用，經常使用於構建身份認證機制，一個 JWT 實際上就是一個字符串，它包含了使用.分隔的三部分： Header 頭部 Payload 負載 Signature 簽名（格式：Header.Payload.Signature）後端

在這個三個部分中最關鍵的就是signature。api

　　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 的有效期應該設置得比較短。對於一些比較重要的權限，使用時應該再次對用戶進行認證。

二、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的交互流程圖

3、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 流程圖。

4、JWT中使用RSA加密

在說明JWT使用RSA加密以前咱們先來比較一下其餘的加密算法

一、HS256與RS256的區別

　　HS256 使用密鑰生成固定的簽名，RS256 使用成非對稱進行簽名。簡單地說，HS256 必須與任何想要驗證 JWT的客戶端或 API 共享祕密。即以下圖

　　RS256 生成非對稱簽名，這意味着必須使用私鑰來籤簽名 JWT，而且必須使用對應的公鑰來驗證簽名。與對稱算法不一樣，使用 RS256 能夠保證服務端是 JWT 的簽名者，由於服務端是惟一擁有私鑰的一方。這樣作將再也不須要在許多應用程序之間共享私鑰

二、建立自簽名證書(操做步驟)

　　生產環境（負載集羣）通常須要使用固定的證書籤名與驗籤,以確保重啓服務端或負載的時候 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

生成以下：

三、證書生成以後就可進入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。這樣便可實現防篡改。