其他分享
首页 > 其他分享> > Spring Security OAuth2 完全解析 (流程/原理/实战定制) —— Client / ResourceServer 篇

Spring Security OAuth2 完全解析 (流程/原理/实战定制) —— Client / ResourceServer 篇

作者：互联网

一、前言

本文假设读者对 Spring Security 本身原理有一定程度的了解，假设对 OAuth2 规范流程、Jwt 有基础了解，以此来对 SpringSecurity 整合 OAuth2 有个快速全面的认识。
（关于总体流程，若对SS实在不熟悉可以简单理解为：Filter构造Authentication-> Provider认证并填充-> 设置到SecurityContext -> 而后用于Filter/AOP鉴权）

要了解一个SpringSecurity模块，就是了解它如何身份认证、如何自定义、（至于如何鉴权是SpringSecurity通用部分），对应到代码就是：背后的相关 Configurer、Filter、Authentication、Provider。

本文以最新Spring Boot版本2.6.2 按此逻辑梳理；涉及源码太多，就不放源码对照了，可以自行fork查看；斜体表示可配置自定义替换的部分

二、默认 spring-boot-starter-oauth2-client 效果预览

由 OAuth2ClientAutoConfiguration自动配置类引入的默认配置，可由代码 thirdpart-login 复现。

  1. 后端在 .yml 配置中做好相关配置
  2. 访问受限资源"/user"，后端鉴权异常后，由LoginUrlAuthenticationEntryPoint重定向到登录页。
  3. 登录页则由DefaultLoginPageGeneratingFilter根据相关配置自动构造页面String返回。
  4. 页面点击<a "href"="/oauth2/authorization/gitee">发出授权请求。
    后端OAuth2AuthorizationRequestRedirectFilter匹配响应该模板路径，返回实际授权码请求的重定向响应，转入三方授权页面：
  5. 同意授权后，Gitee会向游览器返回重定向响应。
    游览器向 "redirect-uri" 发起访问，此时被后端OAuth2LoginAuthenticationFilter匹配处理，其会用请求携带的 code 向配置的 "token-uri、user-info-uri" 发起一系列请求，最后构造出认证后的身份放入SecurityContext，以SESSION持久化等。再将先前保存在SESSION中的的受限资源访问请求拿出，重定向重新访问。

三、oauth2Login、oauth2Client 解析

1. 两者区别

这两者都是在SpringSecurity中整合OAuth2的入口方法(例http.oauth2Login())，对应OAuth2LoginConfigurer、OAuth2ClientConfigurer，只是引入Filter有所异同。简而言之：

2. 从 OAuth2 请求的维度概览

3. 必须要配置的属性：

太长就不贴了 参考Github项目代码，CommonOAuth2Provider也内建了一些常见OAuth2提供方，在之内少配几个字段也没关系。

4. 相关 Authentication

  1. OAuth2LoginAuthenticationToken
    用以给Provider认证过渡用，最初仅含code，最终包含access_token、user等。
  2. OAuth2AuthorizationCodeAuthenticationToken
    用以给Provider认证过渡用，未填充时仅含code，经填充后包含access_token等。
  3. OAuth2AuthenticationToken
    authenticated=true 认证后安全上下文实际保存的OAuth2用户认证，由convert将填充后的OAuth2LoginAuthenticationToken转换而来。

