很早的时候就有人发明了 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 不提供 Email 信息，所以如果用 twitter 登录的话，还要你输入 email. 因此 Quora 并不依赖第三方认证，它只是让用户把账户跟 Facebok/Twitter 连接起来，好利用它们扩大影响。即使 twitter 几年以后不存在了，也不影响用户在 Quora 登录。
如果我的网站要依赖第三方的用户认证，也应适当地要一些多的权限，好利用这些 SNS 的力量。归根结底，它们的 API 就是为了这个设计的，并不只是用户认证。
Leave a Reply