SpringSecurity5-教程3-oauth2登录源码分析

基于用户名密码登录的demo实现oauth2授权码登录！

demo下载

配置解释

http.authorizeRequests()         .mvcMatchers("/login").permitAll() //放行login请求         .anyRequest().authenticated()//代表其他请求需要认证         .and()         .formLogin()//配置表单认证         .loginPage("/login")//用来指定自定义登录界面，不使用SpringSecurity默认登录界面  注意：一旦自定义登录页面，必须指定登录url         .loginProcessingUrl("/doLogin")//指定处理登录的请求url         .and()         .oauth2Login() // 开启oauth2登录         .loginPage("/login") //不使用默认的oauth登录页面，否则无法密码登录         .successHandler(oauth2AuthenticationSuccessHandler)         .and()         .csrf().disable(); //禁止csrf 跨站请求保护

源码分析

1. 访问根路径，重定向到登录页

在FilterChainProxy如下打断点：

浏览器访问：http://localhost:8035/

进入断点，观察过滤器：

可知多了两个Filter:

OAuth2AuthorizationRequestRedirectFilter ：重定向过滤器，即当未认证时，重定向到登录页

OAuth2LoginAuthenticationFilter：授权登录过滤器，处理指定的授权登录

而且在UsernamePasswordAuthenticationFilter之前；

debug放行直到进入OAuth2AuthorizationRequestFilter:

因为当前请求根路径。并非授权登录请求，因此继续执行后续Filter；

debug放行进入OAuth2LoginAuthenticationFilter：

首先执行方法requiresAuthentication判断当前请求是否需要当前AuthenticationFilter执行认证：

可知OAuth2AuthenticationFilter处理的请求是/login/oauth2/code/，因此返回false：

不需要当前Filter执行认证，因此继续执行后续Filter:

直到现在，其实新加入的两个Filter都没有起作用，后续流程就是认证为匿名用户，授权校验抛出AccessDeniedExcepiton，然后ExceptionTranslateFilter处理重定向到登录页。

2. 点击gitee登录，页面重定向到gitee授权登录页面

提前打开https://gitee.com/，如果已登录，请先退出登录。

保持FilterChainProxy断点，点击gitee登录，请求 /oauth2/authorization/gitee

进入断点：

debug放行，直到进入OAuth2AuthorizationRequestRedirectFilter ：

判断是否是授权登录请求，进入resolve方法：

进入resolveRegistrationId：

pattern是/oauth2/authorization/{registrationId}，因此可解析出registrationId是gitee

继续执行getAction方法：

请求中没有action参数，返回默认的：login

debug下一步，进入resolve：

denbug下一步，发起重定向：

首先执行saveAuthorizationRequest方法，即保存本次请求相关的信息，以用于三方平台回调时可以再次获取，例如当回调时需要检查state参数是否一致，以保证安全；

进入sendRedirect方法：

debug放行，后续Filter不被执行，页面渲染授权登录页面（如果浏览器已登录过gitee将不会出现以下页面，而是直接进行回调，因为已登录啦）：

3. gitee登录完成后回调完成认证，并响应信息

首次gitee授权登录时还需要确认授权，之后不会再出现该步骤；

保持FilterChainProxy断点，gitee登录和确认授权后，进入该断点：

当前请求是/login/oauth2/code/gitee，就是gitee回调请求，debug放行进入OAuth2LoginAuthenticationFilter：

同样先执行抽象父类AbstractAuthenticationProcessingFilter的判断是否需要执行认证的方法requiresAuthentication：

pattern是/login/oauth2/code/*，当前回调请求的url是/login/oauth2/code/gitee，因此匹配，开始执行认证：

进入OAuth2LoginAuthenticationFilter.attemptAuthentication方法:

可以看到回调请求中包含授权码code和state两个参数；

在removeAuthorizationRequest方法中根据state参数从会话中查询授权登录之前保存的请求对象（请求对象也有state参数），如果找不到则抛出异常：AUTHORIZATION_REQUEST_NOT_FOUND_ERROR_CODE

意思就是这次授权回调和当前会话无关，为了安全，有可能是黑客乱搞的链接被用户误点了，因此这里直接抛出异常；

继续执行：

构造认证请求，然后使用工厂模式执行认证，这个和用户名密码认证是一样的：

进入authenticate方法，并debug放行到下图断点：

可知处理OAuth2LoginAuthenticationToken的provider是OAuth2LoginAuthenticationProvider，进入：

debug放行：

这里会将OAuth2AuthenticationToken保存到SecurityContextHolder中，以使得SecurityContextPersistenceFilter能持久化到会话中，

可发现该认证结果包含了大量gitee用户信息，这和密码登录后认证为本地用户是不同的，本地用户可能有id等信息，gitee的id和本地用户的id不同；因此如果Controller中获取该Authentication对象后还需要做转换以匹配本地用户，这是不方便的，因此可以自定义认证成功后处理器中完成用户匹配：

handler中也使用了工厂模式，以支持不同授权登录方式对应不同的用户匹配方法；

debug放行，Controller返回当前认证信息：

4. 使用SavedRequestAwareAuthenticationSuccessHandler可实现回调原始请求

重启浏览器，访问localhost:8035/test，跳转登录页，使用gitee授权登录后，页面会重定向到localhost:8035/test

但是当前后端分离时，通过默认的SavedRequestAwareAuthenticationSuccessHandler就不能实现重定向到原始请求了。