5. 相关 Filter

  1. OAuth2AuthorizationRequestRedirectFilter

    1. 通过调用OAuth2AuthorizationRequestResolver用于判断是否为授权请求（默认为 "/oauth2/authorization/{registrationId}"，可通过.oauth2Login().authorizationEndpoint().baseUri()配置) ，并且请求包装为OAuth2AuthorizationRequest后由authorizationRequestRepository（默认基于SESSION实现）将授权请求保存（后有他用）
    2. 随后重定向到追加了参数(client-id、response_type)的真实授权码请求。

  2. OAuth2LoginAuthenticationFilter
    继承自AbstractAuthenticationProcessingFilter，即负责身份认证的Filter。

    1. 当是loginProcessingUrl（默认为/login/oauth2/code/*）请求且带了code和state时，尝试以这俩参数构建OAuth2LoginAuthenticationToken且调用AuthenticationManager去进行认证。
    2. 认证通过后，调用authenticationResultConverter将认证后完全填充的OAuth2LoginAuthenticationToken转为authenticated=true的OAuth2AuthenticationToken，用以代表认证后的身份。（该converter默认就是直接提取填充后的"principal、authorities、clientid"直接new）
    3. 将先前得到 "token、refreshToken" 等信息包装为OAuth2AuthorizedClient调用 OAuth2AuthorizedClientRepository#saveAuthorizedClient保存起来（默认是基于内存实现的ClientId和Principal为key的Map）

  3. OAuth2AuthorizationCodeGrantFilter
    （该Filter，在oauth2Login()下会永远被跳过，因为该请求已被OAuth2LoginAuthenticationFilter处理后通过successHandler重定向）
    匹配带code与state的请求（表示回调请求）且满足authorizationRequestRepository.loadAuthorizationRequest不为空时（表示经过了RedirectFilter,是先前授权请求发起的），会构造 OAuth2AuthorizationCodeAuthenticationToken交由AuthenticationManager（背后交由OAuth2AuthorizationCodeAuthenticationProvider）进行认证，并将结果构造为OAuth2AuthorizedClient交由authorizedClientRepository保存，然后去除参数再将请求重定向到 "savedRequest 或者 redirect-url"。
    【注：不是很能理解该Filter这里为什么要重定向，这个重定向真的很恼火。如果API自身需要code，这重定向把参数清除了会报错；而即便API不要code了依附于它的逻辑使用authorizedClientRepository，那也是无意义多一次请求。而且其基于SESSION的实现本来没什么问题，但非要重定向请求一次就导致单纯的多实例时会存在问题】

6. 相关 Provider

  1. OAuth2LoginAuthenticationProvider

    1. 对OAuth2LoginAuthenticationToken尝试认证，其内会进一步构造OAuth2AuthorizationCodeAuthenticationToken，然后调用 OAuth2AuthorizationCodeAuthenticationProvider 对其进行认证。
    2. 经过上述认证后拿到填充了 "access_token" 的OAuth2AuthorizationCodeAuthenticationToken，会构造成OAuth2UserRequest后传给OAuth2UserService负责进行实际的 "user-info-uri" 请求，并将结果包装成DefaultOAuth2User返回。（该User拥有两类authorities，一个是ROLE_USER（Spring在经过oauth2UserService时手动添加的），一类是Token中的SCOPE_{sopces}）

  2. OAuth2AuthorizationCodeAuthenticationProvider
    对OAuth2AuthorizationCodeAuthenticationToken尝试认证，内部会构造对"token-uri"的实际请求，并调用DefaultAuthorizationCodeTokenResponseClient进行请求返回，并根据返回结果OAuth2AccessTokenResponse（内含access_token/refreash_token），新new一个填充了"access_token"的OAuth2AuthorizationCodeAuthenticationToken返回。

四、oauth2ResourceServer

1. 概述

由 org.springframework.boot:spring-boot-starter-oauth2-resource-server 引入，提供对请求中携带token校验解析、身份认证的服务。

2. 必须的配置

3. 相关 Filter

4. 相关 Authentication

  1. BearerTokenAuthenticationToken
    代表原始token的一个过渡身份。
  2. JwtAuthenticationToken
    其authenticated=true，进行实际系统访问的身份。由BearerTokenAuthenticationToken认证后，通过JwtAuthenticationConverter转换而来。

5. 相关 Provider

五、前后端分离实战定制

实际情况中，除了OAuth2登录，我们系统自身也有完整的用户体系，也有按自己业务定制的token构建分发服务。
三方登录仅作为绑定手段，而且在初次三方登录时 往往还需补全信息注册到我们自己的用户体系。

最终实现代码以及效果展示都放在Github上了：spring-security-oauth2-sample

登录流程，大致API流程：

六、后记

从上文也能看出，不得不提 笔者实际用SpringSecurity很多时候宁愿迁出去自己写套Configuer/Filter/Provider…，官方虽提供了很多服务，而且也能看出在尽可能定制化。但背后还是强制耦合引入了太多逻辑，很难与实际业务契合，即便稍有不同在它基础上定制也都需要付出很大代价。这代价不仅指新增代码行数，为了运行稳定 你首先就得彻底清楚它原本引入了哪些逻辑，这就需要大量上手成本。

本文仍存在些许问题，特别是OAuth2AuthorizationCodeGrantFilter的重定向问题，还有与无状态相悖的oauth2AuthorizedClientRepository涉及较少，也没一张清晰流程图，时间关系暂且就这样了。即便要用好也得知其然 知其所以然，笔者撰文也只是尽量往上靠，有什么问题还希望指正讨论。

关于 Spring Security 对 OAuth2 认证服务org.springframework.security:spring-security-oauth2-authorization-server的实现，以及前言提到的 SpringSecurity原理、JWT等等，后面有时间的话也会慢慢更。

标签：OAuth2,请求,Spring,uri,认证,token,ResourceServer,重定向
来源： https://www.cnblogs.com/simpleito/p/15786122.html