從壹開始 [ Ids4 ] 之二║ 基礎知識集合 & 項目搭建一

時間 2019-11-05

原文原文鏈接

前言

哈嘍你們又見面啦，感受很久沒更新了，這幾天看了一本書《解憂雜貨鋪》，嗯挺好的，推薦一下😀。html

不過仍是要學習了，這些天簡單的看了看 Id4 的資料，才發現原來關於 Id4 的系列文章真是數不勝數，並且還有不少的深度好文章，說的灰常之詳細，因此一度打消了我寫這一系列的衝動和信心，不過仍是有一部分的小夥伴尚未學習過，因此我決定我之後就把 IdentityServer4 的基礎概念知識點，就少寫些，重點寫如何在項目中使用吧，本文的知識點，簡單過一遍，腦子裏有這個東西就好了，再之後的開發中，多動手就知道了，特別簡單的，這裏說明一下，在之前的Blog.Core 系列中，有關 JWT 的知識，我單拎出來一個小Demo，有不懂的能夠下載看看（https://github.com/anjoy8/Blog.Core/blob/master/Blog.Core/wwwroot/Autho.jwt.rar）。vue

零、今天要完成紅色的部分

1、常見術語

一、身份認證服務器（IdentityServer）

IdentityServer 是基於OpenID Connect協議標準的身份認證和受權程序，它實現了OpenID Connect 和 OAuth 2.0 協議。node

