在微服务架构中，由于不同的业务会拆分成不同的微服务，传统的单体项目一般是通过过滤器进行拦截校验，而微服务显然不可能分发到各个服务进行用户认证，这就需要由一个统一的地方来管理所有服务的认证信息，实现只登录一次，即可在各个服务的授权范围内进行操作；
  实现认证中心的方式有很多，这里只记录了使用OAuth2协议标准实现认证的方法；

OAuth2介绍

  OAuth是一个关于授权（authorization）的开放网络标准，在全世界得到广泛应用，目前的版本是2.0版。
OAuth 2.0 也是目前最流行的授权机制，用来授权第三方应用，获取用户数据。
详细的可参考这篇文章：http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

OAuth 2 目前有四种授权模式:

• 授权码模式（authorization code)
• 简化模式（implicit)
• 密码模式（resource owner password credentials）
• 客户端模式（client credentials）

授权码模式

使用场景
  比如用微信登录、用 QQ 登录、用微博登录、用 Google 账号登录、用 github 授权登录等等，这些都是典型的 OAuth2 使用场景。假设我们做了一个自己的服务平台，如果不使用 OAuth2 登录方式，那么我们需要用户先完成注册，然后用注册号的账号密码或者用手机验证码登录。而使用了 OAuth2 之后，相信很多人使用过、甚至开发过公众号网页服务、小程序，当我们进入网页、小程序界面，第一次使用就无需注册，直接使用微信授权登录即可，大大提高了使用效率。因为每个人都有微信号，有了微信就可以马上使用第三方服务，这体验不要太好了。而对于我们的服务来说，我们也不需要存储用户的密码，只要存储认证平台返回的唯一ID 和用户信息即可。
  授权码模式（authorization code）是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。
处理逻辑如下图所示：

1. 用户访问客户端，后者将前者导向认证服务器。
2. 用户选择是否给予客户端授权。
3. 假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。
4. 客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。
5. 认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

简化模式

  简化模式（implicit grant type）不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。

密码模式

  密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。
  在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。
  一般情况下，自己内部的服务可以使用这种模式来认证；用户信息本来就在自己系统内管理的，就可以使用这种方式；

1. 用户向客户端提供用户名和密码。
2. 客户端将用户名和密码发给认证服务器，向后者请求令牌。
3. 认证服务器确认无误后，向客户端提供访问令牌。

spring cloud有一套spring-cloud-starter-oauth2组件 ，其实是 Spring Cloud 按照 OAuth2 的标准并结合 spring-security 封装好的一个具体实现。他的密码模式就如下面所示：
这种方式就是用来管理自己业务系统内用户认证的逻辑；采用这种方式的微服架构图如下所示：
详细的spring-cloud-starter-oauth2集成实战，可以参考这边文章https://blog.csdn.net/AkiraNicky/article/details/124167607

客户端模式

  客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务

1. 客户端向认证服务器进行身份认证，并要求一个访问令牌
2. 认证服务器确认无误后，向客户端提供访问令牌

其实在我们的企业内部，就有这种模式的使用场景；举个例子，企业内有一套业务系统A是微服务架构开发的，另一个应用系统B不属于这个微服服务体系内的，B是一个单体应用；现在应用B要调用业务系统A的某个resultful接口，业务系统A通常就是给应用A提供一个客户端id和客户端秘钥等数据来进行认证，获取token信息再进行接口调用；
如图：