Spring Security OAuth2.0认证授权

1. 基本概念

1.1 什么是认证

　　进入移动互联网时代，大家每天都在刷手机，常用的软件有微信、支付宝、头条等，下边拿微信来举例子说明认证相关的基本概念，在初次使用微信前需要注册成为微信用户，然后输入账号和密码即可登录微信，输入账号和密码登录微信的过程就是认证。

系统为什么要认证？

　　认证是为了保护系统的隐私数据与资源，用户的身份合法方可访问该系统的资源。

认证 ：用户认证就是判断一个用户的身份是否合法的过程，用户去访问系统资源时系统要求验证用户的身份信息，身份合法方可继续访问，不合法则拒绝访问。常见的用户身份认证方式有：用户名密码登录，二维码登录，手机短信登录，指纹认证等方式。

1.2 什么是会话

　　用户认证通过后，为了避免用户的每次操作都进行认证可将用户的信息保证在会话中。会话就是系统为了保持当前用户的登录状态所提供的机制，常见的有基于session方式、基于token方式等。

基于session的认证方式如下图：

　　它的交互流程是，用户认证成功后，在服务端生成用户相关的数据保存在session(当前会话)中，发给客户端的sesssion_id 存放到 cookie 中，这样用户客户端请求时带上 session_id 就可以验证服务器端是否存在 session 数据，以此完成用户的合法校验，当用户退出系统或session过期销毁时,客户端的session_id也就无效了。

基于token方式如下图：

　　它的交互流程是，用户认证成功后，服务端生成一个token发给客户端，客户端可以放到 cookie 或 localStorage等存储中，每次请求时带上 token，服务端收到token通过验证后即可确认用户身份。

 

• 基于session的认证方式由Servlet规范定制，服务端要存储session信息需要占用内存资源，客户端需要支持cookie；
• 基于token的方式则一般不需要服务端存储token，并且不限制客户端的存储方式。如今移动互联网时代更多类型的客户端需要接入系统，系统多是采用前后端分离的架构进行实现，所以基于token的方式更适合。

1.3 什么是授权

　　例如微信登录成功后用户即可使用微信的功能，比如，发红包、发朋友圈、添加好友等，没有绑定银行卡的用户是无法发送红包的，绑定银行卡的用户才可以发红包，发红包功能、发朋友圈功能都是微信的资源即功能资源，用户拥有发红包功能的权限才可以正常使用发送红包功能，拥有发朋友圈功能的权限才可以使用发朋友圈功能，这个根据用户的权限来控制用户使用资源的过程就是授权。

为什么要授权？

　　认证是为了保证用户身份的合法性，授权则是为了更细粒度的对隐私数据进行划分，授权是在认证通过后发生的，控制不同的用户能够访问不同的资源。

授权： 授权是用户认证通过根据用户的权限来控制用户访问资源的过程，拥有资源的访问权限则正常访问，没有权限则拒绝访问。

2. 分布式系统认证方案

2.1 什么是分布式系统

　　随着软件环境和需求的变化 ，软件的架构由单体结构演变为分布式架构，具有分布式架构的系统叫分布式系统，分布式系统的运行通常依赖网络，它将单体结构的系统分为若干服务，服务之间通过网络交互来完成用户的业务处理，当前流行的微服务架构就是分布式系统架构，如下图：

分布式系统具体如下基本特点：

1、分布性：每个部分都可以独立部署，服务之间交互通过网络进行通信，比如：订单服务、商品服务。

2、伸缩性：每个部分都可以集群方式部署，并可针对部分结点进行硬件及软件扩容，具有一定的伸缩能力。

3、共享性：每个部分都可以作为共享资源对外提供服务，多个部分可能有操作共享资源的情况。

4、开放性：每个部分根据需求都可以对外发布共享资源的访问接口，并可允许第三方系统访问。

2.2 分布式认证需求

　　分布式系统的每个服务都会有认证、授权的需求，如果每个服务都实现一套认证授权逻辑会非常冗余，考虑分布式系统共享性的特点，需要由独立的认证服务处理系统认证授权的请求；考虑分布式系统开放性的特点，不仅对系统内部服务提供认证，对第三方系统也要提供认证。分布式认证的需求总结如下：