一樣的角色，不一樣的文檔使用不一樣的術語。在有些文檔中，它（IdentityServer）可能會被叫作安全令牌服務器（security token service）、身份提供者（identity provider）、受權服務器（authorization server）、標識提供方（(IP-STS，什麼是IP-STS）等等。git

可是它們都是同樣的，都是向客戶端發送安全令牌（security token），github

IdentityServer有許多功能：web

保護你的資源
使用本地賬戶或經過外部身份提供程序對用戶進行身份驗證
提供會話管理和單點登陸
管理和驗證客戶機
向客戶發出標識和訪問令牌
驗證令牌

二、用戶（User）

用戶是使用已註冊的客戶端（指在id4中已經註冊）訪問資源的人。算法

三、客戶端（Client）

客戶端就是從identityserver請求令牌的軟件（你能夠理解爲一個app便可），既能夠經過身份認證令牌來驗證識別用戶身份，又能夠經過受權令牌來訪問服務端的資源。可是客戶端首先必須在申請令牌前已經在identityserver服務中註冊過。chrome

實際客戶端不只能夠是Web應用程序，app或桌面應用程序（你就理解爲pc端的軟件便可），SPA，服務器進程等。數據庫

四、資源（Resources）

資源就是你想用identityserver保護的東東，能夠是用戶的身份數據或者api資源。
每個資源都有一個惟一的名稱，客戶端使用這個惟一的名稱來肯定想訪問哪個資源（在訪問以前，實際identityserver服務端已經配置好了哪一個客戶端能夠訪問哪一個資源，因此你沒必要理解爲客戶端只要指定名稱他們就能夠隨便訪問任何一個資源）。json

用戶的身份信息實際由一組claim組成，例如姓名或者郵件都會包含在身份信息中（未來經過identityserver校驗後都會返回給被調用的客戶端）。

API資源就是客戶端想要調用的功能（一般以json或xml的格式返回給客戶端，例如webapi，wcf,webservice），一般經過webapi來創建模型，可是不必定是webapi，我剛纔已經強調可使其餘類型的格式，這個要看具體的使用場景了。

五、身份令牌（Identity Token）

身份令牌表示身份驗證過程的結果。它最低限度地標識了某個用戶，還包含了用戶的認證時間和認證方式。它能夠包含額外身份數據。

一個身份令牌指的就是對認證過程的描述。它至少要標識某個用戶（Called the sub aka subject claim）的主身份信息，和該用戶的認證時間和認證方式。可是身份令牌能夠包含額外的身份數據，具體開發者能夠自行設定，可是通常狀況爲了確保數據傳輸的效率，開發者通常不作過多額外的設置，你們也能夠根據使用場景自行決定。

六、訪問令牌（Access Token）

訪問令牌容許訪問API資源。客戶端請求訪問令牌並將其轉發到API。訪問令牌包含有關客戶端和用戶的信息（若是存在）。 API使用該信息來受權訪問其數據。

訪問令牌容許客戶端訪問某個 API 資源。客戶端請求到訪問令牌，而後使用這個令牌來訪問 API資源。訪問令牌包含了客戶端和用戶（若是有的話，這取決於業務是否須要，但一般沒必要要）的相關信息，API經過這些令牌信息來授予客戶端的數據訪問權限。

七、刷新令牌（Refresh Token）

access token 是客戶端訪問資源服務器的令牌。擁有這個令牌表明着獲得用戶的受權。然而，這個受權應該是臨時的，有必定有效期。這是由於，access token 在使用的過程當中可能會泄露。給 access token 限定一個較短的有效期能夠下降因 access token 泄露而帶來的風險。

　　然而引入了有效期以後，客戶端使用起來就不那麼方便了。每當 access token 過時，客戶端就必須從新向用戶索要受權。這樣用戶可能每隔幾天，甚至天天都須要進行受權操做。這是一件很是影響用戶體驗的事情。但願有一種方法，能夠避免這種狀況。

　　因而 Oauth2.0 引入了 refresh token 機制。refresh token 的做用是用來刷新 access token。鑑權服務器提供一個刷新接口，例如：

　　http://xxx.xxx.com/refresh?refreshtoken=&client_id=

　　傳入 refresh token 和 client_id，鑑權服務器驗證經過後，返回一個新的 access token。爲了安全，Oauth2.0 引入了兩個措施：

　　1，Oauth2.0 要求，refresh token 必定是保存在客戶端的服務器上的，而毫不能存放在狹義的客戶端（例如移動 app、PC端軟件）上。調用 refresh 接口的時候，必定是從服務器到服務器的訪問；

　　2，Oauth2.0 引入了 client_secret 機制。即每個 client_id 都對應一個 client_secret。這個 client_secret 會在客戶端申請 client_id 時，隨 client_id 一塊兒分配給客戶端。客戶端必須把 client_secret 妥善保管在服務器上，決不能泄露。刷新 access token 時，須要驗證這個 client_secret。

　　因而，實際上的刷新接口應該是相似這樣的：

　　http://xxx.xxx.com/refresh?refreshtoken=&client_id=&client_secret=

　　以上就是 refresh token 機制。refresh token 的有效期很是長，會在用戶受權時，隨 access token 一塊兒重定向到回調 url，傳遞給客戶端。

2、 OAuth 2.0 和 OpenID Connect

一、什麼是OAuth2.0 ?

OAuth（開放受權）是一個開放標準，容許用戶讓第三方應用訪問該用戶在某一網站上存儲的私密的資源（如照片，視頻，聯繫人列表），而無需將用戶名和密碼提供給第三方應用。就好比我用QQ登陸博客園，那博客園（第三方應用）的暱稱就能夠是個人QQ（某網站）暱稱，它獲取到了個人QQ暱稱，並存到了博客園的數據庫，我之後就一直可使用QQ來登陸博客園，可是博客園殊不知道我QQ的用戶名和密碼。

OAuth 容許用戶提供一個令牌，而不是用戶名和密碼來訪問他們存放在特定服務提供者的數據。每個令牌受權一個特定的網站（例如，視頻編輯網站）在特定的時段（例如，接下來的 2 小時內）內訪問特定的資源（例如僅僅是某一相冊中的視頻）。這樣，OAuth 讓用戶能夠受權第三方網站訪問他們存儲在另外服務提供者的某些特定信息，而非全部內容。

OAuth 2.0 四種受權模式：

受權碼模式（authorization code）

簡化模式（implicit grant type）

密碼模式（resource owner password credentials）

客戶端模式（Client Credentials Grant）

具體的概念和如何使用不細說，之後會分四篇文章詳細說明，今天主要是基礎知識和項目的搭建。

二、什麼是 OpenID Connect ？

簡單來講：

OpenID Connect是基於OAuth 2.0規範族的可互操做的身份驗證協議。它使用簡單的REST / JSON消息流來實現，和以前任何一種身份認證協議相比，開發者能夠輕鬆集成。
OpenID Connect容許開發者驗證跨網站和應用的用戶，而無需擁有和管理密碼文件。
OpenID Connect容許全部類型的客戶,包括基於瀏覽器的JavaScript和本機移動應用程序,啓動登陸流動和接收可驗證斷言對登陸用戶的身份。

進一步來講：

OpenID Connect是OAuth 2.0協議之上的簡單身份層，用 API 進行身份交互的框架，容許客戶端根據受權服務器的認證結果最終確認用戶的身份，以及獲取基本的用戶信息；
它支持包括Web、移動、JavaScript在內的全部客戶端類型；
它是可擴展的協議，容許你使用某些可選功能，如身份數據加密、OpenID提供商發現、會話管理；

OpenID Connect vs OpenID 2.0：OpenID Connect完成不少與OpenID 2.0相同的任務，是API-friendly，定義了可選的簽名和加密的機制；OAuth 1.0和OpenID 2.0的集成須要擴展，而OpenID Connect協議自己就創建在OAuth 2.0之上。

爲何開發者要使用OpenID Connect？
由於它很簡單,可靠,安全,並讓他們擺脫困難和危險的存儲和管理別人的密碼。也有好處,它讓用戶的生活更容易在網站註冊和註冊從而減小遺棄。

三、JWT 和 OAuth2.0 的比較

要比較JWT和OAuth2，首先要明白一點就是，這兩個根本沒有可比性，是兩個徹底不一樣的東西。

JWT是一種認證協議
JWT提供了一種用於發佈接入令牌（Access Token)，並對發佈的簽名接入令牌進行驗證的方法。令牌（Token）自己包含了一系列聲明，應用程序能夠根據這些聲明限制用戶對資源的訪問。
OAuth2是一種受權框架
另外一方面，OAuth2是一種受權框架，提供了一套詳細的受權機制（指導）。用戶或應用能夠經過公開的或私有的設置，受權第三方應用訪問特定資源。

