官網：https://identityserver4.readthedocs.io/en/latest/quickstarts/2_interactive_aspnetcore.html
官網例子：https://github.com/IdentityServer/IdentityServer4/tree/main/samples/Quickstarts
is4，我的理解是，獨立的用戶認證授權框架，爲多個不同系統，提供一個公共的認證授權服務，a系統，b系統，c系統都 在 is4服務器上“註冊得有策略” ，其中密匙什麼的，只有a、b、c系統與is4服務器是知道的，用戶訪問各人的系統時， 需要先到is4服務器去獲得認證，獲得了令牌後，帶入頭部，bearer認證，然後再去訪問a b c的後端api。因爲 a b c分別與is4之間是信任的，當 a的前端帶帶着頭部認證進入a的後端api後，a系統後端就會驗證這個頭部是否是is4給的token，如果是僞造的就不行。當然應該不用每次都先要訪問is4服務，肯定是可以設置token過期時間的，過期後，再去請求is4服務。其關鍵就在於，a b c 在 is4 上註冊的認證策略，也不叫什麼註冊，就是互相通個氣，幾個關鍵文字只有a b c與is4服務器知道就行了，背後的加密算法，最後算出來的token，只有得到is4的一些關鍵信息之後才能解析成功。官網的例子裏，沒有在api端寫密匙，而是給的一個is4服務的url地址，應該是api在驗證token時，還去請求了這個url的；按我的感覺，直接寫上is4上給出的密匙，驗證token的時候，不再去訪問那個url地址應該是可行的吧，就想JWT認證類似。
或者這個url地址是映射到某個在a服務器的文件的，如果文件存在，就不去訪問is4服務器了，然後，token的認證就靠這個文件，依稀記得官網上是提了一下這個文件的。
來個官網的圖，就更清楚了。
a b c 系統之間還能通過is4實現互相登陸，只需要其中一個系統中有註冊的用戶，比如a系統，在is4上獲得了認證後，就可以在 b c系統上登陸了，b c 系統缺少的用戶的信息可以通過token傳送，實現的時候，就把is4上的用戶身份信息保存在各自的系統。設計系統的時候，感覺可以把 a b c 系統 公用的用戶信息設計到is4的服務器上。
jwt認證和is4 .net core 也有一套接口，jwt和is4分別實現了這樣的接口，所以看.net core的代碼 這兩個東西代碼都相似。
最後，我聯想到 https協議的加密，網站管理人員在ca機構註冊了，給你發個密匙，生成一個公共證書。也是靠個證書，和私匙完成加密的。我瀏覽器請求網址時，首次訪問，會提示安裝證書，安裝後，訪問你的網站，其內容就加密了，我服務器的私匙就可以解密這些信息，也只能是這個密匙能解密。