（1）统一认证授权

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

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

（2）应用接入认证

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

2.3 分布式认证方案

2.3.1 选型分析

1、基于session的认证方式

　　在分布式的环境下，基于session的认证会出现一个问题，每个应用服务都需要在session中存储用户身份信息，通过负载均衡将本地的请求分配到另一个应用服务需要将session信息带过去，否则会重新认证。

 

这个时候，通常的做法有下面几种：

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

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

Session集中存储：将Session存入分布式缓存中，所有服务器应用实例统一从分布式缓存中存取Session。

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

2、基于token的认证方式

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

 2.3.2 技术方案

　　根据 选型的分析，决定采用基于token的认证方式，它的优点是：

1、适合统一认证的机制，客户端、一方应用、三方应用都遵循一致的认证机制。

2、token认证方式对第三方应用接入更适合，因为它更开放，可使用当前有流行的开放协议Oauth2.0、JWT等。

3、一般情况服务端无需存储会话信息，减轻了服务端的压力。

分布式系统认证技术方案见下图：

流程描述：

（1）用户通过接入方（应用）登录，接入方采取OAuth2.0方式在统一认证服务(UAA)中认证。

（2）认证服务(UAA)调用验证该用户的身份是否合法，并获取用户权限信息。

（3）认证服务(UAA)获取接入方权限信息，并验证接入方是否合法。

（4）若登录用户以及接入方都合法，认证服务生成jwt令牌返回给接入方，其中jwt中包含了用户权限及接入方权限。

（5）后续，接入方携带jwt令牌对API网关内的微服务资源进行访问。

（6）API网关对令牌解析、并验证接入方的权限是否能够访问本次请求的微服务。

（7）如果接入方的权限没问题，API网关将原请求header中附加解析后的明文Token，并将请求转发至微服务。

（8）微服务收到请求，明文token中包含登录用户的身份和权限信息。因此后续微服务自己可以干两件事：

1. 用户授权拦截（看当前用户是否有权访问该资源）
2. 将用户信息存储进当前线程上下文（有利于后续业务逻辑随时获取当前用户信息）

流程所涉及到UAA服务、API网关这三个组件职责如下：

1）统一认证服务(UAA)

　　它承载了OAuth2.0接入方认证、登入用户的认证、授权以及生成令牌的职责，完成实际的用户认证、授权功能。

2）API网关

　　作为系统的唯一入口，API网关为接入方提供定制的API集合，它可能还具有其它职责，如身份验证、监控、负载均衡、缓存等。API网关方式的核心要点是，所有的接入方和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。

3. OAuth2.0

3.1 OAuth2.0介绍

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

3.2 OAuth2.0认证流程

1）客户端请求第三方授权 

2）资源拥有者同意给客户端授权

3）客户端获取到授权码，请求认证服务器申请令牌 

4）认证服务器向客户端响应令牌

5）客户端请求资源服务器的资源

6）资源服务器返回受保护资源

OAauth2.0包括以下角色：

1）客户端

　　本身不存储资源，需要通过资源拥有者的授权去请求资源服务器的资源，比如：Android客户端、Web客户端（浏览器端）、微信客户端等。

2）资源拥有者

　　通常为用户，也可以是应用程序，即该资源的拥有者。

3）授权服务器（也称认证服务器）

　　用于服务提供商对资源拥有的身份进行认证、对访问资源进行授权，认证成功后会给客户端发放令牌（access_token），作为客户端访问资源服务器的凭据。

4）资源服务器

　　存储资源的服务器

现在还有一个问题，服务提供商能允许随便一个客户端就接入到它的授权服务器吗？答案是否定的，服务提供商会给准入的接入方一个身份，用于接入时的凭据:

client_id：客户端标识

client_secret：客户端秘钥

因此，准确来说，授权服务器对两种OAuth2.0中的两个角色进行认证授权，分别是资源拥有者、客户端。 

4. Spring Cloud Security OAuth2

　　Spring-Security-OAuth2是对OAuth2的一种实现，并且跟Spring Security相辅相成，与SpringCloud体系的集成也非常便利。

