在IdentityServer4中有两种令牌，一个是JWT和Reference Token，在IDS4中默认用的是JWT，那么这两者有什么区别呢？
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的交互流程图
此图为：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加密之前我们先来比较一下其他的加密算法
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，自定义即可。
B、在starup.cs中ConfigureServices方法中配置如下即可。
配置完后即可。我们启动IDS4项目即可生成加密的token。
将得到的token在jwt.io 网站来认证一下：把后缀为 crt 公钥、key私钥复制到验证中，发现认证ok。这样即可实现防篡改。
在实际环境中应该使用加密的token，而不应该使用临时令牌。以及尽量设置token的过期时间短，以及刷新token的机制，这样可以尽可能的保护token以及数据安全。
asp.net core 交流群：787464275 欢迎加群交流
如果您认为这篇文章还不错或者有所收获，您可以点击右下角的【推荐】按钮精神支持，因为这种支持是我继续写作，分享的最大动力！
微信公众号：欢迎关注 QQ技术交流群： 欢迎加群
