微服务认证受权概览

从单体架构向微服务架构转型的过程当中，认证方式也发生了改变。

而转变最大的方面即是有状态向无状态的转变。

在单体架构时代，咱们通常使用的是会话管理(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带给后端的微服务，一切都是网关来决定用户是谁，后端微服务无条件接受，这种形式对网关的安全要求比较高。

"内部裸奔"改进方案