大话微服务：Spring Cloud gateway+OAuth2 精僻总结

一、什么情况下没有必要用OAuth2（当然要用也不反对）？

• 只有一套应用系统，用户名和密码，或者手机号+短信验码，CA证书等用户身份即可以满足时，没有必要用OAuth2.
• 一个公司有多套系统，但数量有限并且可控，只是不同的系统有不同的用户系统，只是想打通用户，即sso单点登录的需求，可以没有必要用，当然用oauth2做同一家公司研发的各个应用系统的单点登录也是一个不错的方案。

二、什么情况需要OAuth2?

• 互联网上的开放的系统之间如何授权：A.调用微信，钉钉，qq等来联合登录；B.调用微信等开放平台的api。
• 微服务架构的安全性：A.单页浏览器调用微服务api的安全性.  B.手机原生app调用微服务api C.服务端应用访问 D.微服务之间的api的调用安全性。
• 企业内部各个应用系统之间的认证与授权，即单点登录sso的方案。

   总结：不同公司开发的应用系统，如何有一个互信机制，而不需要把用户名和密码给对方或者实现数据的共享。

三、OAuth2的术语理解？

oauth2的设计思想：客户应用（即客户端）与服务提供商（资源方）之间不能直接访问，而是加了一个授权层（认证和鉴权），最终根据token的特性（令牌有权限范围和有效期），向客户端开放用户的数据。

oauth2四个角色理解：

（1）资源拥有者：资源的拥有人，想要分享某些资源给第三方应用。

（2）客户应用（资源请求方）

      通常是各个应用系统（一个应用系统可以有多个微服务组成），对于同一家的企业的应用系统，可以分配同一个client_id和client_secret, 例如微信api开放平台的调用时，他给不同的商户（或企业）提供了注册，注册后生成了这个商户（或企业）的appid和appPassword，即client_id和client_secret。所以在微服务后台管理系统中，应用客户应用的配置功能，即创建不同客户的client_id和client_secret,访问资源，权限范围（读/写）等，即设置oauth_client_details表的内容。

   oauth2有客户凭证（client_id和client_secret）和token之分，根据客户凭证生成token，客户凭证相当于业主的身份证，token相当于门禁卡，有了身份证才能生成门禁卡（门禁卡我是可以设定时间限制的，用一次，还是多长时间失效）。

（3）授权服务器（oauth2认证服务）：

      根据客户应用的身份（即client_id和client_secret）生成access token。通常假设A公司的应用要访问B公司的应用提供的api，那么这个授权服务一定是B公司提供的，例如：我们调用微信的api，一定要通过腾讯的oauth2 授权服务器认证。

（4）资源服务器（应叫oauth2资源服务更合适一些）：

     这个资源服务器可以理解为两种类型：一种OAuth2（认证与鉴权）也是资源服务器，我们可以叫它OAuth2资源服务器，另一种普通应用的也是一个资源服务器，例如：订单系统，支付系统），它通常是资源的存放地点或者资源的访问入口。按道理来说，你要访问我的订单服务这个应用中的api，我需要把我的订单服务应用开发时就做成一个资源服务（里面加入了oauth2的token认证机制，没有合法的token，你不能访问我），但在微服务架构下，不可能这样开发，微服务架构一般按以下思路设计：

      在微服务架构下：

           一个企业，开发一个独立的oauth2认证与鉴权的微服务应用（即一个spring boot), 负责身份认证后生成token，同时验证token合法性。所有各个应用（即微服务）的访问统一经过gateway(网关）转发，这个网关自动把每个访问转发到oauth2服务器，由oauth2做token的生成或者合法检查，token合法后才能访问资源。所以本身业务功能的资源服务器一般不会再包装oauth2的token相关内容，而是统一由专门的oauth2认证与鉴权应用来做。

        oauth2服务器（即应用程序spring boot),可以把认证服务和资源服务做成一个微服务（即一个spring boot),也可以分开认证是一个微服务（即一个spring boot, 生成token),资源服务是一个微服务（即一个spring boot,验证token)。所以这个资源服务，指oauth2本身也是一个资源服务，应叫oauth2资源服务器，区别于业务上的资源服务器。

四、OAuth2应用场景类型？

  根据业务的不同需求，oauth2提供了四种授权方案(即token的生成方式），即客户端必须得到用户的授权，才能获得令牌(access token)：

（1）授权码模式生成token:

        这是流程最严密的授权模式，客户端应用服务器与服务提供商的认证服务器有一个互动过程，例如：我们的软件需要调用qq或者微信的登录，必须得到这个微信或者qq主人的确认才能登录（主人的确认就是由腾讯认证服务器提供的功能）。

       常用在：我们的软件需要给第三方提供相应的api资源服务时，需要采用授权码模式生成token，这个模式有一个特点先生成授权码（客户的应用服务器与服务提供商的服务器交互生成授权码），再根据授权码生成token。

  (2)  简化模式生成token

       不需要授权码，即浏览器直接向服务提供商的认证服务器申请生成令牌，通常是软件没有后台，只有前端例如纯js开发的软件。

  (3) 密码模式生成token

       这种模式通过账号与密码生成token，一般客户端高度信任情况下，这个一般是oauth2服务器和客户端的各个应用均是同一家公司开发的，这个最常用的公司本身的各个应用系统之间的token生成。

  (4) 客户端模式生成token

       这种模式以客户端的模式而不是终端用户的名义申请生成token，例如: 同一家公司内部的各个应用系统，各个应用系统可以采用同样的客户信息进行生成token.

总结：不管哪一种模式，均要客户的凭证，即client_id和client_secret, 才能生成access token。

五、微服务架构中如何搭配用OAuth2?

    一个大的应用开发，我们会根据业务职责工分为多个独立的微服务，每个微服务提供一套各自的api。实际业务中，我们不会将所有子服务接口单独暴露出来，我们需要统一的入口为我们请求转发、负载均衡、认证与鉴权等操作。所以在spring cloue微服务架构中，我们经常把spring coud gateway包装成oauth2 的一个客户端应用(oauth2 client) ，达到与oauth2的集成。

     工作原理： 用户发出的任何一个访问请求，均通过gateway进行拦截，它接收到请求后，转向oauth2认证与鉴权服务，获得授权后才能访问相关的资源。