|
在最近的五年间，复合应用程序已经从新奇的事物变成了主流。在构建复合应用程序时，关键的架构问题之一就是在访问特定服务的时候需要双重认证，以及相关的认证规则： 一般，我们需要对触发服务的（复合）应用程序和复合应用程序本身的用户进行认证，同时还要能够为应用程序和用户定义服务访问规则。这在客户端/服务器中间件环境中尤其困难，包括HTTP环境，因为多年以来它们构建的前提就是“客户端”只会表现为单一的标识：或者是软件客户端，或者是用户，而不能二者都是。 现在典型的复合应用程序会使用流行的API（像Twitter、Facebook或者Google），通过这些API它会请求对用户特定的数据进行访问。之前，复合应用程序的开发者需要了解针对每项服务的用户证书，那样才能够访问他们的数据并以字母顺序的方式将它们混合在一起。Jeff Altwood曾经用一种情况与这个过程做过比较，那种情况是和某人要房间的钥匙，目的只是要获得通讯簿。2007年四月，一小组人创建了OAuth项目，初始成员包括Blaine Cook、Chris Messina、Larry Halff 和David Recordon。 OAuth是位于HTTP和HTTPS上层的协议，它让复合应用程序和服务的用户都可以为服务和应用程序赋予部分访问权限。它基于第三方的信任联盟：用户-应用程序、用户-服务和应用程序-服务。 这个组织很快就发布了OAuth 1.0规范，人们也开始使用它。OAuth 1.0可能发布地太快了，因此广受批评。之后很快就出现了与之竞争的WRAP（Web资源授权协议），它很快地进行了标准化，成为OAuth的对手。从那时开始，OAuth工作小组就开始着手创建OAuth 2.0。 OAuth最明显的便利性在于，Twitter在本月（2010年9月）决定对访问它的API实行强制认证，然后不再支持基本的认证方式。Michael Calore解释说： Twitter的这个举措反映出在社会化网络的更广泛的趋势，其中当服务和应用程序与用户的账号连接的时候，基本的认证需要扩展为更安全的OAuth。 包括iCodeBlog在内的很多网站都提供了教程，帮助开发者快速地更新他们的应用程序。并且，即便OAuth还处于草稿阶段，它已经得到了Facebook的支持，它已经预定是OAuth协议最大的实现者，并且是该规范的关键利益相关者。 看起来这次业界已经对解决这个重要的问题达成了广泛的共识。然而，OAuth 2.0的一位制定者，同时也是OAuth早期的贡献者Eran Hammer-Lahav突然离开了这个工作组，并在离开之前发布了关于这个规范的最新方向的批评意见，认为规范因为“不记名的令牌（bearer tokens）”而放弃了数字签名和加密。然而，Eran自己也承认，“加密是不可原谅的”。开发者很容易在对消息加密或者签名的步骤中犯错，并且一般这是不可原谅的错误。放弃加密是WRAP的初始想法的一部分： 在WRAP架构的核心有一种需求，就是要从客户端移除所有加密。WRAP的作者发现，开发者因为OAuth 1.0中的数字签名而痛苦挣扎，他们的结论是，完全放弃数字签名是最好的解决方案。取而代之的是，他们决定依赖于已经得到验证的并且广泛可用的技术：HTTPS（或者更准确地说是SSL/TLS）。如果开发者可以在他们的请求中添加一个字符（将http://更改为https://）就可以保护自己的秘密不被窃听者得到，为什么要使用数字签名呢？后续的批评大多是集中于WRAP并非真的需要HTTPS上。这只是提供了一种选择。 这种对没有秘密的令牌或者其它验证机制的使用被叫做不记名令牌（这与cookie类似）。所有持有令牌的人都会获得访问权限。如果你是攻击者，那么只需要持有这个简单的字符串，就可以来去自如。不需要任何数字签名、计算、反向工程，或者类似的方法。 这个模型的支持者的观点如下： 既然大多数服务都使用基于cookie的认证系统，那么使用额外的机制也不会更安全，因为攻击者总会把目标定在最脆弱的地方。实际上，Eran的担心不是关于当前的OAuth的，而是关于这个规范将在五年之内所产生的影响，那时肯定会需要更安全的协议。首先，论点再次提到，由于OAuth 2.0是最脆弱的环节，就没有必要实现更强壮的安全机制。其次，OAuth能够在当前的环境中工作的原因就在于，所有API都针对客户端做了很好的签名，并且大多数API终端都是在客户端代码或配置中静态声明的，在应用程序发布之前都得到了彻底的测试。因此总的来说，几乎没有将这个令牌发送到不友好的目标站点的风险。 《RESTful Web Services Cookbook》一书的作者Subbu Allamaraju在个人笔记中写到： 如果客户端应用程序向错误的地址发送请求（比方说“mail.exmple.org”而不是“mail.example.org”），位于“mail.exmple.com”恶意服务器就会得到客户端的访问令牌，并可以访问它的邮件。当然，对于浏览器的情况，浏览器开发者应该负责不要通过实现相同的原始策略而泄漏cookie。OAuth2.0客户端开发者也有同样的责任。
然而，Eran还是认为Web应该更安全，那样才能够支持更加动态的情况，并且支持通过各种服务实现的标准API的世界： 一旦我们试图通过服务引入可发现或者互操作的API，OAuth 2.0就会出现故障。因为它缺少对令牌的加密保护（没有任何令牌秘密），客户端需要指出向哪里发送令牌才是安全的。OAuth依赖于cookie模型来获得相同的解决方案——让客户端来应用安全策略，并指出和哪些服务器共享它的令牌。当然，资源服务器能够请求任何授权服务器所发布的令牌。例如，受保护的资源可以声称，它需要Google发布的OAuth访问令牌，事实上此时是与Google无关的（即便它可能是Google的子领域服务）。 客户端需要指出，服务器是否被授权能够看到它的Google访问令牌。Cookie拥有关于哪个cookie与哪台服务器共享的规则。但是，因为这些规则是由客户端执行的，所以长久以来的问题是，对cookie的错误共享会产生安全性的故障。对于OAuth 2.0也是一样。 他做出这样的结论： 任何基于客户端执行安全策略的解决方案都会被打破，并出现故障。OAuth 1.0通过支持数字签名来解决这个问题。如果客户端向错误的服务器发送了请求，什么危险的事情都不会发生，因为恶意服务器没有任何方法使用那个错误导向的请求来做任何事。如果客户端向错误的服务器（通过发现找到的）发送OAuth 2.0请求，那台服务器就可以自由访问用户的资源，因为令牌是有效的。 复合应用程序快速成为关键的变革方向，它为简单的数据——像任务、朋友或者TV指南——添加了新的价值。同时，OAuth对快速地采用做出了平衡，因为它解决了严重的问题，并在业界得到了一些动力，比方说Facebook和Twitter对它的支持。 和经常在标准化过程中所发生的一样，我们现在处于十字路口，我们的业界需要选择这条路，或者是那条路：我们是要支持更简单的安全机制，从而让大量开发者能够创建这些复合应用程序呢？还是应该实现更强壮的机制，那会让其他开发者创建更多与现存的服务交互和竞争的服务呢？你站在哪一边呢？ |
|
|
来自： CevenCheng > 《客户端接口》
