技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 系统架构 --> 使用第三方网站作为用户认证系统

使用第三方网站作为用户认证系统

浏览:2161次  出处信息

    很早的时候就有人发明了 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,就好像一个人的名字、身份证号码一样。有一些选择:

  • Facebook ID 是一个号码,在 Facebook 的用户系统中是绝对不会重复的
  • 申请授权的时候,同时申请得到用户 email 的权限。email 也是一个非常合适的 ID,甚至比 Facebook ID 还好,因为它在 Facebook 之外也是唯一的。
  • Stack Overflow 的身份认证

        上面也提到了,一旦确认身份之后,还是用 cookie 作为临时通行证。我们可以把 Facebook ID 或者 email 放在 cookie 里,同时放一个 hash 来保证它的真实性。Stack Overflow 就是一个很好的例子,我觉得它是使用 email 作为 ID 的,可以这么来验证这一点:

  • 确保你的 Google/Facebook 账户使用的 email 地址是一样的
  • 通过 Google 登录 Stack Overflow,创建账户
  • 退出登录,然后用 Facebook 重新登录
  • 这时候你就看到,进入了刚才通过 Google 登录创建的账户了!
  •     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 就是为了这个设计的,并不只是用户认证。

    建议继续学习:

    1. python实现自动登录discuz论坛    (阅读:31573)
    2. 微信扫码登录网页实现原理    (阅读:15584)
    3. 初探单点登录 SSO    (阅读:9283)
    4. 你会做Web上的用户登录功能吗?    (阅读:5566)
    5. 如何设计用户登录    (阅读:5481)
    6. perl的expect使用方法,实现非交互式登录。    (阅读:4479)
    7. 如何让ssh登录更加安全    (阅读:4472)
    8. 什么是OpenID?OpenID概念、原理和案例    (阅读:4266)
    9. 互联网上的单点登录研究    (阅读:3989)
    10. 为什么要登录?    (阅读:3905)
    QQ技术交流群:445447336,欢迎加入!
    扫一扫订阅我的微信号:IT技术博客大学习
    © 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

    京ICP备15002552号-1