统一认证中心-auth2.0

背景

随着微服务架构的兴起，模块之间细分力度更小。许多公司将单点登录会做成一个统一的微服务平台。但是一旦抽象出一个单独的微服务平台之后，就会涉及到如下问题：（1）接入方在不同的域名，会涉及到跨域问题；（2）安全问题，整个登录接口全部暴露给所有的接入方，存在一定的数据泄露等问题。本片文章主要是介绍当前较通用的一种单点登录认证协议Auth2.0。

SSO单点登录介绍：

单点登录（SSO）：传统的多点登录方式对于站点都会开发一套登录系统和用户数据维护系统，同时不同的站点整个用户的数据维护在其自己数据库中，无法共享用户数据。单点登录是体统统一的登录和权限验证逻辑。同时整个用户数据统一管理，很大程度降低工作量。如下图，图一为传统的登录方式，图二为SSO单点登录。

传统登录方式

SSO登录

Auth2.0协议

下图是Auth2.0协议时序图

时序图

 

步骤介绍

（1）用户通过浏览器访问第三方应用后端资源，第三应用会判断用户是否登录。第三方应用从请求头或者cookies中获取登录app_token标识，验证是否登录。由于第三方不保存用户数据和登录的相关信息，其需要请求验证服务器，判断当前app_token是否有效。如果失效，则需要告知浏览器用户未登录。--------登录拦截

（2）浏览器收到第三方应用接口返回的未登录标识时，则浏览器自动重定向到用户登录页面。注意，此处的登录页面应该有登录验证服务器提供。用户输入密码和账号，验证服务器验证通过，返回浏览器登录验证通过标识token。-------账号验证

（3）由第二步账号验证通过之后，根据返回的token和从第三方应用给的appkey获取应用登录授权码。验证服务器根据token和appkey计算出相应的应用授权码auth_token。

（4）获取到应用授权码之后，浏览器重新回到第三方应用页面，由auth_token请求第三方后台登录，注意此处不再是用户账号和密码登录了，是通过授权码请求第三方应用后端服务器。第三方后端服务器根据auth_token和appkey对应的密钥，请求验证服务器获取应用登录凭证app_token并且返回给浏览器。

（5）浏览器获取到应用登录服务器登录凭证app_token进行保存，请求原先开始的页面，后端接着验证app_token,验证通过，返回后端响应的资源。

设计时疑惑介绍

（1）在（2）中获取到一个token之后，我们完全可以直接将此token作为应用登录凭证，为何还要通过授权码方式获取应用登录token？

用户在传递token时，一般是通过浏览器的url方式传递，大部分场景都是直接放在浏览器后面的url参数，这样直接将token暴露出来，如果被截取了是非常危险的事情。

如果有多个应用，如果直接用登录返回的token，则会涉及到权限的问题，不同的应用应该有自己专属的token，降低各应用直接的耦合性。

（2）为何获取应用登录凭证app_token时，还有一个密钥参数？

由于授权码是通过显示的暴露在url后面，容易被截取，如果auth_token被截取并且知道了通过auth_token 获取应用登录凭证接口，导致整个用户信息被盗用和泄露。因此，在获取app_token时，需要一个密钥参数，这样即使auth_token被获取到了，由于劫持人缺少密钥，是无法获取的到用户信息。