1.应用前提
1.1 分布式用户登录问题
微服务架构下的第一个难题便是数据同步,单机版的Session
在分布式环境下一般不能正常工作,为此我们需要对框架做一些特定的处理。
首先我们要明白,分布式环境下为什么Session
会失效?因为用户在一个节点对会话做出的更改无法实时同步到其它的节点, 这就导致一个很严重的问题:如果用户在节点一上已经登录成功,那么当下一次的请求落在节点二上时,对节点二来讲,此用户仍然是未登录状态。
假设我们的系统被切割为N个部分:商城、论坛、直播、社交…… 如果用户每访问一个模块都要登录一次,那么用户将会疯掉, 为了优化用户体验,我们急需一套机制将这N个系统的认证授权互通共享,让用户在一个系统登录之后,便可以畅通无阻的访问其它所有系统。
单点登录——就是为了解决这个问题而生!
简而言之,单点登录可以做到:在多个互相信任的系统中,用户只需登录一次,就可以访问所有系统。
1.2 解决方案
- Session同步:只要一个节点的数据发生了改变,就强制同步到其它所有节点
- Session粘滞:通过一定的算法,保证一个用户的所有请求都稳定的落在一个节点之上,对这个用户来讲,就好像还是在访问一个单机版的服务
- 建立会话中心:将会话信息存储在专业的缓存中间件上,使每个节点都变成了无状态服务,例如:
Redis
- 颁发无状态token:放弃Session机制,将用户数据直接写入到令牌本身上,使会话数据做到令牌自解释,例如:
jwt
- 方案一:性能消耗太大,不考虑
- 方案二:需要从网关处动手,与框架无关
- 方案三:Spring-Session
- 方案四:Spring-OAuth2.0
2.什么是OAuth2.0
简单来讲,OAuth2.0 的应用场景可以理解为单点登录的升级版,单点登录解决了多个系统间会话的共享,OAuth2.0 在此基础上增加了应用之间的权限控制。
OAuth2.0 可以解决分布式环境下的统一认证授权,我们要学习的是 Spring 推出的 Spring-Oauth2.0 框架,可以完美的和 SpringBoot 以及 SpringCloud进行整合,而不需要复杂的配制,在学习前最好已经了解学习了 SpringSecurity 的使用,因为SpringSecurity和SpringOauth2 一般是一起使用的,SpringOauth2 包含 SpringSecurity,所以很多配制都需要结合SpringSecurity来完成。
OAuth(开放授权)是一个开放标准,允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息,而不需要将用户名和密码提供给第三方应用或分享他们数据的所有内容。
比如在用户登录时,经常采用的第三方登录的方式,如:微信登录、QQ登录、微博登录等,这些都是基于Oauth2.0 协议来实现的认证授权过程。
相关名词:
- Resource owner(资源拥有者):拥有该资源的最终用户,他有访问资源的账号密码;
- Resource server(资源服务器):拥有受保护资源的服务器,如果请求包含正确的访问令牌,可以访问资源;
- Client(客户端):访问资源的客户端,会使用访问令牌去获取资源服务器的资源,可以是浏览器、移动设备或者服务器;
- Authorization server(认证服务器):用于认证用户的服务器,如果客户端认证通过,发放访问资源服务器的令牌。
2.1 Auth2.0 四种授权模式
- Authorization Code(授权码模式):正宗的OAuth2的授权模式,客户端先将用户导向认证服务器,登录后获取授权码,然后进行授权,最后根据授权码获取访问令牌;
- Implicit(简化模式):和授权码模式相比,取消了获取授权码的过程,直接获取访问令牌;
- Resource Owner Password Credentials(密码模式):客户端直接向用户获取用户名和密码,之后向认证服务器获取访问令牌;
- Client Credentials(客户端模式):客户端直接通过客户端认证(比如client_id和client_secret)从认证服务器获取访问令牌。