分布式系统认证

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

分布式系统认证需求分析

分布式系统认证的需求总结如下
[scode type="blue"]统一认证授权[/scode]

• 提供独立的认证服务，提供处理认证授权。无论是不同类型的用户、还是不同类型的客户端，均采用一致的认证、授权、绘画判断机制，实现统一认证授权服务。
• 要实现这种统一的认证方式必须可扩展、支持各种认证需求。例如用户名密码、短信验证码、二维码、人脸识别等各种认证方式，并可以灵活的切换。

[scode type="blue"]多样的认证场景[/scode]

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

[scode type="blue"]应用接入认证[/scode]

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

分布式认证方案

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

基于Session的认证方式：

这种方式依然是由服务端保存统一的用户信息。只是在分布式环境下，将Session信息同步到各个服务中，并对请求进行负载均衡。

这种方案下，通常有一下几种做法：

• Session复制。在多台应用服务器之间同步Session，并使Session保持一致，对外透明。
• Session黏贴。当用户访问集群中某台服务器后，强制指定后续所有请求均落到此服务器上。
• Session集中存储。将Session存入分布式缓存中，所有服务器应用实例都统一从分布式缓存中获取Session信息。

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

基于Token的认证方式

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

方案选项

• 在通常情况下，还是会选择更通用的基于token的方式，这样能保证整个系统更灵活的扩展性，并减轻服务端的压力。
• 在这种方案下，一般会独立出统一认证服务（UAA）和网关两个部分来一起完成认证授权服务。
• 其中，统一认证服务承载接入方认证、登入用户认证、授权以及令牌管理的职责，完成实际的用户认证、授权功能。
• 而API网关会作为整个分布式系统的唯一入口，API网关为接入方提供API结合。它本身还可能具有其他辅助职责，如身份验证、监控、负载均衡、缓存、协议转换等功能。API网关方式的核心要点是，所有的接入方和消费端都通过统一的网关接入微服务，在网关层处理所有与业务无关的功能。正题流程如下图：
  

OAuth2.0

概念

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

OAuth2.0流程示例

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

OAuth2.0协议

Spring Security OAuth2.0

环境介绍

• OAuth是一个开放的授权标准，而Spring Security OAuth2是对OAuth2协议的一种实现框架。
• OAuth2的服务提供方包含两个服务，即授权服务（Authorization Server，也叫做认证服务）和资源服务（Resource Server），使用Spring Security OAuth2的时候，可以选择在同一个应用中来实现这两个服务，也可以拆分成多个应用来实现同一组授权服务。

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

  • AuthorizationEndpoint服务于认证请求。默认URL：/oauth/authorize
  • TokenEndpoint服务于访问令牌的请求。默认URL：/oauth/token
  • OAuth2AuthenticationProcessingFilter用来对请求给出的身份令牌进行解析健全。

UAA核心三个配置

• ClientDetailServiceConfigurer：用来配置客户端详情服务（ClientDetailsService），客户端详情信息在这里进行初始化，你能够把客户端详情信息写死在这里或者是通过数据库来存储调取详情信息。
• AuthorizationServerEndpointsConfigurer：用来配置令牌（token）的访问端点和令牌服务（tokenservices）
• AuthorizationServerSecurityConfigurer：用来配置令牌端点的安全约束

测试

客户端模式 client_credentials:

• 这种模式是最方便但是也是最不安全的模式，代表了授权服务器对客户端的完全互信。因此，这种模式一般可以用在授权服务器对客户端完全信任的场景，例如内部系统或者协议合作方系统对接。

密码模式

简化模式 implicit

• 这种方案下，一般redirect_uri会配置成客户端自己的一个响应地址。这个响应地址接收到授权服务器推送过来的访问令牌后，就可以将访问令牌在本地进行保存，然后在需要调用资源服务时，再拿出来通过资源服务的认证。

授权码模式 authorization_code