既然 JWT和OAuth2.0 沒有可比性，爲何還要把這兩個放在一塊兒說呢？實際中確實會有不少人拿 JWT和OAuth2.0 做比較。不少狀況下，在討論OAuth2的實現時，會把JSON Web Token做爲一種認證機制使用。這也是爲何他們會常常一塊兒出現。

四、OpenID 是怎麼認證用戶的？

一個網站若是想要接入 OpenID 認證是很是簡單的，不須要建立應用，不須要 App Key ，不須要 Secret ，只須要將用戶導向 OpenID Provider 的 Entry 並帶上 Callback ，用戶只要贊成提供信息，你就能夠拿到這個用戶的「惟一標識」。

請注意這裏我使用了「惟一標識」這種說法，由於對於網站來講，OpenID Provider 提供的既不是用戶的 UID ，也不是用戶的 E-Mail ，好比 Google 在默認狀況下提供的就是一個幾十位長的字符串，這個字符串是隨機生成的，第三方網站沒法從中得到用戶的任何私人信息。這麼說可能很抽象，舉個例子：

好比我用 Google 的 OpenID 服務登陸 xxx.com ， xxx.com 先把我導向 Google 的受權頁面，我使用 Google 賬號 test@gmail.com 登陸並贊成後，頁面跳回 xxx.com ， xxx.com 拿到了個人「惟一標識」，這個惟一標識多是 cdxxxxxxxaaf6b73bcb04a1 ，xxx.com 從這個字符串裏沒法得到任何 test@gmail.com 的我的信息（甚至連郵箱地址也不知道）， xxx.com 只知道之後只要使用谷歌登陸並返回 cdxxxxxxxaaf6b73bcb04a1 這個標識符，那就是我在登陸。

顯而易見，OpenID 是專爲登陸認證而生，它使用簡單，門檻很低，可是若是你想在認證過程當中得到用戶的其餘信息（好比 E-Mail ）就得多作一步了。

你這個時候可能就會問了，那有哪些網站使用的是 OpenID 登陸的呢，我簡單看了看，好像都是基於 OAuth 開發的，並且也看到了一個博問，是這麼說的：

具體的我們就不分析了，如今基本都是使用的 OAuth2.0 ，不過如今使用 Id4 是結合了 OAuth2.0 和 OpenID的。

五、OAuth 又是怎麼認證用戶的？

與 OpenID 相比，網站想接入 OAuth 要稍微麻煩點，網站須要先建立應用，拿到 Key 和 Secret ，才能接入 Provider 。