　　OAuth2.0的服务提供方涵盖两个服务，即授权服务 (Authorization Server，也叫认证服务) 和资源服务 (ResourceServer)，使用 Spring Security OAuth2 的时候你可以选择把它们在同一个应用程序中实现，也可以选择建立使用同一个授权服务的多个资源服务。

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

• AuthorizationEndpoint 服务于认证请求。默认 URL： /oauth/authorize 。
• TokenEndpoint 服务于访问令牌的请求。默认 URL： /oauth/token 。
• 资源服务 (Resource Server)，应包含对资源的保护功能，对非法请求进行拦截，对请求中token进行解析鉴权等，下面的过滤器用于实现 OAuth 2.0 资源服务：
• OAuth2AuthenticationProcessingFilter用来对请求给出的身份令牌解析鉴权。

4.1 授权服务器配置

　　可以用 @EnableAuthorizationServer 注解并继承AuthorizationServerConfifigurerAdapter来配置OAuth2.0 授权服务器。

在Confifig包下创建AuthorizationServer：

@Configuration 
@EnableAuthorizationServer 
public class AuthorizationServer extends AuthorizationServerConfigurerAdapter { 
    //略... 
}

AuthorizationServerConfifigurerAdapter要求配置以下几个类，这几个类是由Spring创建的独立的配置对象，它们会被Spring传入AuthorizationServerConfifigurer中进行配置。

public class AuthorizationServerConfigurerAdapter implements AuthorizationServerConfigurer {
 　 public AuthorizationServerConfigurerAdapter() {} 
　　public void configure(AuthorizationServerSecurityConfigurer security) throws Exception {} 
　　public void configure(ClientDetailsServiceConfigurer clients) throws Exception {} 
　　public void configure(AuthorizationServerEndpointsConfigurer endpoints) throws Exception {} 
}

ClientDetailsServiceConfifigurer：用来配置客户端详情服务（ClientDetailsService），客户端详情信息在这里进行初始化，你能够把客户端详情信息写死在这里或者是通过数据库来存储调取详情信息。

AuthorizationServerEndpointsConfifigurer：用来配置令牌（token）的访问端点和令牌服务(token services)。

AuthorizationServerSecurityConfifigurer：用来配置令牌端点的安全约束

4.1.1 配置客户端详细信息

　　ClientDetailsServiceConfifigurer 能够使用内存或者JDBC来实现客户端详情服务（ClientDetailsService），ClientDetailsService负责查找ClientDetails，而ClientDetails有几个重要的属性如下列表：

clientId：（必须的）用来标识客户的Id。

secret：（需要值得信任的客户端）客户端安全码，如果有的话。

scope：用来限制客户端的访问范围，如果为空（默认）的话，那么客户端拥有全部的访问范围。

authorizedGrantTypes：此客户端可以使用的授权类型，默认为空。

authorities：此客户端可以使用的权限（基于Spring Security authorities）。 

 /**
     * 用来配置客户端详情服务（ClientDetailsService），客户端详情信息在 这里进行初始化，
     * 你能够把客户端详情信息写死在这里或者是通过数据库来存储调取详情信息。
     *
     * @param clients 客户端详情服务
     */
    @Override
    public void configure(ClientDetailsServiceConfigurer clients)
            throws Exception {
        clients.withClientDetails(clientDetailsService);
       /* clients.inMemory()// 使用in-memory存储,存储到内存中
                .withClient("c1")// client_id
                .secret(new BCryptPasswordEncoder().encode("secret"))//客户端密钥client_secret
                .resourceIds("res1")//资源列表
                .authorizedGrantTypes("authorization_code", "password", "client_credentials", "implicit", "refresh_token")// 该client允许的授权类型authorization_code,password,refresh_token,implicit,client_credentials
                .scopes("all")// 允许的授权范围
                .autoApprove(false)//false跳转到授权页面
                //加上验证回调地址
                .redirectUris("http://www.baidu.com")*/
        ;
    }

4.1.2 管理令牌的三种方式

