【分布式认证授权】OAuth2和SpringSecurity的区别与联系（Tok
- 分布式系统认证需求分析
统一认证授权
- 提供独立的认证服务，提供处理认证授权。无论是不同类型的用户，还是不同类型的客户端，均采用一致的认证、授权、绘画哦按段机制，实现统一认证授权服务。
- 要实现这种统一的认证方式必须可扩展、支持各种认证需求。例如用户名密码、短信验证码、二维码、人脸识别等各种认证方式，并可以灵活的切换。
多样的认证场景
- 例如购物、支付需要有不同的安全级别，也就需要有对应的认证场景。
应用接入认证
- 应提供扩展和开放的能力，提供安全的系统对接机制，并可开放部分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，等都提供了OAuth认证服务，这些都足以说明OAuth标准逐渐成为开放资源授权的标准。
Spring Security OAuth2.0
环境介绍
- OAuth是一个开放的授权标准，而Spring Security OAuth2.是对OAuth2协议的一种实现框架
- OAuth2的服务提供防包含两个服务，即授权服务（Authorizaton server,也叫认证服务）和资源服务（Resource server）,使用Spring Security OAuth2的时候，可以选择在同一个应用中来实现这两个服务，也可以拆分成多个应用来实现同一组授权服务。
- 授权服务（Authorizaton server）应包含对介入段以及登入用户的合法性进行验证并颁发token等功能，对令牌的请求断点由spring MVC控制器实现，下面是配置一个认证服务必须的endpoints:
- AuthorizationEEndpoint 服务于认证请求。默认URL：/oautn/authorize
- TokenEndpoint服务于访问令牌的请求。默认URL:/oauth/token
- OAuth2AuthenticationProcessingFilter 用来对请求给出的身份令牌进行解析健全。
问题：有Spring Security了为什么还要Spring Security OAuth2.0 ，同样是认证与授权，Spring Security不能实现OAuth2.0 协议吗？
OAuth2.0流程示例
- OAuth认证流程，简单理解，就是允许我们将之前实现的认证和授权的过程交由一个独立的第三方来进行担保。而OAuth协议就是用来顶故意如何让这个第三方的担保有效且双方可信。（以微信扫码登录百度为例）
UAA核心三个配置
- ClientDetailServiceConfigurer: 用来配置客户端详情（ClientDetailsService）,客户端详情信息在这里进行初始化，你能够把客户端详情信息写死在这里或者是通过数据库来存储调取详情信息。
- AuthorizationServerEndpointsConfigurer: 用来配置令牌（token）的访问端点和令牌服务（tokenServices）
- AuthorizationServerSecurityConfigurer: 用来配置令牌端点的安全约束
测试：
客户端模式：client_credentials:
- 这种模式是最方柏霓但是也是最不安全的模式，戴白哦了授权服务器对客户端的完全互信。因此，这种模式一般可以用在授权服务器对客户端完全信任的场景，例如内部系统或者协议合作方系统对接。
密码模式：
- 这种模式用户会把用户名和密码直接泄露给客户端，代表了资源拥有者和授权服务器对客户端的绝对互信，相信客户端不会做坏事。一般适用于内部开发的客户端的场景。
简化模式 implicit
示例：
- 这种方案下，一般redirect_uri会配置称客户端自己的一个响应地址。这个响应地址接收到授权服务器推送过来的访问令牌后，就可以将访问令牌在本地进行保存，然后在需要调用资源服务时，再拿出来通过资源服务的认证。
- 这种模式下，access_token并不是以get请求参数的刑师推送的，而是以#fragment方式返回的
- 这种模式下，oauth三方的数据已经进行了隔离。这种模式下一般用于没有服务端的第三方单页面应用，这样可以在js里直接响应access_token
授权码模式 authorization_code
- 返回code
名词
OAuth2.0
OAuth（开放授权）是一个开放标准，允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方应用或分享他们数据的所有内容。OAuth2.0是OAuth协议的延续版本，但不想后兼容OAuth1.0即完全废止了OAuth1.0.很多大公司如google、yahoo，等都提供了OAuth认证服务，这些都足以说明OAuth标准逐渐成为开放资源授权的标准。
token
令牌，客户端访问服务资源的凭证
JWT
json web token (jwt),是为了在网络环境间传递声明而执行的一种基于JSON的开放标准（RFC_7519）.该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT声明一般被采用在身份提供者和服务提供者间传递的被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其他业务逻辑所必须的声明信息，以便于从资源服务器获取资源，也可以增加一些额外的其他业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。
Spring Security
Spring Security是一种功能强大且高度可定制的身份验证和访问控制框架。它是保护基于sprinv的应用程序的事实上的标准。
Spring Security是一个专注于为Java应用程序提供身份和授权的框架。于所有Spring项目一样，Spring Security的真正强大之处在于它可以轻松扩展以满足自定义要求。特征：
- 对身份验证和授权的全面且扩展的支持。
- 防止会话固定、点击劫持、跨站点请求仿造等攻击
- servlet API继承
- 于spring web mvc的可选集成
