这篇文章和之前那篇分布式认证系统大同小异，本篇内容是分享的成稿

分布式系统认证

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

分布式系统认证需求分析

分布式系统认证的需求总结如下

统一认证授权

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

多样的认证场景

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

应用接入认证

• 应提供扩展和开放的能力，提供安全的系统对接机制，并可开放部分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版本已得到广泛的应用。

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用来对请求给出的身份令牌进行解析健全。

问题： 有SpringSecurity了为什么还要SpringSecurityOAuth2.0，同样是认证与授权，SpringSecurity不能实现OAuth2.0协议吗

OAuth2.0流程示例

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

OAuth2.0官方流程图

UAA核心三个配置

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

测试

客户端模式 client_credentials:

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

密码模式

• 这种模式用户会把用户名和密码直接泄露给客户端，代表了资源拥有者和授权服务器对客户端的绝对互信，相信客户端不会做坏事。一般适用于内部开发的客户端的场景。

简化模式 implicit

• 这种方案下，一般redirect_uri会配置成客户端自己的一个响应地址。这个响应地址接收到授权服务器推送过来的访问令牌后，就可以将访问令牌在本地进行保存，然后在需要调用资源服务时，再拿出来通过资源服务的认证。
• （这种模式下，access_token并不是以get请求参数的形式推送的，而是以#fragment方式返回的）
• 这种模式下，oauth三方的数据已经进行了隔离。这种模式下一般用于没有服务端的第三方单页面应用，这样可以在js里直接响应access_token

授权码模式 authorization_code

• 返回code

名词

OAuth 2.0

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

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

Token

令牌，客户端访问服务资源的凭证

JWT

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

SpringSecurity

Spring Security 是一个功能强大且高度可定制的身份验证和访问控制框架。它是保护基于 Spring 的应用程序的事实上的标准。

Spring Security 是一个专注于为 Java 应用程序提供身份验证和授权的框架。与所有 Spring 项目一样，Spring Security 的真正强大之处在于它可以轻松扩展以满足自定义要求。特征：

• 对身份验证和授权的全面且可扩展的支持
• 防止会话固定、点击劫持、跨站点请求伪造等攻击
• Servlet API 集成
• 与 Spring Web MVC 的可选集成
• 多得多…

SpringSecurityOAuth2

OAuth是一个开放的授权标准，而Spring Security OAuth2是对OAuth2协议的一种实现框架。

RBAC

RBAC 是基于角色的访问控制（Role-Based Access Control ），是一个权限设计模型，在 RBAC 中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。这样管理都是层级相互依赖的，权限赋予给角色，而把角色又赋予用户，这样的权限设计很清楚，管理起来很方便。

设计数据库表的设计，Security中认证流程的设计。

视频讲解