　　AuthorizationServerTokenServices 接口定义了一些操作使得你可以对令牌进行一些必要的管理，令牌可以被用来加载身份信息，里面包含了这个令牌的相关权限。自己可以创建 AuthorizationServerTokenServices 这个接口的实现，则需要继承 DefaultTokenServices 这个类，里面包含了一些有用实现，你可以使用它来修改令牌的格式和令牌的存储。默认的，当它尝试创建一个令牌的时候，是使用随机值来进行填充的，除了持久化令牌是委托一个 TokenStore 接口来实现以外，这个类几乎帮你做了所有的事情。并且 TokenStore 这个接口有一个默认的实现，它就是 InMemoryTokenStore ，如其命名，所有的令牌是被保存在了内存中。除了使用这个类以外，你还可以使用一些其他的预定义实现，下面有几个版本，它们都实现了TokenStore接口： 

1）InMemoryTokenStore：这个版本的实现是被默认采用的，它可以完美的工作在单服务器上（即访问并发量压力不大的情况下，并且它在失败的时候不会进行备份），大多数的项目都可以使用这个版本的实现来进行尝试，你可以在开发的时候使用它来进行管理，因为不会被保存到磁盘中，所以更易于调试。

2）JdbcTokenStore：这是一个基于JDBC的实现版本，令牌会被保存进关系型数据库。使用这个版本的实现时，你可以在不同的服务器之间共享令牌信息，使用这个版本的时候请注意把"spring-jdbc"这个依赖加入到你的classpath当中。

3）JwtTokenStore：这个版本的全称是 JSON Web Token（JWT），它可以把令牌相关的数据进行编码（因此对于后端服务来说，它不需要进行存储，这将是一个重大优势），但是它有一个缺点，那就是撤销一个已经授权令牌将会非常困难，所以它通常用来处理一个生命周期较短的令牌以及撤销刷新令牌（refresh_token）。另外一个缺点就是这个令牌占用的空间会比较大，如果你加入了比较多用户凭证信息。JwtTokenStore 不会保存任何数据，但是它在转换令牌值以及授权信息方面与 DefaultTokenServices 所扮演的角色是一样的。 

4.1.3 令牌访问端点配置 

　　AuthorizationServerEndpointsConfifigurer 这个对象的实例可以完成令牌服务以及令牌endpoint配置。

4.1.3.1 配置授权类型（Grant Types）

　　AuthorizationServerEndpointsConfifigurer 通过设定以下属性决定支持的授权类型（Grant Types）:

authenticationManager：认证管理器，当你选择了资源所有者密码（password）授权类型的时候，请设置这个属性注入一个 AuthenticationManager 对象。

userDetailsService：如果你设置了这个属性的话，那说明你有一个自己的 UserDetailsService 接口的实现，或者你可以把这个东西设置到全局域上面去（例如 GlobalAuthenticationManagerConfifigurer 这个配置对象），当你设置了这个之后，那么 "refresh_token" 即刷新令牌授权类型模式的流程中就会包含一个检查，用来确保这个账号是否仍然有效，假如说你禁用了这个账户的话。

4.1.3.2 配置授权端点的URL（Endpoint URLs）：

AuthorizationServerEndpointsConfifigurer 这个配置对象有一个叫做 pathMapping() 的方法用来配置端点URL链接，它有两个参数：

第一个参数：String 类型的，这个端点URL的默认链接。

第二个参数：String 类型的，你要进行替代的URL链接。

以上的参数都将以 "/" 字符为开始的字符串，框架的默认URL链接如下列表，可以作为这个 pathMapping() 方法的第一个参数：

/oauth/authorize：授权端点。

/oauth/token：令牌端点。

/oauth/confifirm_access：用户确认授权提交端点。

/oauth/error：授权服务错误信息端点。

/oauth/check_token：用于资源服务访问的令牌解析端点。

/oauth/token_key：提供公有密匙的端点，如果你使用JWT令牌的话。

需要注意的是授权端点这个URL应该被Spring Security保护起来只供授权用户访问. 

4.1.4 令牌端点的安全约束

　　AuthorizationServerSecurityConfifigurer：用来配置令牌端点(Token Endpoint)的安全约束

4.1.5 web安全配置

　　和secutity的WebSecurityConfigurerAdapter配置一样

 

 项目下载地址：https://gitee.com/donleo/springcloud-security-oauth2.git