持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第24天，点击查看活动详情
Authotization Server的appid和秘钥db加载
client传递appid和秘钥调Authotization Server获取accesstoken
client传递accesstoken调Resource Server接口（Resource Server底层通过过滤器检查accesstoken是否有效）
Resource Server中配置要保护的接口，配置对应的资源id
角色划分
jwt
应用场景
前端分离项目、（移动app、小程序、H5）
1、session 存放在服务器端---根据session id获取
2、token+redis
session最大的缺点集群无法共享。
token类似于session的session id
token依赖于reids，根据token获取真实的value值，获取到用户信息
jwt底层组成部分：
1、header （头部、描述payload加密方式）（base64编码）
{
Typ="jwt" ---类型为jwt
Alg:"HS256" --加密算法为hs256
}
2、payload装载的数据（base64编码）
携带存放的数据 用户名称、用户头像之类 注意铭感数据
{
userid:"123",
userName:"zhangsan"
}
3、验证签名，防止篡改payload中的数据（MD5加密，属于单向加密，需要在后面加盐）。
jwt底层加密、解密：
jwt和token最大的区别？
token需要依赖于redis查询数据信息的，数据比较安全
jwt不需要依赖于服务器端，数据信息直接存放在客服端（浏览器中）
\
jwt的优缺点？
优点：
-
无需再服务器存放用户的数据，减轻服务器端压力
-
轻量级、json风格比较简单
-
跨语言
缺点：
jwt一旦生成后期无法修改：
-
无法更新jwt有效期
-
无法销毁一个jwt
jwt 设置90天以后过期 提前60天过期（jwt无法提前过期）
- 支持跨域访问：cookie是无法跨域的，而token由于没有用到cookie(前提是将token放到请求头中)，所以跨域后不会存在信息丢失问题
- 无状态：token机制在服务端不需要存储session信息，因为token自身包含了所有登录用户的信息，所以可以减轻服务端压力
- 更适用CDN：可以通过内容分发网络请求服务端的所有资料
- 更适用于移动端：当客户端是非浏览器平台时，cookie是不被支持的，此时采用token认证方式会简单很多
- 无需考虑CSRF：由于不再依赖cookie，所以采用token认证方式不会发生CSRF，所以也就无需考虑CSRF的防御
