背景

最近，公司的标准B端产品，遇到了两个客户的定制化需求：

1.A客户公司要求产品需要集成他们的单点登录，客户还提出来，他们今年没有这方面的预算，要求自己在我们的源码基础上二开。

2.B客户公司说他们集团有要求，产品都需要集成双因子认证登录的功能，同样他们登录也要求接入他们的用户中心。

我们的产品登录认证是基于# SpringSecurity+OAuth2.0。

看起来登录认证，接入客户的用户中心这个场景在安全的大背景下，是一个普遍的需求场景了，遂纳入了迭代版本，同时考虑到后续版本升级及维护成本，进行统一的设计，留好接口，做到良好的代码隔离及扩展。

我的工作思路

1.接到这种需求，首先第一考虑的当然是搜索，github上找现成方案，hahah，没错，面相搜索的编程原则不能丢，用经过别人实践的方案，或者是这个模块的通用解决方案，不用自己想歪招~

2.当我查了半天，发现S# SpringSecurity+OAuth2.0原理解释的文章一大堆，但是真正关于这两个需求相关的方案很少，仅有的几篇要么写的不清楚，要么不是我想要的，无奈还是得自己调研，做方案设计。

tips：
SpringSecurity+OAuth2.0我只是以前作为学习了解过，最多写过demo，之前没有负责过登录模块，并且好几年了，也只是了解写概念和基本流程，并不足以支撑我进行方案设计和基SpringSecurity+OAuth2.0的改造。那就只能重新回顾原理去了。

这里为什么说不足以支撑我做方案设计呢，我个人认为SpringSecurity+OAuth2.0的方案，框架封闭程度太高了。

几个概念

1.OAuth2.0

2.SpringSecurity+OAuth2.0

3.单点登录

这几个概念比较普遍了，不知道的也可以网上搜一下，都写的比较透彻了。

4.双因子登录可能有些人不太清楚，这里重点说一下：

其实这也不是新概念了，早年的银行U盾+用户名密码也是双因子的一种。 就举个现在C端常用的例子吧：

正常你可能用户名+密码就完成了登录，但是当你某一天去外地出差，在输入用户名密码后，跳转到了另一个页面要求你用短信验证码做二次认证，大概就是这么个场景。概括的说：在系统基于大数据识别到风险或者异常行为，开启第二种登录认证方式。

谈谈我的设计方案

根据需求背景，那我希望的是：

1.三方登录集成：
SpringSecurity的用户名密码认证，可以基于策略模式，来实现。（基于本地的密码认证策略，三方接口接入的）

2.双因子登录：
在用户请求登录时，增加预校验接口，先校验是否需要双因子认证，如果不需要，则直接加载密码授权模式办法token，如果需要，则先不能办发token，再增加一个自定义的grant_type，来进行短信验证码的授权模式，并颁发token。

目标出发，再看oauth2.0的工作及实现原理

由于原来的实现是授权码模式（authorization code），那我们来看他的工作流程及原理：
我们画出他的时序图:

集成三方登录

从上述时序图来看，这个需求，我们关键是关注下述这个地方：

他的密码认证的核心逻辑在DaoAuthenticationProvider类的additionalAuthenticationChecks方法

接下来，我决定重写该类的additionalAuthenticationChecks方法，这样就能满足我的想法，同时原来的代码结构不用破坏，权限等的加载逻辑也都不用动。

我的具体实现方案

自定义重写additionalAuthenticationChecks方法

基于策略模式实现不用认证方式的加载

加载自己的CustomLoginAuthProvider

SecurityConfigurer中加入自己的configure

tips: 这里有个小坑，mark一下，我还查了好就：

双因子登录

还是根据调用的时序图来看：

关于授权类型 grant_type 的解析

1.每种 grant_type 都会有一个对应的 TokenGranter 实现类。
2.所有 TokenGranter 实现类都通过 CompositeTokenGranter 中的 tokenGranters 集合存起来。
3.然后通过判断 grantType 参数来定位具体使用那个 TokenGranter 实现类来处理授权。

关于授权登录逻辑

1.每种 授权方式 都会有一个对应的 AuthenticationProvider 实现类来实现。
2.所有 AuthenticationProvider 实现类都通过 ProviderManager 中的 providers 集合存起来。
3.TokenGranter 类会 new 一个 AuthenticationToken 实现类，如 UsernamePasswordAuthenticationToken 传给 ProviderManager 类。
4.而 ProviderManager 则通过 AuthenticationToken 来判断具体使用那个AuthenticationProvider 实现类来处理授权。
5.具体的登录逻辑由 AuthenticationProvider 实现类来实现，如 DaoAuthenticationProvider。

基于以上我这里实现了单独的SmsGranter