之前整理的微服务认证文档，分享一下

微服务认证有四种解决方案，分别是：单点登录SSO方案、分布式会话(Session)方案、客户端令牌(Token)方案，客户端和API网关结合；

• 单点登录方案：是最常见的解决方案，但是每个与用户交互的服务，都需要通过认证服务器通信，会产生大量的重复认证，和网络碎片流量。
• 分布式会话方案 ：将用户信息session 共享存储；当用户访问微服务时，直接从共享存储中获取。该解决方案在高可用和扩展方面很好，但是会话信息保存到共享存储中，要保证数据安全这块，实现复杂度比较高。
• 客户端网络令牌方案:令牌有客户端生成，并由认证服务器签名，在令牌中包含足够的信息，客户端在请求时会将令牌附件在请求上，从而为为各个微服务提供用户身份认证。但是如何及时的注销用户认证则是一个大问题。
• 客户端令牌和API网关结合 ：通过微服务架构中实施API网关，将原始的客户端令牌转化为内部的令牌，一方面可以有效的隐藏服务，另一方面通过API网关的通一入口可以实现令牌的注销处理。
• 综上所述，采用客户端令牌和API网关，解决了会话信息的安全和及时注销用户认证问题。

基于令牌(token)包含几层含义：

• 令牌是认证用户信息的集合。
• 令牌包含了足够的信息，验证令牌就可以完成用户的身份的验证。
• 服务器会通过HTTP头部中的Authorization获取令牌信息并进行检查，并不需要在服务端存储任何信息。
• 通过服务端验证令牌检查机制，可以应用在浏览器，和其他第三方应用程序上。
• 支持夸程序的调用。Cookie是不支持跨域访问，而token不存在这个问题。

1.Token认证有两种方式：OAuth2.0，JWT

OAuth2.0 授权流程
1)用户打开客户端后，客户端要求用户给预授权
2)用户同意给予客户端授权
3)客户端使用上一步的授权，向认证服务器申请令牌
4)认证服务器对客户端进行认证，确定无误后同意发放令牌
5)客户端使用令牌，向资源服务服务器申请资源
6)资源服务器确认无误后，同意向客户端开发资源

2. oAuth2.0授权方式

客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。oAuth 2.0 定义了四种授权方式。

• implicit：简化模式，不推荐使用
• authorization code：授权码模式
• resource owner password credentials：密码模式
• client credentials：客户端模式

2.1授权码模式：

1.用户访问客户端(应用界面)；
2.客户端将用户引导到授权服务器上
3.用户是否同意客户端授权；
4.如果同意授权，授权服务器将重定到客户端事先指定的地址，同时附加上授权码（token）
5.客户端收到授权码后，同时附加上要访问的页面，经客户端后台服务向授权服务器申请令牌；
6.授权服务验证授权码后，向客户端发送访问令牌(Access Token)和更新令牌(Refresh Token)并重新制定上步指定的地址；

2.2简化模式:

指不通过客户端的后台服务器来获取访问令牌，客户端一般指的是浏览器，客户端通过脚本语言(一般是javascript)来完成授权服务器申请服务器的操作；

简化模式详细介绍

简化模式适应于纯静态页面；所谓的纯静态界面应用，也就是应用没有在服务器代码执行的权限，(通常把代码托管在别人服务器上)，只有js代码的控制权限。
这种场景下，应用没有持久化的能力。因此按照oAuth2.0的规定，这种应用拿不到Refresh Token的。其授权流程入下图 。

2.3密码模式：

密码模式是指客户端通过用户提供的用户名和密码信息，直接通过授权信息服务器来获取授权。这种模式下，用户把自己用户名和密码提供给客户端，但是客户端不保存这些信息。
该模式使用，客户端高度信任的情况下。

该模式授权流程：
1.用户向客户提供相应的用户名和密码
2.客户端依据用户提供的用户名和密码，向授权服务器请求令牌
3.授权服务确认后，返回 令牌给客户端

密码模式详细介绍

密码模式中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向“服务提供商”索要授权(即：向授权服务器索要服务请求令牌)。在这种模式下，用户必须把用户名和密码给客户端，但是客户端不存储密码。这通常在用户端对客户端高度信任的情况下，比如客户端是操作系统的一部分。

一个典型的例子，同一个企业的不同产品要使用本企业的oAuth2.0体系。有些情况下产品希望能够定制化，授权界面。由于同一个企业，不需要授权通过授权界面来，询问用户授权意向，而只需要认证用户身份即可。这个时候产品研发定制授权界面，用户输入用户名和密码，并直接传递给授权进行授权即可。

2.4客户端模式：

指客户端以自己的名义而不是用户的名义，向授权服务器进行认证；
客户端模式详细介绍
如果信任关系再进一步，或者调用者是一个后端的模块，没有用户界面的时候，可以使用客户端模式。鉴权服务器直接对客户端进行身份验证，验证通过后，返回 token。

2.5结论:选择密码模式

由于，简化模式整体过程，整个过程在前端界面实现，这里不建议使用，authorization code，虽然是最安全的，最严密的，但是网络交互比较多，由于cem项目是内网实现，相应的API开发的接口不会放在外网，因此建议在密码模式和客户端模式中，二者选择其中一个，建议选择，密码模式;
由于cem产品基本上部署打内网环境，建议选择密码模式，鉴权服务器直接对客户端用户输入的，用户名和密码，进行身份验证，换取token。

总结 依据产品实际情况出发，选择适合当前场景的 认证方式；

3.依据用户名和密码，获取token验证，访问资源服务器流程

后续补充

4 .名词解释

名词解释

• 第三方应用程序（Third-party application）： 又称之为客户端（client），比如上节中提到的设备（PC、Android、iPhone、TV、Watch），我们会在这些设备中安装我们自己研发的 APP。又比如我们的产品想要使用 QQ、微信等第三方登录。对我们的产品来说，QQ、微信登录是第三方登录系统。我们又需要第三方登录系统的资源（头像、昵称等）。对于 QQ、微信等系统我们又是第三方应用程序。
• HTTP 服务提供商（HTTP service）： 我们的云笔记产品以及 QQ、微信等都可以称之为“服务提供商”。
• 资源所有者（Resource Owner）： 又称之为用户（user）。
• 用户代理（User Agent）： 比如浏览器，代替用户去访问这些资源。
• 认证服务器（Authorization server）： 即服务提供商专门用来处理认证的服务器，简单点说就是登录功能（验证用户的账号密码是否正确以及分配相应的权限）
• 资源服务器（Resource server）： 即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。简单点说就是资源的访问入口，比如上节中提到的“云笔记服务”和“云相册服务”都可以称之为资源服务器。