OAuth 的受權過程並非身份認證的過程，這一點須要特別清楚，網站走完 OAuth 流程並拿到用戶的受權 token 後還須要經過 token 調用相應的用戶信息接口才能得到「惟一標識」，舉個例子：

我想經過新浪微博登陸 xxx.com ，xxx.com 要先把我 redirect 到新浪微博的受權頁面，我經過微博賬號登陸並受權後，頁面跳回 xxx.com ，xxx.com 拿到個人訪問 token 後還要再調用一個接口來得到個人新浪會員 UID ，這個 UID 就是新浪用戶的「惟一標識」了。

能夠看出，OAuth 相對於 OpenID 最大的區別就是，網站其實是拿到了你的賬戶訪問權限繼而確認你的身份，這是一個安全隱患，由於網站在拿到你的「惟一標識」的同時還拿到了一把你的帳戶的「臨時鑰匙」。至於網站會不會拿這把鑰匙「幹壞事」，這個只有站長內心清楚。同時 OAuth 還比 OpenID 多了幾個額外的請求步驟，登陸所費時間必定是長於 OpenID 的。

六、OAuth和OpenID的區別

OAuth關注的是authorization；而OpenID側重的是authentication。從表面上看，這兩個英文單詞很容易混淆，但實際上，它們的含義有本質的區別：

authorization: n. 受權，承認；批准，委任
authentication: n. 證實；鑑定；證明

OAuth關注的是受權，即：「用戶能作什麼」；而OpenID關注的是證實，即：「用戶是誰」。

OpenID是關於證實、證明身份（Authentication）的，比如火車站進站的時候拿出身份證和車票來看，比對是否同一我的。這是在回答「我是誰？這就是我」，是爲了證明「這不是一個匿名的不可查的信息源頭」，由於匿名對象和信息對網絡服務商來講很差統計管理，也不利於產生價值。

OAuth 是關於受權、許可（Authorization）的，比如坐飛機過安檢的時候除了看身份證，還要求掏出兜裏的東西，拿出包裏的東西、手機等隨身物品以便檢查，這時就須要獲得被檢查人的許可才行，被檢查人有權利扭頭就走，但要想登機，必須給予許可、掏出物品。這是在回答「我贊成讓你對我進一步作些什麼」，是爲了在被授予權限的前提下，更多的獲取除了帳號密碼之外的我的信息，例如：聯繫人通信錄，郵箱號，電話號，地址，照片，聊天記錄，網絡發言、活動記錄，GPS 信息等等，來知足用戶對服務的功能須要，或者「其餘須要」。

//這裏有個網友的說明，我感受挺好的

現在愈來愈多的網站，以及一些應用程序都開始使用第三方社交平臺帳戶登陸，那這裏就會涉及到安全性的問題，隱私的問題，你不能隨意來獲取個人資料，固然你來使用個人資料，你要通過用戶的贊成，那這個用戶是否是我平臺上，仍是要來向我求證，那在這個過程當中，實際上就出現了兩個過程，咱們仍是直接使用上次的例子來講明，比較直觀，CSDN使用QQ登陸，進入csdn的登陸頁，點擊使用QQ登陸：

在進入到QQ登陸界面後，最開始是要請求認證，用戶輸入QQ號和密碼，點擊登陸，騰訊互聯會先進行驗證該用戶是否爲個人用戶，若是是個人用戶，那麼我會通知你（CSDN），他是個人用戶，你可使用該帳戶登陸你的系統，這個過程就是認證（Authentication），認證就是證實你是誰，你是不是真實存在的，就好像，快遞員來給你送快遞，讓你出示你的身份證，他肯定你是本人後，把快遞給你，這就是OpenID。

而在QQ受權登陸下方，有兩給CheckBox複選框，能夠容許CSDN得到您的暱稱、頭像、性別，這是在認證以後的事了，在騰訊互聯你是我平臺的用戶後，你能夠本身選擇CSDN是否有權去獲取你的相關信息，當你勾選後，騰訊互聯就把你的這些基本信息給了CSDN，這個過程就是受權（Authorization），受權就是肯定了你是誰後，又把屬於你的東西給了別人，猶如你向快遞員出示了身份證，而後你又把你房門的密碼給了他，並告訴他說，我把房門密碼給你，你幫我放到我客廳裏吧。

