我觉得原作者写得已经很好了，所以可以直接看链接。
https://www.cnblogs.com/uoyo/p/13209685.html
我们围绕着问题来看看身份验证原理的发展史。
初代验证方案
在web中，最基础的验证方案就是每次访问web时，都带上用户名密码这些标识验证信息，比如
http://ourBusinessWebServer/Get?user='Me'&pass='12345678'web服务器每次对于请求都会检查user和pass字段信息，检查验证通过后，才会后续处理。
这个方案可以解决验证登陆问题，但是... 信息都在url中，人眼都可以看到，非常不安全。
1改
既然把数据放在url里面不安全，那就放到Http 的request header中，例如 Authorization属性。
Authorization:Me:12345678如果觉得这样还是明文显示，那么可以简单地用base64编码加密一下。
2改
如果验证信息特别多，实际上就可以增加一个cookie，web端维护改cookie，并将改cookie和登陆验证信息进行一一对应，后续客户端请求只需要带上这个cookie，即可认为是合法用户，避免了每次对验证信息进行验证。
至此，单体程序下，验证足够使用了。如果需要安全地通信，可以使用https。
身份信息自包含的验证方案
初代验证方案，在单体验证环境下，基本就可以解决很多问题了。但是在现在2022年的微服务架构下，验证服务在一台web服务器上，很多个业务线的web服务在其他不同的服务器上，这些业务都会使用相同的验证服务。
假如, A服务器为登陆验证服务，B服务器为业务服务。
现在的验证模式就会如下：
- 我们在浏览器中输入B的Url，由于没有登陆验证过，请求中没有对应的cookie，B服务会检查发现没有Cookie，此时会重定向到登陆验证服务的Url给客户端，并且在这个Url中会有后续回调Url，这个回调Url为B的登陆验证Url。
- 浏览器收到重定向登陆A服务的Url，一般是一个类似QQ第三方登陆的界面，点击确定提交给A服务，A服务对提交的登陆用户信息进行验证，若验证通过，会返回一个包含用户各种身份信息的Token，改Token通常是加密和签名的数据，返回的Url即为上一部中的回调Url，加上这个Token。
- 浏览器收到返回的信息，发现是重定向请求，于是将请求重定向到B服务的登陆验证Url。
- B服务收到请求，检查是否有Token，根据设置好的解析Token的对应公钥进行解析出身份信息，并将其存入自己的内存中，同时生成一个Cookie与这些信息进行对应，该Cookie传送给浏览器。
- 浏览器收到B服务的Cookie信息，后续访问B服务的资源，只需要请求中带有Cookie即可。
实际上，这种验证方案，和初始验证方案解决的问题是一样的，只是解决过程中，由于调用第三方或者远程验证服务，引入了更多环节而已。JWT Bearer基本就是如上方式。
