SpringSecurity最全实战讲解四-一一网

五、分布式系统认证方案

1、分布式系统认证需求分析

随着软件环境和需求的变化，软件的架构通常都会由单体结构演变成具有分布式架构的分布式系统。而分布式系统的每个服务都会有认证、授权的需求。如果每个服务都实现一套认证逻辑，就会非常冗余并且不现实。而针对分布式系统的特点，一般就会需要一套独立的第三方系统来提供统一的授权认证服务。分布式系统认证的需求总结如下：

1、统一认证授权

提供独立的认证服务，统一处理认证授权。无论是不同类型的用户、还是不同类型的客户端(Web、H5、App等)，均采用一致的认证、授权、会话判断机制，实现统一认证授权服务。

要实现这种统一则认证方式必须可扩展，支持各种认证需求。例如用户名密码、短信验证码、二维码、人脸识别等各种认证方式，并可以灵活的切换。

2、多样的认证场景

例如购物、支付需要有不同的安全级别，也就需要有对应的认证场景。

3、应用接入认证

应提供扩展和开放的能力，提供安全的系统对接机制，并可开放部分API给第三方使用。并且内部服务和外部第三方服务均采用统一的接入机制。

2、分布式认证方案

分布式环境下的认证方案主要有基于Session和基于Token两种方案。

1、基于Session的认证方式：

这种方式依然是由服务端保存统一的用户信息。只是在分布式环境下，将Session信息同步到各个服务中，并对请求进行均衡的负载。
在这里插入图片描述
这种方案下，通常有以下几种做法：

1、Session复制。在多台应用服务器之间同步session，并使session保持一致，对外透明。

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

3、Session集中存储。将Session存入分布式缓存中，所有服务器应用实例都统一从分布式缓存中获取Session信息。

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

2、基于Token的认证方式

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

3、方案选型

通常情况下，还是会选择更通用的基于token的方式，这样能保证整个系统更灵活的扩展性，并减轻服务端的压力。

在这种方案下，一般会独立出统一认证服务(UAA) 和网关两个部分来一起完成认证授权服务。

其中，统一认证服务承载接入方认证、登入用户认证、授权以及令牌管理的职责，完成实际的用户认证、授权功能。

而API网关会作为整个分布式系统的唯一入口，API网关为接入方提供API结合。它本身还可能具有其他辅助职责，如身份验证、监控、负载均衡、缓存、协议转换等功能。API网关方式的核心要点是，所有的接入方和消费端都通过统一的网关接入微服务，在网关层处理所有与业务无关的功能。正题流程如下图：
在这里插入图片描述

六、OAuth2.0

6.1 OAuth2.0介绍

6.1.1、什么是OAuth2.0?

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

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

参考：baike.baidu.com/item/oAuth/…

Oauth协议：tools.ietf.org/html/rfc674…

6.2.2、OAuth2.0流程示例

OAuth认证流程，简单理解，就是允许我们将之前实现的认证和授权的过程交由一个独立的第三方来进行担保。而OAuth协议就是用来定义如何让这个第三方的担保有效且双方可信。例如我们下面以用户访问百度登录后的资源为例：

2.1 用户希望登录百度，访问百度登录后的资源。而用户可以选择使用微信账号进行登录，实际是将授权认证的流程交由微信(独立第三方)来进行担保。
在这里插入图片描述

2.2 用户以扫描二维码的方式，在微信完成登录认证。
在这里插入图片描述

2.3 用户选择同意后，进入百度的流程。这时，百度会获取用户的微信身份信息，与百度自己的一个注册账号完成绑定。绑定完成了之后，就会用这个绑定后的账号完成自己的登录流程。
在这里插入图片描述

以上这个过程，实际上就是一个典型的OAuth2.0的认证流程。在这个登录认证的过程中，实际上是只有用户和百度之间有资源访问的关系，而微信就是作为一个独立的第三方，使用用户在微信里的身份信息，来对用户的身份进行了一次担保认证。认证完成后，百度就可以获取到用户的微信身份信息，进入自己的后续流程，与百度内部的一个用户信息完成绑定及登录。整个流程大致是这样：
在这里插入图片描述
我们来分析这整个过程，其中最重要的问题，显然是如何让用户、百度和微信这三方实现权限认证的共信。这其中涉及到非常多的细节问题，而OAuth2.0协议就是用来定义这个过程中，各方的行为标准。