Spring security OAuth2 深入解析

一、OAuth2 概要

1.1.OAuth2基本流程

话不多说，先上图：

分析一波：

client：第三方应用（即App或向外提供接口）
Resource Owner:资源所有者（即用户）
Authentication Server:授权认证服务（发配Access Token）
Resource Server：资源服务器（存储用户资源信息等资源）

其实不管微信或者QQ大体上都是使用这种OAuth2的基本流程：

第三方应用请求用户授权；
用户同意授权，并返回一个授权码（code）；
第三方应用根据授权码（code）向授权认证服务进行授权；
授权服务器根据授权码（code），校验通过，并返回给第三方应用令牌（Access Token）；
第三方应用根据令牌（Access Token）向资源服务请求相关资源；
资源服务器验证令牌（Access Token），校验通过，并返回第三方所请求的资源。

1.2.服务类型

OAuth2 在服务提供者上可分为两类：

授权认证服务：AuthenticationServer

@Configuration
@EnableAuthorizationServer
public class CustomAuthenticationServerConfig extends AuthorizationServerConfigurerAdapter

资源获取服务：ResourceServer

@Configuration
@EnableResourceServer
public class CustomResourceServerConfig extends ResourceServerConfigurerAdapter

注：这两者有时候可能存在同一个应用程序中（即SOA架构）。在Spring OAuth中可以简便的将其分配到两个应用中（即微服务），而且可多个资源获取服务共享一个授权认证服务。

1.3.授权认证服务

主要的操作：

获取第三方应用发送的授权码（code）以及第三方应用标识
根据授权码及标识进行校验
校验通过，发送令牌（Access Token）

分析一波：
1）第一步操作：

授权码（code）：第三方应用进行第一步“Authorization Request”时，请求参数redirect_uri中的回调链接，服务会生成相关用户凭证，并在其回调链接上附带code
第三方用户标识：
- client_id: 第三方用户的id（可理解为账号）
- client_secret:第三方应用和授权服务器之间的安全凭证(可理解为密码)

注：其中client_id和client_secret都是授权服务器发送给第三方应用的，如：微信等一系列授权，在其平台上注册，获取其appid和secret同样道理（个人理解为账号密码）。

既然是账号秘密，总不能以get请求，也太不安全了。因此，OAuth2要求该请求必须是POST请求，同时，还必须时HTTPS服务，以此保证获取到的安全凭证（Access Token）的安全性。

2）第二步操作：

授权认证服务器根据标识校验第三方应用的真实性
授权认证服务器根据授权码（code）进行校验用户凭证

3）第三步操作：

生成Access Token（MD5类型，uuid类型，jwt类型等）

1.4.资源获取服务

主要的操作：

校验Access Token
发放资源信息

二、Spring Security OAuth2的使用

1.授权认证服务

spring OAuth2中，我们配置一个授权认证服务，我们最主要有以下三点：

第三方用户客户端详情 → Client
令牌的生成管理 → Access Token
端点接入 → endpoints

spring中有三个配置与这三点一一对应：

ClientDetailsServiceConfigurer：用来配置客户端详情服务。
AuthorizationServerSecurityConfigurer：用来配置令牌端点(Token Endpoint)的安全约束.
AuthorizationServerEndpointsConfigurer：来配置授权（authorization）以及令牌（token）的访问端点和令牌服务(token services)

1.1.第三方用户客户端详情

除了上面说到的client_id和client_secret，还需要一些服务附带一些授权认证参数。

1).Grant Type

其实OAuth2不仅提供授权码（code）这种格式授权方式，还提供几个其他类型。其中用Grant Type代表当前授权的类型。 Grant Type包括：

authorization_code：传统的授权码模式
implicit：隐式授权模式
password：资源所有者（即用户）密码模式
client_credentials：客户端凭据（客户端ID以及Key）模式
refresh_token：获取access token时附带的用于刷新新的token模式

2).scope

其实授权赋予第三方用户可以在资源服务器获取资源，经常就是调取Api请求附带令牌，然而调取api有增删查改等功能，而scopes的值就是all（全部权限），read，write等权限。就是第三方访问资源的一个权限，访问范围。

3).accessTokenValiditySeconds

还可以设置accessTokenValiditySeconds属性来设置Access Token的存活时间。

