问：我们组织非常倾向于将OAuth协议集成到我们的Web应用认证架构中，从而同时支持标准的和移动Web应用。使用OAuth协议，特别是用于移动应用时，有什么不利的地方吗？或者还有一些别的原因，我们应该考虑其他方法或联合协议？

　　答：OAuth（Open Authorization，开放授权）协议2.0版本作为一个IETF标准，目前已接近最后的完成阶段。它是一个联合协议，旨在简化对受到保护数据的授权和访问，在授予对数据的访问的同时，保护拥有者的帐户凭证。它允许拥有某个web站点（服务提供商）账号的用户，同意另一个web站点（消费者）从前者访问他/她的数据（允许用户让第三方应用访问该用户在某一网站上存储的私密的资源，而无需将用户名和密码提供给第三方应用。）。用户可以提供令牌而不是凭证（通常是他们的用户名和密码）来共享访问他们位于因特网上的私有资源（如文档、图像和日程表）。令牌可以授予在指定时间内对特定资源的访问，这样一来，用户可以授权第三方访问他们共享的资源，而不需要分享他们的访问许可或他们数据的所有内容。比起为了相互访问数据，用户们互相共享他们的用户名和密码，这个解决方案更好。

　　OAuth 2.0的一个潜在好处是，能够让用户共享关于他们自身身份的可核实的声明，而不必发布任何个人识别信息。允许你的客户将他们的信息与让你的应用系统整合，或通过你的应用从别的站点上共享有关他们的信息，能够极大地提高你的服务，同时，和别的站点一起发挥作用可以降低成本。

　　许多大型网站包括Twitter、Facebook和Google都使用OAuth协议。选择一个备选协议来提供网络上这些大型站点要求的支持水平十分困难，但是OAuth协议不是一个简单的即插即用的技术。当使用OAuth协议时，你需要从想委派的服务获取密钥字符串。在浏览各种博客和论坛中，我获悉开发人员们正努力在移动设备上管理该密钥，因为在应用中存储密钥信息时意味着其可以被发现和滥用。

　　还要记住，OAuth是一项关于授予对资源的访问无需共享拥有者身份或是凭证的技术，例如某个临时的数据传输授权。即使用户们使用OpenID以及单个身份登入众多站点，他们仍然不得不在某个站点使用用户名或密码登录。我会建议在设计架构上实施一些可用性测试来看看你的用户的反应。有些人可能喜欢输入用户名和密码而不是点击登录到Twitter，他们输入用户名/密码，点击提交，批准后最终返回到你的站点。

　　为移动应用建立一套标准的认证和授权框架，我们还有一些路要走，但是对于那些以此为业务模式中的关键方面的公司来说，如Google，他们正在继续为之努力。到那时，OAuth 2.0可能是你最佳的选择，你只要牢记你用户的需和你自己的需求。