一个单点登录系统(SSO)设计

李鹏0 10,806 次浏览

最近在研究设计一个单点登录系统(SSO),这是一个很常见的系统,但我们在功能与体验上有很多深入精细的探究,这里总结记录一下。下文中SSO也指代本系统。

SSO为PC版和移动版各提供多种登录方式,有常规的邮箱账号或手机号登录,有使用新浪、QQ等账号的联合登录,也有使用手机动态口令登录,另 外还针对不同平台也各提供了一些特色登录方式来提升用户体验,比如微信中打开公司的分享链接可以使用微信授权直接登录,而在PC页面则是扫码登录。

现在移动端的App页面,很多都是直接将普通移动版网页内嵌在App中,App扮演着一个浏览器,这样的好处不必多说。因为App原生页面登录方式 的体验优于在App中打开网页再登录,所以我们在App中还保留使用原生页面登录。SSO实现了与App原生登录方式的兼容,可以识别App中用户的 登录状态。另外也可以使用App扫码登录PC版SSO。

下面是一张单点登录的时序图,具体就不再解释了,之前没有接触过的看图也应该可以理解是怎么一回事:

安全与体验

SSO在安全和体验方面都有一些很精细的考量,在保证系统安全性的前提下,最大程序的优化用户体验。
1、全程HTTPS,防止客户端与服务器之间的通信被窃听。
2、设置回调URL设置白名单,客户端子系统接入SSO必须先在SSO登记注册。
3、token一次性有效,且与客户端子系统绑定,使用后立即销毁。
4、为提升用户体验,每IP每天前3次登录,或每个手机号每天第一次发送动态口令,都不需要用户输入验证码。
5、一个验证码重复发送手机动态口令超过3次后失效。
6、等等…

兼容App登录

App的用户登录信息是单独保存在App中的,并没有使用SSO提供的公共登录服务。那么用户通过App访问内嵌网页时,网页是怎么知道用户的登录状态,怎么实现内嵌网页和App登录状态的共享呢?

我们的解决方案是,在App访问内嵌的要求登录的页面PageA时,PageA会302跳转到SSO的登录页面,这个过程都是在App中进行 的,App在访问SSO的登录页面时会在Cookie中加入一个hash值。SSO接收到请求后先判断SSO自身是否处于登录状态,如果没有则拿 Cookie中的hash值去App服务器请求用户ID,在取到用户ID后生成用户登录信息,再带上token跳转PageA所在系统WebA的回调 URL,WebA重复上面的登录过程就可以登录了。如果hash值为空或者根据hash值从App服务端取回的用户ID为空,则跳转到一个用于被App劫 持的URL,在App完成登录后再重复上述流程。

App在Cookie中设置一个hash值而不是直接设置用户ID,是为了安全考虑,SSO自己调接口从App服务端取回的用户ID才能保证合法性,才是值得信任的。
时序图如下:

扫码登录

扫码登录是现在很流行的一个做法,用户已经在自己的手机或其它移动设备一直处于登录状态,而且这是值得信任的,用它来为PC版登录提供一个快捷方 式,简单快捷体验好,用户不需要再输入冗长复杂的可能用户自己都记不住的密码。所以这种登录方式也是我们必须提供的,虽然现在还没有正式发布上线,但早已 经规划设计。
具体的实现方式是,SSO服务器先随机生成一个不会冲突的code存入数据库,并将它绘制成二维码图片显示在PC版登录页面,页面使用 Javascript短轮询的方式向服务器查询这个code的对应的登录信息。App使用内置的扫码功能识别出图片中的code,然后通过App服务端将 code和上文提到的用户登录信息的hash值作为参数请求SSO接口。SSO收到请求后先判断这个code在我们数据库中是不是存在,存在则表示请求合 法,然后再以hash值请求App服务器获取用户ID,后面的流程就是上文的与App登录连通差不多了。JS轮询到用户已登录后刷新页面,或者从哪里来就 跳转回哪里去。

最后,SSO其实不仅仅提供统一登录服务,还集成用户注册、密码找回等功能,所以称之为通行证系统更合适一点,是公司内稳定性和安全性等方面要求最高的系统。


发表评论

? razz sad evil ! smile oops grin eek shock ??? cool lol mad twisted roll wink idea arrow neutral cry mrgreen