SSO with CAS, OpenID or OAuth

近来又开始了我的实验架构之路,在Rails中,尝试性的利用Engine将项目分离成多个子项目,当处理用户验证时出了点问题,Devise无论怎么配置都会出现问题,由此引发一系列的思考,不关Devise,而是单点登陆和开放平台授权等多方面。

需求如下,以新浪为例:

Sina有很多内部应用,如Mail, Game,加上现在的Weibo等等,但它只会保证有一个用户中心,所有的用户注册都在该处进行,当其它应用需要对用户进行身份验证时,也将用户带到该处,也就是通常所说的SSO,中文翻译单点登陆,这样一来,当用户在该处实现验证完成后,其它应用就可以直接取得用户信息,对于一个大型多应用的网站,这看起来是必备的。

但后来SNS的兴起,其基因就是充满着开放,作为代表Weibo也为大家开放着自己的一些API,通过这些开放接口,开发者就可能做出更帅更好玩的应用。我们称开发者的应用为第3方应用。有时,Sina Weibo自己也会基于这些API来做一些应用,如手机客户端,PC客户端。这样如何对应用程序进行授权也是开放平台面对的一个问题。

在开放的世界里,越是常见的复杂问题往往会越简单,因为总会有人来做出好的解决方案。这里我们要看到的就是CAS, OpenID, OAuth 2.0。这三个名字代表的分别是三样东西,但往往因为理解上的不清楚,很多人都在用错着它们。

CAS是一个SSO的开源解决方案,由耶鲁大学发起,致力于解决大型网站的单点登陆问题,它要解决的是,多个网站,在其中一个指定的服务器上登陆,再访问其它网站时就已自动登陆。

OpenID则是用来验证。网站越来越多,每个上面注册一下都会有不同的名字或不同的密码,记起来特烦,能不能用同一个名字来登陆这所有的网站,这就是OpenID的目的,提供OpenID的服务商存有你的个人信息,然后当用户有验证需求时,应用程序就可以直接去服务商处取得用户信息。Google,Facebook都提供这样的服务。

OAuth则是用来授权的,在开放的SNS中,当第三方程序想访问你的数据,比如说我下载了一个第三方的很漂亮的微博客户端,而该程序如果想对我的数据进行操作,比如读我的好友列表,发新的微博。就需要Weibo平台对该程序授权,这就是OAuth要做的。

很简单,但事实上很多人都在错用这些东西。

TukeQ作为创新工厂投资的网站,当你进入时,会有注册的提示,再点进去,会发现只有一个选项:用新浪微博登陆,然后会有新浪的授权提示。

这是最错误的一种应用了。这里应该用的是OpenID,结果却不小心用成了OAuth。本来是应该只提供用户信息给第三方TukeQ,结果现在把操纵个人微博数据的权利都交给了该第三方应用。经典的说法是,你本只需要将身份证出示给快递人员,结果不小心把家里钥匙都给了快递人员。可怕的错误应用场景。

明天继续从应用场景方面来讲述这几种开放协议和产品。