授权 鉴权中心微服务
1 什么是JWT
1.2 JWT 的基本概念

1.3 JSON Web Token jwt 是一个开放标准 它定义了一种紧凑的、自包含的方式 用于作为JSON 对象在各方之间安全地传输信息

1.4.那些场景下可以考虑使用JWT ？

​ 1.用户授权 信息交换

1.5 JWT的结构及其含义

​ 1.JWT 由三个部分组成 Header、Payload Signature 且用圆点连接

​ 2.Header 由两部分（Token类型 加密算法名称）组成,并使用Base64 编码

​ 3.Payload kv形式的数据 即你想传递的数据 （授权的话就是token 信息）

​ 4.Signature 为了得到签名部分 你必须有编码过的Header 编码过的payload 一个秘钥 签名算法是Header 中指定的那个 然对它们签名即可

我以前的公司使用的是JWT+SpringSecurity 做的鉴权和权限中心 现在我最近公司的微服务项目采用的SA—Token 所以在该Demo 当中直接采取Sa-Token 方式 去授权和鉴权的服务

2 授权和鉴权服务设计 分为好几种方案
2.1 、全局鉴权中心

有些微服务项目弄了个全局的鉴权中心，所有微服务接收HTTP调用之后，先去全局鉴权中心验证用户的身份和权限，然后再允许用户调用微服务。

这种缺点 我个人认为 发送了多次http请求 其二 每个服务都与鉴权服务进行耦合 耦合度有点深，

二、BFF鉴权
BFF全称是Backends For Frontends，直译过来就是“服务于前端的后端”。 简而言之，BFF就是设计后端微服务API接口时，考虑到不同设备的需求，为不同的设备提供不同的API接口。

客户端不是直接访问服务器的公共接口，而是调用BFF层提供的接口，BFF层再调用基础的服务，不同的客户端拥有不同的BFF层，它们定制客户端需要的API接口。

有了BFF层之后，客户端只需要发起一次HTTP请求，BFF层就能调用不同的服务，然后把汇总后的数据返回给客户端，这样就减少了外网的HTTP请求，响应速度也就更快。

跨横切面(Cross-Cutting Concerns)的功能，需要协调更新框架升级发版(路由、认证、限流、安全)，因此全部上沉，引入了 API Gateway，把业务集成度高的 BFF 层和通用功能服务层 API Gateway 进行了分层处理。

在新的架构中，网关承担了重要的角色，它是解耦拆分和后续升级迁移的利器。

在网关的配合下，单块 BFF 实现了解耦拆分，各业务线团队可以独立开发和交付各自的微服务，研发效率大大提升。

BFF的划分：

重要性
垂直业务，闭环
流量大小
另外，把跨横切面逻辑从 BFF 剥离到网关上去以后，BFF 的开发人员可以更加专注业务逻辑交付，实现了架构上的关注分离(Separation of Concerns)。

我们业务流量实际为：
移动端 -> API Gateway -> BFF -> Mircoservice

在 FE Web业务中，BFF 可以是 nodejs 来做服务端渲染(SSR，Server-Side Rendering)，注意这里忽略了上游的 CDN、4/7层负载均衡(ELB)。

总结

基于服务器的身份认证
最为传统的做法 客服端存储cookie 一般是session id 服务器存储Session
Session 是每次用户认证通过以后 服务器需要创建一条记录保存用户信息 通常是在内存中 随着认证通过的用户越来越多 服务器的开销越来越大
在不同域名之前切换时 请求可能会被禁止 跨域问题
基于token方式身份认证
JWT 与Session 的差异相同点是 它们都是存储用户信息 然而Session 存在服务器端 而JWT 是在客户端
jwt 方式将用户状态分散到了客户端中 可以明显减轻服务端的内存压力
在不同域名之前切换时 请求可能会被禁止 跨域问题
基于token 与服务器身份认证
解析方式 jwt 使用算法直接解析得到用户信息 Session 需要额外的数据映射 实现匹配
jwt 只有过期时间的限制 session 保存在服务器 可控性强大
跨平台 jwt 就是一个string 可以任意传送 Session 跨平台需要一个统一解析方式
时效性 jwt一旦生成 独立存在 很难做特殊控制 Session 时效性可以由服务端控制
代码如下