@Override
public void configure(ClientDetailsServiceConfigurer clients) throws Exception {

    clients.inMemory()
            .withClient("catalpaFlat")
            .secret("catalpaFlat-secret")
            .accessTokenValiditySeconds(7200)
            .authorizedGrantTypes("refresh_token","password")
            .scopes("all");
｝

1.2.令牌的生成和管理

AccessToken的存在意义：

创建AccessToken，并保存，以备后续请求访问都可以认证成功并获取到资源
AccessToken还有一个潜在功能，就是使用jwt生成token时候，可以用来加载一些信息，把一些相关权限等包含在AccessToken中

1).AuthorizationServerTokenServices
AuthorizationServerTokenServices 提供了对AccessToken的相关操作创建、刷新、获取。

public interface AuthorizationServerTokenServices {

	OAuth2AccessToken createAccessToken(OAuth2Authentication authentication) throws AuthenticationException;

	
	OAuth2AccessToken refreshAccessToken(String refreshToken, TokenRequest tokenRequest)
			throws AuthenticationException;

	
	OAuth2AccessToken getAccessToken(OAuth2Authentication authentication);

}

2).DefaultTokenServices

AuthorizationServerTokenServices竟然可以操作AccessToken，那么OAuth2就默认为我们提供了一个默认的DefaultTokenServices。包含了一些有用实现，可以使用它来修改令牌的格式和令牌的存储等，但是生成的token是随机数。

3).TokenStore

创建AccessToken完之后，除了发放给第三方，肯定还得保存起来，才可以使用。因此，TokenStore为我们完成这一操作，将令牌（AccessToken）保存或持久化。
TokenStore也有一个默认的实现类InMemoryTokenStore，从名字就知道是通过保存到内存进而实现保存Access Token。 TokenStore的实现有多种类型，可以根据业务需求更改Access Token的保存类型：

InMemoryTokenStore：这个是OAuth2默认采用的实现方式。在单服务上可以体现出很好特效（即并发量不大，并且它在失败的时候不会进行备份），大多项目都可以采用此方法。毕竟存在内存，而不是磁盘中，调试简易。
JdbcTokenStore：这个是基于JDBC的实现，令牌（Access Token）会保存到数据库。这个方式，可以在多个服务之间实现令牌共享。
JwtTokenStore：jwt全称 JSON Web Token。这个实现方式不用管如何进行存储（内存或磁盘），因为它可以把相关信息数据编码存放在令牌里。JwtTokenStore 不会保存任何数据，但是它在转换令牌值以及授权信息方面与 DefaultTokenServices 所扮演的角色是一样的。但有两个缺点：
- 撤销一个已经授权的令牌会很困难，因此只适用于处理一个生命周期较短的以及撤销刷新令牌。
- 令牌占用空间大，如果加入太多用户凭证信息，会存在传输冗余

4).JWT Token

想使用jwt令牌，需要在授权服务中配置JwtTokenStore。之前说了，jwt将一些信息数据编码后存放在令牌,那么其实在传输的时候是很不安全的，所以Spring OAuth2提供了JwtAccessTokenConverter来怼令牌进行编码和解码。适用JwtAccessTokenConverter可以自定义秘签（SigningKey）。SigningKey用处就是在授权认证服务器生成进行签名编码，在资源获取服务器根据SigningKey解码校验。

JwtAccessTokenConverter jwtAccessTokenConverter = new JwtAccessTokenConverter();

 jwtAccessTokenConverter.setSigningKey("CatalpaFlat")

1.3.端点接入-endpoints

授权认证是使用AuthorizationEndpoint这个端点来进行控制，一般使用AuthorizationServerEndpointsConfigurer 来进行配置。

@Override
public void configure(AuthorizationServerEndpointsConfigurer endpoints) throws Exception {}

1).端点（endpoints）的相关属性配置：

authenticationManager：认证管理器。若我们上面的Grant Type设置为password，则需设置一个AuthenticationManager对象
userDetailsService：若是我们实现了UserDetailsService,来管理用户信息，那么得设我们的userDetailsService对象
authorizationCodeServices：授权码服务。若我们上面的Grant Type设置为authorization_code，那么得设一个AuthorizationCodeServices对象
tokenStore：这个就是我们上面说到，把我们想要是实现的Access Token类型设置
accessTokenConverter：Access Token的编码器。也就是JwtAccessTokenConverter
tokenEnhancer:token的拓展。当使用jwt时候，可以实现TokenEnhancer来进行jwt对包含信息的拓展
tokenGranter：当默认的Grant Type已经不够我们业务逻辑，实现TokenGranter 接口，授权将会由我们控制，并且忽略Grant Type的几个属性。

