基于用户名密码登录的demo实现oauth2授权码登录!
demo下载
| http.authorizeRequests() |
在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处理重定向到登录页。

提前打开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将不会出现以下页面,而是直接进行回调,因为已登录啦):

首次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返回当前认证信息:
重启浏览器,访问localhost:8035/test,跳转登录页,使用gitee授权登录后,页面会重定向到localhost:8035/test

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