微服务系列（四）单点登陆问题

微服务系列（四）单点登陆问题

分布式系统中单点登陆问题是一个非常常见的问题，开发者经常需要面临不同系统或模块需要不同的认证，而某些场景下，用户只需要一次登陆，即可访问跨模块、系统的服务。

ps.分享基于spring boot2.0.x、spring cloud Finchley.SR2

一次Oauth 2.0的使用经历

由于项目采用了Spring Cloud全家桶来构建底层服务，Spring框架具备良好的抽象能力，在认证方法也提供了解决方案，因此使用了Oauth 2.0来构建项目的服务认证中心。

spring security对权限控制的抽象非常好，用户可以无缝接入自己的实现：

例如：

可以自己实现基于redis存储的CustomTokenStore

可以自己实现基于jvm缓存+redis+mysql的用户信息获取服务CustomUserDetailsService

可以自己实现基于jvm缓存+redis+mysql的客户端信息获取服务CustomClientDetailsService

可以自己实现自定义的令牌校验逻辑（用户名密码组合、静态加密字符串等）的CustomAuthenticationProvider

可以自己实现自定义的密码加码器PasswordEncoder

而spring security已经提供了几乎完善的各种默认组合方案，JwtTokenStore、JdbcUserDetailsManager或LdapUserDetailsManager、JdbcClientDetailsService、BCryptPasswordEncoder，配合抽象层的模板代码的处理，用户非常轻松就能实现一套健壮性、扩展性强的认证服务。

首先，“/login”作为登陆的入口，应该跳过认证，如果“/login”不跳过，岂不是死循环了吗？就好比”你工作经验太少了“和“你为什么不工作？”

通过继承WebSecurityConfigurerAdapter配置WebSecurity

可以看到，配置了登陆静态页面的相对路径、authenticationDetailsSource、authenticationFailureHandler、authenticationSuccessHandler、customLogoutSuccessHandler。

authenticationDetailsSource是一个抽象的认证对象，用于给用户扩展并实现认证需要交互的对象或内容，这里的实现则是增加了验证码的处理，将cookie中的验证码读到request请求中，以便后续验证的处理逻辑。

而对于authenticationFailureHandler、authenticationSuccessHandler、customLogoutSuccessHandler就不做介绍了，它们是用于验证失败或成功后的处理逻辑，可以实现以下功能如：多次验证失败锁定ip、控制同一账户验证间隔等。

接着进行配置认证服务配置

通过继承AuthorizationServerConfigurerAdapter配置AuthorizationServer

可以看到：

使用JdbcAuthorizationCodeServices作为授权码模式服务的实现，在关系型数据库中保存授权码模式服务所需信息。

使用了自定义tokenStore作为令牌存储实现，这里基于redis存储了token信息。

使用了自定义userDetailsService作为用户信息获取服务，依然是存储在数据库中，但额外做了一些业务上的处理。

使用了自定义authenticationManager来处理用户登陆逻辑，其本质是在内部维护了ProviderManager，并调用ProviderManager下的AuthenticationProvider.authenticate()逻辑，所以这里实际上是自定义实现了CustomAuthenticationProvider。

完成配置，由于已编写好登陆页面等自定义逻辑，一个能提供基本认证功能的定制化的认证服务开发完成了！

小结

由于spring security作为框架，为了适应大多数场景，其复杂度是很高的，代码量也是非常多，要想灵活运用，不仅需要结合官网的介绍，还需要阅读大量的源码和思考。

简言之，如果系统的认证服务器后期不会再做一些大的变动的情况，其实是不太适合使用spring security框架的，一般而言，对于业务单一的公司，可以根据自身情况构建一套扩展性较高的认证服务，而对于业务种类多的场景、认证服务器可能在未来存在未知变动的情况，则应该使用spring security这样扩展性高的框架来构建自身的认证服务器。