SpringCloud进阶（4）–OAuth 2.0 实现单点登录

SpringCloud进阶（4）–OAuth 2.0 实现单点登录

在之前的文章中，我们曾学习过，使用Redis作为缓存，去存放session来实现分布式session，以此完成不同服务间的分布式权限校验。实际上我们称这种登录模式为多点登录。

但这样实现也存在几个问题：

• 服务间调用障碍：就如前面文章中的借阅服务为例，如果我们直接使用分布式Session，就会发现借阅服务报错，因为借阅服务需要请求book服务和user服务，而两者又需要cookie来进行验证，显然，会存在报错。即在一个服务上登录，并不能保证可以访问其他方法。
• 验证系统冗余：使用分布式session验证同时存在一个问题–每个服务都有自己的验证模块，但实际上，这个系统是存在冗余的。

那么能否实现只在一个服务进行登录，就可以访问其他服务的方法呢？

这里我们可以使用OAuth 2.0单点登录实现基于三方应用的访问用户信息权限。

四种授权模式

1.客户端模式

这是最简单的一种模式，我们可以直接向验证服务器请求一个Token，服务器拿到这个令牌后，经过验证才能去访问资源，这样所有服务都能知道我们是否成功登录了：

虽然这种模式比较简便，但是已经失去了用户验证的意义，压根就不是给用户校验准备的，而是更适用于服务内部调用的场景。

2.密码模式

密码模式和客户端模式类似，就是多了用户名和密码信息，用户需要提供对于账号的用户名和密码，才能获取到token：

3.隐式授权模式

首先用户访问页面时，会重定向到认证服务器，接着认证服务器给用户一个认证页面，等待用户授权，用户填写信息完成授权后，认证服务器返回Token。

它适用于没有服务端的第三方应用页面，并且相比前面一种形式，验证都是在验证服务器进行的，敏感信息不会轻易泄露，但是Token依然存在泄露的风险。

4.授权码模式

这种模式是最安全的一种模式，也是推荐使用的一种，比如我们手机上的很多App都是使用的这种模式。

相比隐式授权模式，它并不会直接返回Token，而是返回授权码，真正的Token是通过应用服务器访问验证服务器获得的。在一开始的时候，应用服务器（客户端通过访问自己的应用服务器来进而访问其他服务）和验证服务器之间会共享一个secret，这个东西没有其他人知道，而验证服务器在用户验证完成之后，会返回一个授权码，应用服务器最后将授权码和secret一起交给验证服务器进行验证，并且Token也是在服务端之间传递，不会直接给到客户端。

这样就算有人中途窃取了授权码，也毫无意义，因为，Token的获取必须同时携带授权码和secret，但是secret第三方是无法得知的，并且Token不会直接丢给客户端，大大减少了泄露的风险。