微服务认证授权概览 顶
从单体架构向微服务架构转型的过程中，认证方式也发生了改变。
而转变最大的方面便是有状态向无状态的转变。
在单体架构时代，我们一般使用的是会话管理(Session)，架构图如下所示
即多实例采用一个同一个Session Store(一般采用Redis来存储)来进行Session的管理，即共享Session,在第二代网关GateWay搭建流程 的SaveSession小节中有介绍共享Session的配置。对以上这种设置，我们称之为有状态。
而与之相对的就是无状态，指的是服务器端不去记录用户的登录状态，不再去维护用户的Session。在微服务时代，如果依然采用共享Session的策略，则把各个独立的微服务又捆绑在了Session Store中，如果Session Store挂了，则所有的微服务都无法运行，等于把鸡蛋放到了一个篮子中。而更主要的是如果Session Store需要做迁移，则所有的微服务地址都要调整，牵一发而动全身。再就是如果Session Store达到了瓶颈(容量瓶颈，性能瓶颈)，都得对其进行扩容。
微服务的无状态架构图如下所示
服务器端不会存储用户的登录状态，而是在用户登录的时候颁发一个token,之后用户的请求都需要带上token(可能放在head中，可能放在url参数中),服务器端拿到token后进行解密，校验token是否合法，有无过期，如果合法并没有过期，就认为用户为登录状态，否则为未登录状态。我们还可以在Token里面存储一些不太敏感的用户信息(比如用户名),这样服务器在解密完token以后就可以直接使用。但有时候token里不一定带有用户信息;而是利用token在某个地方查询，才能获得用户信息。比如在Spring OAuth2中可以做如下设置，其中8002为鉴权中心的端口。
security:
oauth2:
resource:
user-info-uri: http://local.register.com:8002/user-me
prefer-token-info: false然后通过OAuth2.0通过token获取受保护资源的解析 来拿取用户的详细信息。
有状态和无状态的优缺点
优缺点 | 有状态 | 无状态 |
|---|---|---|
优点 | 服务器端控制力强 | 去中心化，无存储，简单，任意扩容，缩容 |
缺点 | 存在中心点，鸡蛋在一个篮子里，迁移麻烦，服务器端存储数据，加大了服务器端压力 | 服务器端控制力弱 |
无状态登录的实现和变种
- 处处安全
处处安全一般是指单点登录，一次登录可以访问所有的其他的系统
我们打开淘宝APP，首页就会有天猫、聚划算等服务的链接，当你点击以后就直接跳过去了，并没有让你再登录一次
它的请求顺序如下图所示
一般这种方式采用OAuth 2.0来处理
- 外部无状态，内部有状态
该方式结合了Token和Session，一般用于旧单体系统和微服务过渡时使用
网关认证授权，内部裸奔
该形式的token认证解析都是由网关来处理的，解析后也可以携带User_ID，UserName带给后端的微服务，一切都是网关来决定用户是谁，后端微服务无条件接受，这种形式对网关的安全要求比较高。
"内部裸奔"改进方案
