使用第三方网站作为用户认证系统
很早的时候就有人发明了 OpenID,希望解决用户在每一个网站都重复注册流程的问题,但是由于种种原因,这个事情好久没什么起色。我曾经也弄过 OpenID,后来发现由于不怎么常用,我连 URL、密码之类的都记不住,还不如在每个网站上都注册一下。从网站的角度看,他们也不愿意把网站的入口交给第三方――这个 OpenID provider 的网站挂了怎么办?直到 Google/Yahoo! 这样级别的作为 OpenID provider 还比较靠谱。第一,它们足够稳定;第二,它们本身就是许多广为使用的服务的提供商,这个也让人可以信赖第一点是成立的,它们从自身利益出发就有足够的理由去保障。到了这个阶段,就不是 OpenID 的成功了,而是 Google/Yahoo! 的成功,或者说第三方登录的成功,选择什么协议已经不重要了。
现在国外许多网站都使用 Facebook Connect,大部分都是为了让自己的用户把 Facebook 账户关联起来,好从 Facebook 拿到用户的数据,或者让用户把本站的信息向 Facebook 发送,利用 Facebook 的巨大社交网络作传播。所以大部分的 Facebook Graph 教程,都在讲怎么往自己网站加个 Facebook Connect 的按钮,如何重定向,如何拿到用户的隐私数据等等。
不过我最近在想做一个新的网站的时候,就想直接依赖第三方的用户认证系统,而不自己实现了。向第三方网站 pull/push 数据只是一个附带产物。以下只是我很粗浅的想法,还没有实现,等将来有了实际经验的话也许再回来更新一下这篇文章吧。
基于 cookie 的用户名密码认证
每个做过网站的都记得一般是怎么用用户名密码做用户登录的。数据库里有一个表来记录用户名和 hash 过的密码,登录时,用同样的算法 hash 提交过来的密码,看跟数据库里的记录是否一致。如果登录成功,创建一个或几个 cookie,里面记录该用户已经登录成功,并且有算法保证这个 cookie 的信息(用户名、过期时间)不是伪造的(许多使用 HMAC 算法)。这样用户下次请求的时候,就不再需要重新提交用户名密码了,直接检查请求中附带的 cookie 即可知道他是谁。
一直遵从这么一个思路,我都快忘了它是干嘛的了。如果一个网站有 UGC,那么很多情况下我们都需要知道访问者的身份。我们所需要的就是身份认证,让用户可以安全地保存他的内容或秘密。
Facebook Connect 作为身份认证服务
使用第三方用户认证的概念就是,以前我们直接问用户要口令,来确定来者是谁,现在转而去一个可信的人(Facebook/Google)那儿去查。一旦查清楚身份,我们就给用户一个临时的通行证(cookie),在一段时间内就不用再要密码或者再去第三方哪里查了。看起来很显然,不过我花了点时间才想清楚这一点。所以现在我们最需要的就是从 Facebook/Google 那儿要一个 ID,就好像一个人的名字、身份证号码一样。有一些选择:
Stack Overflow 的身份认证
上面也提到了,一旦确认身份之后,还是用 cookie 作为临时通行证。我们可以把 Facebook ID 或者 email 放在 cookie 里,同时放一个 hash 来保证它的真实性。Stack Overflow 就是一个很好的例子,我觉得它是使用 email 作为 ID 的,可以这么来验证这一点:
Stack Overflow 在一个名为 "usr" 的 cookie 里保存认证信息,并且 cookie 的有效期是6个月(也许应该加个 "remember me" 的选项吧?)。所以即使退出 Google/Facebook,也不会影响在 Stack Overflow 的登录状态。把这个 cookie 复制到另一台计算机上,然后访问 Stack Overflow,你会发现你已经登录了。
这样做会威胁到 Facebook 账户的安全吗?不会。Facebook 使用的是 OAuth 2.0,authorization code 和 acess code 很快就过期,即使有个人偷到了 cookie,闯入别人的 Stack Overflow 账户,他如果想通过 SO 在 Facebook 做点坏事的话,SO 也需要重新走个流程,获取 authorization code 及 access code。
Quora的身份认证
依赖第三方的登录看起来有点危险,即使是 Facebook/Google,它们也难免有 downtme,这时候用户就无法被认证了。但是如果你得到了用户的 email,将来有一天就可以摆脱 Facebook/Google,让用户在本站建立密码。
Quora 也是个很有意思的例子。比如最初的时候我记得 Quora 是只接受 email 注册的,我就用 gmail 邮箱注册了一个账户。过了很久以后再去登录,发现有了 Connect to Facebook 这么个按钮,就点了。然后发现我进入了原来用 email 注册的那个账户,看起来跟 Stack Overflow 是一样的道理。
不过不一样的地方是,不管你怎么登录,Quora 都要求你在它网站上设立一个密码。Twitter 的 OAuth 不提供密码,所以如果用 twitter 登录的话,还要你输入 email. 所以 Quora 并不依赖第三方认证,它只是让用户把账户跟 Facebok/Twitter 连接起来,好利用它们扩大影响。即使 twitter 几年以后不存在了,也不影响用户在 Quora 登录。
如果我的网站要依赖第三方的用户认证,也应适当地要一些多的权限,好利用这些 SNS 的力量。归根结底,它们的 API 就是为了这个设计的,并不只是用户认证。
建议继续学习:
- python实现自动登录discuz论坛 (阅读:31573)
- 微信扫码登录网页实现原理 (阅读:15584)
- 初探单点登录 SSO (阅读:9283)
- 你会做Web上的用户登录功能吗? (阅读:5566)
- 如何设计用户登录 (阅读:5481)
- perl的expect使用方法,实现非交互式登录。 (阅读:4479)
- 如何让ssh登录更加安全 (阅读:4472)
- 什么是OpenID?OpenID概念、原理和案例 (阅读:4266)
- 互联网上的单点登录研究 (阅读:3989)
- 为什么要登录? (阅读:3905)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:qingbo.blog 来源: qingbo.blog
- 标签: 登录 认证系统
- 发布时间:2011-08-14 15:18:38
- [68] Go Reflect 性能
- [68] 如何拿下简短的域名
- [67] Oracle MTS模式下 进程地址与会话信
- [62] IOS安全–浅谈关于IOS加固的几种方法
- [61] 图书馆的世界纪录
- [60] 【社会化设计】自我(self)部分――欢迎区
- [58] android 开发入门
- [56] 视觉调整-设计师 vs. 逻辑
- [49] 给自己的字体课(一)——英文字体基础
- [48] 读书笔记-壹百度:百度十年千倍的29条法则