Spring Security Oauth2.0认证授权
基本概念
认证: 用户认证就是判断一个用户的身份是否合法的过程 ，用户去访问系统资源时系统要求验证用户的身份信息，身份合法方可继续访问，不合法则拒绝访问。常见的用户身份认证方式有:用户名密码登录，二维码登录，手机短信登录，指纹认证等方式。
会话:用户认证通过后,为了避免用户的每次操作都进行认证可将用户的信息保证在会话中。会话就是系统为了保持当前用户的登录状态所提供的机制,常见的有基于session方式、基于token方式等。
授权:授权是用户认证通过后根据用户的权限来控制用户访问资源的过程,拥有资源的访问权限则正常访问，没有权限则拒绝访问。授权可简单理解为Who对What(which)进行How操作，
Who，即主体( Subject)， 主体一般是指用户，也可以是程序，需要访问系统中的资源。
What，即资源( Resource)， 如系统菜单、页面、按钮、代码方法、系统商品信息、系统订单信息等。系统菜单、页面、按钮、代码方法都属于 系统功能资源,对于web系统每个功能资源通常对应一个URL ;系统商品信息系统订单信息都属于 实体资源(数据资源)， 实体资源由资源类型和资源实例组成,比如商品信息为资源类型，商品编号为001的商品为资源实例。
How ,权限/许可( Permission)， 规定了用户对资源的操作许可,权限离开资源没有意义，如用户查询权限、用户添加权限、某个代码方法的调用权限、编号为001的用户的修改权限等，通过权限可知用户对哪些资源都有哪些操作许可。
授权的数据模型
资源和权限可以合并一起
RBAC
基于角色的访问控制 if (主体.hasRole()){}
基于资源的访问控制 if(主体.hasPermission()){}
Spring Boot Security
对所有进入系统的请求进行拦截，校验每个请求是否能够访问它所期望的资源，通过Filter实现
2.1 结构原理
初始化Spring Security时，初始化一个类型为org.springframework.security.web.FilterChainProxy的过滤器，
外部的请求会经过此类。FilterChainProxy是一个代理，真正起作用的是FilterChainProxy中SecurityFilterChain所包含的各个Filter，同时这些Filter作为Bean被Spring管理，它们是Spring Security核心，并不直接处理用户的认证，也不直接处理用户的授权，而是把它们交给了认证管理器（AuthenticationManager）和 决策管理器（AccessDecisionManager）进行处理
spring Security功能的实现主要是由一系列过滤器链相互配合完成。
2.2 认证过程
1. 用户提交用户名、密码被SecurityFilterChain中的 UsernamePasswordAuthenticationFilter 过滤器获取到，封装为请求Authentication，通常情况下是UsernamePasswordAuthenticationToken这个实现类。
2. 然后过滤器将Authentication提交至认证管理器（AuthenticationManager）进行认证
3. 认证成功后， AuthenticationManager 身份管理器返回一个被填充满了信息的（包括上面提到的权限信息，身份信息，细节信息，但密码通常会被移除） Authentication 实例。
4. SecurityContextHolder 安全上下文容器将第3步填充了信息的 Authentication ，通过
SecurityContextHolder.getContext().setAuthentication(…)方法，设置到其中。
AuthenticationManager接口（认证管理器）是认证相关的核心接口，也是发起认证的出发点，
它的实现类为ProviderManager。
而Spring Security支持多种认证方式，因此ProviderManager维护着一个List
列表，存放多种认证方式，最终实际的认证工作是由AuthenticationProvider完成。不同的认证方式使用不同的AuthenticationProvider。如使用用户名密码登录时，使用DaoAuthenticationProvide
DaoAuthenticationProvider，它的内部又维护着一个UserDetailsService负责UserDetails的获取。最终AuthenticationProvider将UserDetails填充至Authentication。
2.3 密码处理
Spring Security提供了很多内置的PasswordEncoder，能够开箱即用，使用某种PasswordEncoder只需要进行如
下声明即可
常见的密码编码器有
NoOpPasswordEncoder、BCryptPasswordEncoder、Pbkdf2PasswordEncode、SCryptPasswordEncoder
2.4 授权过程
已认证用户访问受保护的web资源将被SecurityFilterChain中的 FilterSecurityInterceptor 的子类拦截。
FilterSecurityInterceptor会从 SecurityMetadataSource 的子类DefaultFilterInvocationSecurityMetadataSource 获取要访问当前资源所需要的权限Collection
SecurityMetadataSource其实就是读取“安全拦截机制”
FilterSecurityInterceptor会调用 AccessDecisionManager 进行授权决策，若决策通过，则允许访问资源，否则将禁止访问。此处会从安全上下文中获取用户：Authentication authentication = SecurityContextHolder.getContext().getAuthentication(); 再进行比对和判断。
decide接口就是用来鉴定当前用户是否有访问对应受保护资源的权限。
authentication：要访问资源的访问者的身份
object：要访问的受保护资源，web请求对应FilterInvocation
confifigAttributes：是受保护资源的访问策略，通过SecurityMetadataSource获取。
Spring Security内置了三个基于投票的AccessDecisionManager实现类
AffirmativeBased 只要有一个赞成票，则表示同意用户访问
ConsensusBased：赞成票多余反对票，则表示同意用户访问
UnanimousBased：只要有一个反对票，则表示反对用户访问
spring security为防止CSRF（Cross-site request forgery跨站请求伪造）的发生，限制了除了get以外的大多数方法，
解决方法1：
屏蔽CSRF控制，即spring security不再限制CSRF。httpSecurity.csrf().disable()
解决方法2：
表单添加隐藏域:
2.5 实际应用
用户认证通过后，为了避免用户的每次操作都进行认证可将用户的信息保存在会话中。spring security提供会话管理，认证通过后将身份信息放入SecurityContextHolder上下文，SecurityContext与当前线程进行绑定，方便获取用户身份。
Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
2.5.1 会话控制
Spring Security会为每个登录成功的用户会新建一个Session
httpSecurity.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
session超时、session失效后，通过Spring Security 设置跳转的路径。
httpSecurity.sessionManagement()
.expiredUrl("/login‐view?error=EXPIRED_SESSION")
.invalidSessionUrl("/login‐view?error=INVALID_SESSION");
session退出
httpSecurity.logout()
.logoutUrl("/logout")
.logoutSuccessUrl("/login‐view?logout")
.logoutSuccessHandler(logoutSuccessHandler)
.addLogoutHandler(logoutHandler)
.invalidateHttpSession(true)
定制的 LogoutSuccessHandler ，实现用户退出成功时的处理。如果指定了这个选项那么logoutSuccessUrl() 的设置被忽略；
添加一个 LogoutHandler ，用于实现用户退出时的清理工作.默认 SecurityContextLogoutHandler 会被添加为最后一个 LogoutHandler；
指定是否在退出时让 HttpSession 无效。 默认设置为 true。
2.5.2 web授权
使用 http.authorizeRequests() 对web资源进行授权保护
httpSecurity
.authorizeRequests()
.antMatchers("/r/r1").hasAuthority("p1") (
.antMatchers("/r/r2").hasAuthority("p2")
.antMatchers("/r/r3").access("hasAuthority('p1') and hasAuthority('p2')")
.antMatchers("/r/**").authenticated()
.anyRequest().permitAll()
.and()
.formLogin()
保护URL常用的方法有：
authenticated() 保护URL，需要用户登录
permitAll() 指定URL无需保护，一般应用与静态资源文件
hasRole(String role) 限制单个角色访问，角色将被增加 “ROLE_” .所以”ADMIN” 将和 “ROLE_ADMIN”进行比较.
hasAuthority(String authority) 限制单个权限访问
hasAnyRole(String… roles)允许多个角色访问.
hasAnyAuthority(String… authorities) 允许多个权限访问.
access(String attribute) 该方法使用 SpEL表达式, 所以可以创建复杂的限制.
hasIpAddress(String ipaddressExpression) 限制IP地址或子网
2.5.3.方法授权
以在任何 @Configuration 实例上使用 @EnableGlobalMethodSecurity 注释来启用基于注解的安全性。
@PreAuthorize,@PostAuthorize, @Secured三类注解作用域服务层方法上，限制访问的访问
例如：
匿名访问
@Secured("IS_AUTHENTICATED_ANONYMOUSLY")
@PreAuthorize("isAnonymous()")
方法可匿名访问，底层使用WebExpressionVoter投票器
@PreAuthorize
@PreAuthorize("hasAuthority('p_transfer') and hasAuthority('p_read_account')")
同时拥有p_transfer和p_read_account权限才能访问，底层使用WebExpressionVoter投票器
另外，还有注解@PostAuthorize
分布式系统认证方案
软件的架构由单体结构演变为分布式架构，具有分布式架构的系统叫分布式系统，分布式系统的运行通常依赖网络，它将单体结构的系统分为若干服务，服务之间通过网络交互来完成用户的业务处理，当前流行的微服务架构就是分布式系统架构。
3.1 分布式认证需求
分布式系统的每个服务都会有认证、授权的需求，考虑分布式系统共享性的特点，需要由独立的认证服务处理系统认证授权的请求；考虑分布式系统开放性的特点，不仅对系统内部服务提供认证，对第三方系统也要提供认证。分布式认证的需求总结如下：
统一认证授权
提供独立的认证服务，统一处理认证授权。无论是不同类型的用户，还是不同种类的客户端(web端，H5、APP)，均采用一致的认证、权限、会话机制，实现统一认证授权。要实现统一则认证方式必须可扩展，支持各种认证需求，比如：用户名密码认证、短信验证码、二维码、人脸识别等认证方式，并可以非常灵活的切换。
应用接入认证
应提供扩展和开放能力，提供安全的系统对接机制，并可开放部分API给接入第三方使用，一方应用（内部系统服务）和三方应用（第三方应用）均采用统一机制接入。
3.2 选型分析
3.2.1 基于Session认证
每个应用服务都需要在session中存储用户身份信息，通常的做法有下面几种：
Session复制：多台应用服务器之间同步session，使session保持一致，对外透明。
Session黏贴：当用户访问集群中某台服务器后，强制指定后续所有请求均落到此机器上。
Session集中存储：将Session存入分布式缓存中，所有服务器应用实例统一从分布式缓存中存取Session。
基于session认证的认证方式，可以更好的在服务端对会话进行控制，且安全性较高。但是，session机制方式基于cookie，在复杂多样的移动客户端上不能有效的使用，并且无法跨域，另外随着系统的扩展需提高session的复制、黏贴及存储的容错性。
3.2.2 基于Token认证
基于token的认证方式，服务端不用存储认证数据，易维护扩展性强， 客户端可以把token 存在任意地方，并且可以实现web和app统一认证机制。其缺点也很明显，token由于自包含信息，因此一般数据量较大，而且每次请求都需要传递，因此比较占带宽。另外，token的签名验签操作也会给cpu带来额外的处理负担。
3.2.3 技术方案
根据 选型分析，采用token认证，它的优点是：
适合统一认证的机制，客户端、一方应用、三方应用都遵循一致的认证机制。
token认证方式对第三方应用接入更适合，因为它更开放，可使用当前有流行的开放协议Oauth2.0、JWT等。
一般情况服务端无需存储会话信息，减轻了服务端的压力。
3.3 Oauth2.0
OAuth（开放授权）是一个开放标准，允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方应用或分享他们数据的所有内容。例如，第三方登录，用户 授权 电商网站 访问 用户存储在微信平台的用户信息
OAauth2.0包括以下角色：
客户端
本身不存储资源，需要通过资源拥有者的授权去请求资源服务器的资源，比如：Android客户端、Web客户端（浏览器端）、微信客户端等。
资源拥有者
通常为用户，也可以是应用程序，即该资源的拥有者。
资源服务器
存储资源的服务器，例如微信平台用户信息资源。
服务提供商会给准入的接入方一个身份，用于接入时的凭据:
client_id：客户端标识
client_secret：客户端秘钥
授权服务器（也称认证服务器）
用于服务提供商对资源拥有的身份进行认证、对访问资源进行授权，认证成功后会给客户端发放令牌，作为客户端访问资源服务器的凭据。例如：微信认证服务器。
授权服务器对OAuth2.0中的两个角色进行认证授权，分别是资源拥有者、客户端
Spring Cloud Security OAuth2
Spring-Security-OAuth2是对OAuth2的一种实现，并且跟Spring Security相辅相成，与SpringCloud体系的集成也非常便利。其服务实现包括两个服务：
认证授权服务 (Authorization Server）
应包含对接入端以及登入用户的合法性进行验证并颁发token等功能，对令牌的请求端点由 Spring MVC 控制器进行实现，下面是配置一个认证服务必须要实现的endpoints：
AuthorizationEndpoint 服务于认证请求。默认 URL：
/oauth/authorize 。
TokenEndpoint 服务于访问令牌的请求。默认 URL：
/oauth/token 。
资源服务 (Resource Server)，
应包含对资源的保护功能，对非法请求进行拦截，对请求中token进行解析鉴权等，下面的过滤器用于实现 OAuth 2.0 资源服务：
OAuth2AuthenticationProcessingFilter用来对请求给出的身份令牌解析鉴权。
4.1 授权服务器配置
可以使用
@Configuration
@EnableAuthorizationServer
注解并继承AuthorizationServerConfifigurerAdapter来配置OAuth2.0 授权服务器。
AuthorizationServerConfifigurerAdapter要求配置
ClientDetailsServiceConfifigurer：用来配置客户端详情服务（ClientDetailsService），客户端详情信息在这里进行初始化
AuthorizationServerEndpointsConfifigurer：用来配置令牌（token）的访问端点和令牌服务(tokenservices)。
AuthorizationServerSecurityConfifigurer：用来配置令牌访问端点的安全约束
4.1.1 客户端详情
ClientDetailsServiceConfifigurer能够使用内存或者JDBC来实现客户端详情，ClientDetailsService负责查找ClientDetails，而ClientDetails有几个重要的属性
客户端详情（Client Details）能够在应用程序运行的时候进行更新，可以通过访问底层的存储服务（例如将客户端详情存储在一个关系数据库的表中，就可以使用 JdbcClientDetailsService）或者通过实现
ClientRegistrationService接口（同时你也可以实现 ClientDetailsService 接口）来管理。
此次客户端详情读取数据库的配置：
4.1.2 令牌管理服务
AuthorizationServerTokenServices 接口定义了一些操作可以对令牌进行一些必要的管理,这个接口的实现，则需要继承 DefaultTokenServices,里面包含了一些有用实现，你可以使用它来修改令牌的格式和令牌的存储，其持久化令牌委托一个 TokenStore 接口来实现，TokenStore 这个接口有一个默认的实现，它就是 InMemoryTokenStore。
InMemoryTokenStore：
这个版本的实现是被默认采用的，它可以完美的工作在单服务器上（即访问并发量压力不大的情况下，并且它在失败的时候不会进行备份），大多数的项目都可以使用这个版本的实现来进行尝试，可以在开发的时候使用它来进行管理，因为不会被保存到磁盘中，更易于调试。
JdbcTokenStore：
这是一个基于JDBC的实现版本，令牌会被保存进关系型数据库。使用这个版本的实现时，你可以在不同的服务器之间共享令牌信息，使用这个版本的时候需要把"spring-jdbc"这个依赖加入到classpath。
JwtTokenStore
这个版本的全称是 JSON Web Token（JWT），它可以把令牌相关的数据进行编码（因此对于后端服务来说，它不需要进行存储，这将是一个重大优势），但是它有一个缺点，那就是撤销一个已经授权令牌将会非常困难，所以它通常用来处理一个生命周期较短的令牌以及撤销刷新令牌（refresh_token）。另外一个缺点就是这个令牌占用的空间会比较大，如果你加入了比较多用户凭证信息。JwtTokenStore 不会保存任何数据，但是它在转换令牌值以及授权信息方面与 DefaultTokenServices 所扮演的角色是一样的。
4.1.3 令牌访问端点
4.1.3.1 认证管理器
AuthorizationServerEndpointsConfifigurer通过设定以下属性决定支持的授权类型（Grant Types）:
authenticationManager
认证管理器，选择了资源所有者密码（password）授权类型的时候，请设置这个属性注入一个 AuthenticationManager 对象。
userDetailsService
设置了这个属性，需要有一个 UserDetailsService 接口的实现
authorizationCodeServices：
用来设置授权码服务（即 AuthorizationCodeServices 的实例对象），主要用于 "authorization_code" 授权码类型模式。
implicitGrantServic
这个属性用于设置隐式授权模式，用来管理隐式授权模式的状态。
tokenGranter：
授权将会交由自己来完全掌控，并且会忽略掉上面的这几个属性，这个属性一般是用作拓展用途
4.1.3.2 令牌访问点
框架的默认URL访问链接如下列表
/oauth/authorize：授权端点。
/oauth/token：令牌端点。
/oauth/confifirm_access：用户确认授权提交端点。
/oauth/error：授权服务错误信息端点。
/oauth/check_token：用于资源服务访问的令牌解析端点。
/oauth/token_key：提供公有密匙的端点，如果你使用JWT令牌的话。
AuthorizationServerEndpointsConfifigurer 这个配置对象有一个叫做 pathMapping() 的方法用来配置端点URL链接，它有两个参数：
第一个参数：String 类型的，这个端点URL的默认链接。
第二个参数：String 类型的，你要进行替代的URL链接。
4.1.4 令牌访问端点安全约束
AuthorizationServerSecurityConfigurer: ：用来配置令牌端点(Token Endpoint)的安全约束
4.1.5 WEB安全配置
4.1.6 授权类型
4.1.6.1授权码模式
资源拥有者打开客户端，客户端要求资源拥有者给予授权，它将浏览器被重定向到授权服务器，重定向时会附加客户端的身份信息
/uaa/oauth/authorize?client_id=c1&response_type=code&scope=all&redirect_uri=http://www.baidu.com
浏览器出现向授权服务器授权页面，之后用户同意授权
授权服务器将授权码（AuthorizationCode）经浏览器发送给client
客户端拿着授权码向授权服务器索要访问access_token
/uaa/oauth/token?client_id=c1&client_secret=secret&grant_type=authorization_code&code=5PgfcD&redirect_uri=http://www.baidu.com
授权服务器返回令牌(access_token)
参数列表如下
client_id：客户端准入标识。
response_type：授权码模式固定为code。
scope：客户端权限。
client_secret：客户端秘钥。
grant_type：授权类型，填写authorization_code，表示授权码模式
code：授权码，就是刚刚获取的授权码，注意：授权码只使用一次就无效了，需要重新申请。
redirect_uri：申请授权码时的跳转url，一定和申请授权码时用的redirect_uri一致。
4.1.6.2 简化模式
资源拥有者打开客户端，客户端要求资源拥有者给予授权，它将浏览器被重定向到授权服务器，重定向时会附加客户端的身份信息
/uaa/oauth/authorize?client_id=c1&response_type=token&scope=all&redirect_uri=http://www.baidu.com
浏览器出现向授权服务器授权页面，之后用户同意授权
授权服务器将授权码将令牌（access_token）以Hash的形式存放在重定向uri的fargment中发送给浏览器。fragment 主要是用来标识 URI 所标识资源里的某个资源，在 URI 的末尾通过 （#）作为 fragment 的开头，其中 # 不属于 fragment 的值。
4.1.6.3 密码模式
资源拥有者将用户名、密码发送给客户端
客户端拿着资源拥有者的用户名、密码向授权服务器请求令牌（access_token）
/uaa/oauth/token?
client_id=c1&client_secret=secret&grant_type=password&username=shangsan&password=123
授权服务器将令牌（access_token）发送给client
4.1.6.4 客户端模式
客户端向授权服务器发送自己的身份信息，并请求令牌（access_token）
确认客户端身份无误后，将令牌（access_token）发送给client
/uaa/oauth/token?client_id=c1&client_secret=secret&grant_type=client_credentials
4.2资源服务器配置
@Configuration
@EnableResourceServer
public class ResouceServerConfig extends ResourceServerConfigurerAdapter
@EnableResourceServer 注解自动增加了一个类型为 OAuth2AuthenticationProcessingFilter 的过滤器链
ResourceServerSecurityConfifigurer中主要包括：
tokenServices：ResourceServerTokenServices 类的实例，用来实现令牌服务。
tokenStore：TokenStore类的实例，指定令牌如何访问，与tokenServices配置可选
resourceId：这个资源服务的ID，这个属性是可选的，但是推荐设置并在授权服务中进行验证。
其他的拓展属性例如 tokenExtractor 令牌提取器用来提取请求中的令牌。
HttpSecurity配置这个与Spring Security类似：
请求匹配器，用来设置需要进行保护的资源路径，默认的情况下是保护资源服务的全部路径。
通过http.authorizeRequests()来设置受保护资源的访问规则
其他的自定义权限保护规则通过 HttpSecurity 来进行配置。
RemoteTokenServices 资源服务器通过 HTTP 请求来解码令牌，每次都请求授权服务器端点 /oauth/check_token
此处使用JWT校验令牌
配置安全拦截机制
@EnableResourceServer 注解自动增加了一个类型为 OAuth2AuthenticationProcessingFilter 的过滤器链,此过滤器作用，主要是用来解析网关传过来的用户信息字符串，并存入安全上下文中
4.3 网关
网关整合 OAuth2.0作为OAuth2.0的资源服务器角色，实现接入客户端权限拦截、令牌解析并转发当前登录用户信息(jsonToken)给微服务
public class AuthFilter extends ZuulFilter
校验客户端token，验证接入客户端权限，并解析后明文token，转发请求到微服务