2).端点（endpoints）的授权url：要授权认证，肯定得由url请求，才可以传输。因此OAuth2提供了配置授权端点的URL。
AuthorizationServerEndpointsConfigurer ，还是这个配置对象进行配置，其中由一个pathMapping()方法进行配置授权端点URL路径，默认提供了两个参数defaultPath和customPath：

public AuthorizationServerEndpointsConfigurer pathMapping(String defaultPath, String customPath) {
		this.patternMap.put(defaultPath, customPath);
		return this;
}

pathMapping的defaultPath有：

/oauth/authorize：授权端点
/oauth/token：令牌端点
/oauth/confirm_access：用户确认授权提交端点
/oauth/error：授权服务错误信息端点
/oauth/check_token：用于资源服务访问的令牌解析端点
/oauth/token_key：提供公有密匙的端点，如果使用JWT令牌的话

注：pathMapping的两个参数都将以 "/" 字符为开始的字符串

1.4.自定义错误处理（Error Handling）

实际上我们上面说到的端点，其实可以看成Controller，用于返回不同端点的响应内容。

授权服务的错误信息是使用标准的Spring MVC来进行处理的，也就是 @ExceptionHandler 注解的端点方法，我们可以提供一个 WebResponseExceptionTranslator 对象。最好的方式是改变响应的内容而不是直接进行渲染。

假如说在呈现令牌端点的时候发生了异常，那么异常委托了 HttpMessageConverters 对象（它能够被添加到MVC配置中）来进行输出。
假如说在呈现授权端点的时候未通过验证，则会被重定向到 /oauth/error 即错误信息端点中。whitelabel error （即Spring框架提供的一个默认错误页面）错误端点提供了HTML的响应，但是我们大概可能需要实现一个自定义错误页面（例如只是简单的增加一个 @Controller 映射到请求路径上 @RequestMapping("/oauth/error")）。

2.资源获取服务

资源服务器，其实就是存放一些受令牌保护的资源，只有令牌并且有效正确才能获取到资源。内部是通过Spring OAuth2的Spring Security Authentication filter 的过滤链来进行保护。

2.1.ResourceServerConfigurerAdapter

我们可以继承ResourceServerConfigurerAdapter，来使用 ResourceServerSecurityConfigurer进行相关配置。

public class ResourceServerConfigurerAdapter implements ResourceServerConfigurer {

	@Override
	public void configure(ResourceServerSecurityConfigurer resources) throws Exception {
	}

	@Override
	public void configure(HttpSecurity http) throws Exception {
		http.authorizeRequests().anyRequest().authenticated();
	}
｝

2.2.ResourceServerSecurityConfigurer的相关属性

tokenServices：ResourceServerTokenServices 类的实例，用来实现令牌服务。
resourceId：这个资源服务的ID，这个属性是可选的，但是推荐设置并在授权服务中进行验证。
tokenExtractor 令牌提取器用来提取请求中的令牌。
请求匹配器，用来设置需要进行保护的资源路径，默认的情况下是受保护资源服务的全部路径。
受保护资源的访问规则，默认的规则是简单的身份验证（plain authenticated）。
其他的自定义权限保护规则通过 HttpSecurity 来进行配置。

2.3.ResourceServerTokenServices

ResourceServerTokenServices 是组成授权服务的另一半。

1）.若是资源服务器和授权服务在同一个应用，可以使用DefaultTokenServices

2）.若是分离的。ResourceServerTokenServices必须知道令牌的如何解码。

ResourceServerTokenServices解析令牌的方法：

使用RemoteTokenServices，资源服务器通过HTTP请求来解码令牌。每次都请求授权服务器的端点-/oauth/check_toke，以此来解码令牌
若是访问量大，则通过http获取之后，换成令牌的结果
若是jwt令牌，需请求授权服务的/oauth/token_key，来获取key进行解码

注：授权认证服务需要把/oauth/check_toke暴露出来，并且附带上权限访问。

@Override
public void configure(AuthorizationServerSecurityConfigurer oauthServer) throws Exception {
    oauthServer.tokenKeyAccess("isAnonymous() || hasAuthority('ROLE_TRUSTED_CLIENT')")
        .checkTokenAccess("hasAuthority('ROLE_TRUSTED_CLIENT')");
}

(～￣▽￣)～未完待续... ...