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

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

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

二、什么情况需要OAuth2?

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

三、OAuth2的术语理解？

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

oauth2四个角色理解：

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

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

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

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

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

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

在微服务架构下：

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

四、OAuth2应用场景类型？

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

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

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

(2) 简化模式生成token

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

(3) 密码模式生成token

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

(4) 客户端模式生成token

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

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

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

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