七、OAuth 、OpenID 和 OpenID Connect 的關係

簡要而言，OIDC是一種安全機制，用於應用鏈接到身份認證服務器（Identity Service）獲取用戶信息，並將這些信息以安全可靠的方法返回給應用。

在最初，由於OpenID1/2常常和OAuth協議（一種受權協議）一塊兒說起，因此兩者常常被搞混。

OpenID是Authentication，即認證，對用戶的身份進行認證，判斷其身份是否有效，也就是讓網站知道「你是你所聲稱的那個用戶」；

OAuth是Authorization，即受權，在已知用戶身份合法的狀況下，經用戶受權來容許某些操做，也就是讓網站知道「你能被容許作那些事情」。
由此可知，受權要在認證以後進行，只有肯定用戶身份只有才能受權。

(身份驗證)+ OAuth 2.0 = OpenID Connect

OpenID Connect是「認證」和「受權」的結合，由於其基於OAuth協議，因此OpenID-Connect協議中也包含了client_id、client_secret還有redirect_uri等字段標識。這些信息被保存在「身份認證服務器」，以確保特定的客戶端收到的信息只來自於合法的應用平臺。這樣作是目的是爲了防止client_id泄露而形成的惡意網站發起的OIDC流程。

舉個例子。某個用戶使用Facebook應用「What online quiz best describes you?」 ，該應用能夠經過Facebook帳號登陸，則你能夠在應用中發起請求到「身份認證服務器」（也就是Facebook的服務器）請求登陸。這時你會看到以下界面，詢問是否受權。

在 OAuth 中，這些受權被稱爲scope。OpenID-Connect也有本身特殊的scope--openid ,它必須在第一次請求「身份鑑別服務器」（Identity Provider,簡稱IDP）時發送過去。

3、建立基於EFCore的Idp項目

你能夠參考官方文檔：Docs » Welcome to IdentityServer4

一、創建空的NetCore MVC 項目

這個過程很簡單，由於你能看這個系列，證實你的 NetCore 功底已經很高了，至少中等，若是不會，請時光機回到個人第一個先後端分離系列。

一、建立一個新的ASP.NET Core項目；//可使用命令行建立

二、選擇「空白」選項；//這裏建立空的應用程序是爲了後面方便引入UI界面

三、設置項目使用 kestrel 服務器，刪除IIS；

四、配置端口號；//我這裏是5002，可自定義設置

二、安裝並配置IdentityServer4

一、使用 nuget 添加 IdentityServer4 包；//固然你也可使用命令： Install-Package IdentityServer4

二、配置認證服務中間件管道；//app.UseIdentityServer();

三、配置 IdentityServer 相關服務；

這裏不只要把 IdentityServer 註冊到容器中, 還要至少對其配置四點內容：

一、這個 Authorization Server 保護了哪些 API （資源）；

二、哪些客戶端 Client（應用）可使用這個 Authorization Server；

三、指定可使用 Authorization Server 受權的 Users（用戶）；

四、指定做用域定義系統中的 IdentityResources 資源；//這個在之後說到 OpenId的時候再說，這裏伏筆

首先在項目根目錄下，創建文件 InMemoryConfig.cs：

    public static class InMemoryConfig
    {
        // 這個 Authorization Server 保護了哪些 API （資源）
        public static IEnumerable<ApiResource> GetApiResources()
        {
            return new[]
            {
                    new ApiResource("blog.core.api", "Blog.Core API")
                };
        }
        // 哪些客戶端 Client（應用） 可使用這個 Authorization Server
        public static IEnumerable<Client> GetClients()
        {
            return new[]
            {
                    new Client
                    {
                        ClientId = "blogvuejs",//定義客戶端 Id
                        ClientSecrets = new [] { new Secret("secret".Sha256()) },//Client用來獲取token
                        AllowedGrantTypes = GrantTypes.ResourceOwnerPasswordAndClientCredentials,//這裏使用的是經過用戶名密碼和ClientCredentials來換取token的方式. ClientCredentials容許Client只使用ClientSecrets來獲取token. 這比較適合那種沒有用戶參與的api動做
                        AllowedScopes = new [] { "blog.core.api" }// 容許訪問的 API 資源
                    }
                };
        }
        // 指定可使用 Authorization Server 受權的 Users（用戶）
        public static IEnumerable<TestUser> Users()
        {
            return new[]
            {
                    new TestUser
                    {
                        SubjectId = "1",
                        Username = "laozhang",
                        Password = "laozhang"
                    }
            };
        }
    }

