SSO单点登录的几种方式

简介

单点登录SSO(Single Sign On)是在一个多系统共存的环境下,用户在一处登录之后,就不用在其他的系统中登录,也就是用户的一次登录能得到其他所有系统的信任.单点登录在大型网站里面使用的比较多,例如像阿里巴巴这样的网站,在万丈的背后是成百上千的子系统,用户一次操作或交易可能涉及到几个十几个子系统的协作,如果每个子系统都需要用户认证,会在无形中增加时间的耗费.实现单点登录说到底就是要解决如何产生和存储那个信任,再就是其他子系统如何验证这个信任的有效性,因此要一下两个点:

·存储信任

·验证信任

--第一种:以Cookie作为凭证媒介

最简单的单点登录方式,使用coo[kie作为媒介,存放用户凭证-----当用户登录父应用之后,应用返回一个加密的cookie,但用户访问子应用的时候,携带这个cookie,授权应用解密cookie并进行校验,校验通过则登录当前用户.

从上面的图我们可以发现,把信任存储在客户端的cookie中,这种方式很容易让人质疑,

--cooki不安全

--不能跨域实现免登

对于第一个问题,通过加密cookie可以保证安全性,当然这是在源代码不泄露的前提下,如果cookie的加密算法泄露,攻击者通过伪造cookie则可以伪造特定用户身份,这是很危险的.对于第二个问题更是硬伤

--第二种:通过JSONP实现

对于跨域问题,可以使用JSONP实现,用户在父应用中登录之后,和Session匹配的cookie会存到客户端中,当用户需要登录子应用的时候,授权应用访问父应用提供的JSONP接口,并在请求中带上父应用域名下的cookie,父应用接收到请求,验证用户的登录状态,返回加密的信息,子应用通过解析返回来的加密信息来验证用户,如果通过验证则登录用户.

--这种方式虽然能解决蛞蝓问题,但是安全性其实跟把信任存储到cookie是差不多的,如果一旦加密算法泄露了,攻击者可以在本地建立一个实现了登录接口的假冒父应用,通过绑定Host来把子应用发起的请求指向本地的假冒父应用,并作出回应.

--因为攻击者完全可以按照加密算法来伪造响应请求,子应用接收到这个响应之后可以通过验证,并且登录特定用户.

第三种:通过页面重定向的方式

最后一种是,通过父应用和子应用来回重定向中进行同行,实现信息的安全传递.

父应用提供一个GET方式的登录接口,用户通过子应用重定向连接的这个方式的访问这个接口,如果用户还没有登录,则返回一个的登录页面,用户输入账号密码进行登录,如果用户已经登录,则生成加密的Token,并且重定向到子应用提供的token的接口,通过解密和校验之后,子应用登陆当前用户.

这种方式比较前面两种方式,解决了上面两种方法暴露出来的安全性问题和跨域的问题,但是并没有前面两种方式方便,安全与方便本来就是一对矛盾.