04.分布式系统认证与授权

分布式系统认证与授权

分布式认证与授权的需求

分布式系统的每个服务都会有认证，授权的需求，如果每个服务都实现一套认证授权逻辑会非常冗余，考虑分布式系统共享性的特点，需要由独立的认证服务处理系统认证授权的请求；考虑分布式系统开放性的的特点，不仅对系统内部服务提供认证，对第三方系统也要提供认证。分布式认证的需求总结如下：
统一认证授权

1. 提供独立的认证服务，统一处理认证授权。
2. 无论是不同类型的用户，还是不同种类的客户端(web端，H5、APP)，均采用一致的认证、权限、会话机制，实现统一认证授权。
3. 要实现统一则认证方式必须可扩展，支持各种认证需求，比如：用户名密码认证、短信验证码、二维码、人脸识别等认证方式，并可以非常灵活的切换。
   应用接入认证
   应提供扩展和开放能力，提供安全的系统对接机制，并可开放部分API给接入第三方使用，一方应用（内部 系统服务）和三方应用（第三方应用）均采用统一机制接入。

分布式认证方案

1.基于session的认证方式

在分布式的环境下，基于session的认证会出现一个问题，每个应用服务都需要在session中存储用户身份信息，通过负载均衡将本地的请求分配到另一个应用服务需要将session信息带过去，否则会重新认证。
解决方案有三个：
Session复制：多台应用服务器之间同步session，使session保持一致，对外透明。

Session黏贴：当用户访问集群中某台服务器后，强制指定后续所有请求均落到此机器上。

Session集中存储：将Session存入分布式缓存中，所有服务器应用实例统一从分布式缓存中存取Session。

总体来讲，基于session认证的认证方式，可以更好的在服务端对会话进行控制，且安全性较高。但是，session机制方式基于cookie，在复杂多样的移动客户端上不能有效的使用，并且无法跨域，另外随着系统的扩展需提高session的复制、黏贴及存储的容错性。

2.基于token的认证方式

基于token的认证方式，服务端不用存储认证数据，易维护扩展性强， 客户端可以把token 存在任意地方，并且可以实现web和app统一认证机制。其缺点也很明显，token由于自包含信息，因此一般数据量较大，而且每次请求都需要传递，因此比较占带宽。另外，token的签名验签操作也会给cpu带来额外的处理负担。

3.为什么选择基于token的认证方式

1. 适合统一认证的机制，客户端、一方应用、三方应用都遵循一致的认证机制。
2. token认证方式对第三方应用接入更适合，因为它更开放，可使用当前有流行的开放协议Oauth2.0、JWT等。
3. 一般情况服务端无需存储会话信息，减轻了服务端的压力

分布式系统认证架构图

OAuth2

OAuth2介绍

OAuth（开放授权）是一个开放标准，允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方应用或分享他们数据的所有内容。OAuth2.0是OAuth协议的延续版本，但不向后兼容OAuth 1.0即完全废止了OAuth1.0。很多大公司如Google，Yahoo，Microsoft等都提供了OAUTH认证服务，这些都足以说明OAUTH标准逐渐成为开放资源授权的标准。

Oauth协议目前发展到2.0版本，1.0版本过于复杂，2.0版本已得到广泛应用。

参考：https://baike.baidu.com/item/oAuth/7153134?fr=aladdin

Oauth协议：https://tools.ietf.org/html/rfc6749

OAuth2例子

用户使用美团APP点餐再使用微信付款这用的就是OAuth2，第三方应用就是美团，微信就是存储用户信息的系统。

也就是用户授权美团访问微信上用户的信息。

OAuth2流程图

OAuth2中包含的角色

1.客户端(美团APP)

本身不存储资源，需要通过资源拥有者(用户)的授权去请求资源服务器的资源，比如：Android客户端、Web客户端（浏览器端）、微信客户端等。

2.资源拥有者(用户)

通常为用户，也可以是应用程序，即该资源的拥有者。

3.认证授权服务器(微信端)

用于服务提供商对资源拥有的身份进行认证、对访问资源进行授权，认证成功后会给客户端发放令牌（access_token），作为客户端访问资源服务器的凭据。本例为微信的认证服务器。

4.资源服务器(微信端)

存储资源的服务器，本例子为微信存储的用户信息。

注意

服务提供商能允许随便一个客户端就接入到它的授权服务器吗？答案是否定的，服务提供商会给准入的接入方一个身份，用于接入时的凭据：

client_id：客户端标识 client_secret：客户端秘钥

因此，准确来说，授权服务器对两种OAuth2.0中的两个角色进行认证授权，分别是资源拥有者、客户端。

Spring Cloud Security OAuth2

介绍

Spring-Security-OAuth2是对OAuth2的一种实现，并且跟我们之前学习的Spring Security相辅相成，与Spring Cloud体系的集成也非常便利。

角色

1.认证授权服务 (Authorization Server)

应包含对接入端以及登入用户的合法性进行验证并颁发token等功能，对令牌的请求端点由 Spring MVC 控制器进行实现，下面是配置一个认证服务必须要实现的endpoints：

• AuthorizationEndpoint 服务于认证请求。默认 URL： /oauth/authorize
• TokenEndpoint 服务于访问令牌的请求。默认 URL： /oauth/token

2.资源服务 (Resource Server)

• 包含对资源的保护功能，对非法请求进行拦截，对请求中token进行解析鉴权等。
• OAuth2AuthenticationProcessingFilter用来对请求给出的身份令牌解析鉴权。

OAuth2的四大模式

1.授权码模式

2.简化模式

3.密码模式

4.客户端模式