GetApiResources：這裏指定了name和display name，之後api使用authorization server的時候，這個name必定要一致, 不然就很差用的。

GetClients： Client的屬性太多了，基本的上邊已經註釋了

Users: 這裏的內存用戶的類型是TestUser, 只適合學習和測試使用, 實際生產環境中仍是須要使用數據庫來存儲用戶信息的, 例如接下來會使用asp.net core identity. TestUser的SubjectId是惟一標識.

而後回到 Startup 的 ConfigureServices 方法種：

咱們須要對token進行簽名，這意味着 identity server 須要一對public和private key。不過咱們如今是本地調試，能夠告訴identity server在程序的運行時候對這項工做進行設定: AddDeveloperSigningCredential()，它默認會存到硬盤上的，因此每次重啓服務不會破壞開發時的數據同步。這個方法只適合用於identity server4在單個機器運行，若是是 production 你得使用AddSigningCredential()這個方法：

    public class Startup
    {

        public IConfiguration Configuration { get; }
        public IHostingEnvironment Environment { get; }

        public Startup(IConfiguration configuration, IHostingEnvironment environment)
        {
            Configuration = configuration;
            Environment = environment;
        }

        public void ConfigureServices(IServiceCollection services)
        {
            services.AddMvc();

            var builder = services.AddIdentityServer(options =>
            {
                options.Events.RaiseErrorEvents = true;
                options.Events.RaiseInformationEvents = true;
                options.Events.RaiseFailureEvents = true;
                options.Events.RaiseSuccessEvents = true;
            })
            // in-memory, code config
            .AddTestUsers(InMemoryConfig.Users().ToList())
            .AddInMemoryApiResources(InMemoryConfig.GetApiResources())
            .AddInMemoryClients(InMemoryConfig.GetClients());


            builder.AddDeveloperSigningCredential();

            if (Environment.IsDevelopment())
            {
                builder.AddDeveloperSigningCredential();
            }
            else
            {
                throw new Exception("need to configure key material");
            }

            services.AddAuthentication();//配置認證服務

        }

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseIdentityServer();//啓動 IdentityServer
            app.UseMvcWithDefaultRoute();//啓動 MVC
        }
    }

而後運行一下，在 Postman 中，嘗試經過上邊的用戶名密碼來獲取 Token ：

是否是很熟悉，若是你用過 NetCore 的受權驗證的話，這些確定都能看懂。

這裏你必定很好奇，我是怎麼知道要使用這個地址 localhost:5002/connect/token 來獲取Token的? ，一共還有多少個接口地址呢，要是有一個界面就行了。彆着急往下看。IdentityServer4 官方已經考慮到了。

三、關於QuickStart UI

官方爲咱們提供了一個快速啓動的UI界面，咱們只須要下載下來便可，這裏有兩個方法：

一、直接從這個地址下來下載，拷貝到項目中，一共三個文件夾；// https://github.com/IdentityServer/IdentityServer4.Quickstart.UI

二、在當前文件夾中執行命令，自動下載；
iex ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/IdentityServer/IdentityServer4.Quickstart.UI/master/getmaster.ps1'))

這樣咱們的項目界面已經成功的獲取到了，除此以外，記得要配置中間件來使用靜態文件：

app.UseStaticFiles();

四、運行展現

配置好後，F5運行，就能夠看到了界面，並且也看到了咱們上邊說到的 token 獲取的接口地址 localhost:5002/connect/token：

（可能這個 Json 格式和你的不同，由於我安裝了chrome 的擴展插件了——JSONView）

五、配置 EFCore 鏈接到數據庫

由於篇幅的問題，這個下次再詳細說明，不過個人 GitHub 上已經寫好了，有須要的能夠看看。

六、關於證書問題

這裏信息暫時沒有用處，只是先做爲一個備註記錄，待之後補充完善：

參考地址：https://www.cnblogs.com/guolianyu/p/9872661.html

一、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。