官网：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机构注册了，给你发个密匙，生成一个公共证书。也是靠个证书，和私匙完成加密的。我浏览器请求网址时，首次访问，会提示安装证书，安装后，访问你的网站，其内容就加密了，我服务器的私匙就可以解密这些信息，也只能是这个密匙能解密。