当用户帐户信息（用户ID，密码，角色等）将在我们自己的后端维护以及何时不与其他站点共享资源时，OAuth是否合理？或者分享使用OAuth的全部意义？
背景
我正在开发企业级SaaS产品，我们正在创建一个RESTful API供我们的前端应用程序使用。 API的消费者将是我们开发的浏览器和本机智能手机（iOS和Android）应用程序。由于我们将支持多种客户端类型，因此创建一个我们所有客户端应用程序都可以使用的RESTful API是有意义的。
当然，我们需要保护这个RESTful API。我们正在考虑使用HTTPS / Basic Auth进行身份验证，但我们知道这种方法存在一些众所周知的缺点。
一些快速研究表明强烈建议使用OAuth。但我发现OAuth的大部分内容都是授权网站代表用户共享信息。
欢迎任何信息。
答案 0 :(得分：7)
很好的问题，我们在API Craft上对此进行了很好的讨论：
https://groups.google.com/group/api-craft/browse_thread/thread/b87fd667cccb9c00
以下是我在那里发布的答案：
我认为这实际上是OAuth的一个很好的用例。
首先，使用OAuth，您的移动应用可以在客户端上存储OAuth令牌，而不是用户的“真实”密码。因此，您可以通过获取OAuth令牌自动“登录用户”，而无需在设备上存储实际密码。如果用户丢失了设备，或者某些设备遭到入侵，他们（或您）可以擦除OAuth令牌，而无需用户更改密码并吹走他们可能使用API执行的其他操作。 Ajax风格的Web应用程序有类似的示例，但它更多地取决于您构建客户端的具体方式。
其次，OAuth令牌与唯一键相关联，该唯一键标识正在进行API调用的应用程序，并反过来标识构建应用程序的开发人员。这为您提供了一些选项，例如跟踪应用程序的使用情况，在不禁用整个API的情况下关闭可能已被入侵的应用程序，以及如果您想要打开对为您的API构建应用程序的第三方或合作伙伴的访问权限，您可以提供不同的级别对其他客户的服务。
第三，如果您告诉他们您从未在用户的移动设备上存储密码或将其藏匿在浏览器中的某个位置，您的IT安全人员会很高兴。
第四，您可以选择基于浏览器的移动应用程序登录。这意味着移动应用程序永远不会看到用户的密码，而且如果您想要实现双因素安全性或类似的东西，您可以在登录屏幕中执行此操作而无需更改移动应用程序。现在，缺点是用户看到弹出的浏览器窗口。这就是为什么OAuth为您提供了一些获取应用访问令牌的方法，因此您可以选择是否需要基于浏览器的登录或让用户直接在应用中输入密码。
第五，您如何知道您的API只会被您自己的应用使用？如果您现在使用OAuth，那么稍后您将更容易进行转换。
答案 1 :(得分：3)
是的，这非常适合OAuth。在握手期间，您仍然可以使用HTTP Basic over SSL进行身份验证。 OAuth握手的输出将是一个令牌，然后可以使用该令牌来使用API。这样，应用程序不需要存储凭据，并且令牌可以轻松撤销，而用户影响最小。
OAuth 2.0定义了许多不同的授权类型，以适应不同的情况。听起来像“隐含”或“资源所有者密码凭证”是最合适的，但您可能需要仔细考虑每个。
您不应直接在API中实现此功能，而应使用基础架构代替您的SaaS API委派OAuth支持和令牌管理。
看看
http://www.layer7tech.com/blogs/index.php/oauth-token-management-2/
和
http://www.layer7tech.com/products/oauth-toolkit
希望得到这个帮助，
-FL
答案 2 :(得分：1)
我实现了一个带有活塞的Django nonrel的OAuth，以便将我的API暴露给消费者。 OAuth中有很多种（2腿3腿）。
通常，支持OAuth是一个相当大的挑战。您必须获取请求令牌，对其进行授权，存储访问令牌以对要进行身份验证的每个请求进行签名。
<强>优点
- 您不必每次都发送用户名和密码，安全
- 允许第三方使用您的应用。
的缺点
- 进行2,3次往返认证
- 复杂，自己实现它。
我很确定你可以找到一些允许你的图书馆：
- 公开您的Api并支持OAuth。 E.g Django活塞。
- 通过向他们添加标题来签署您的请求。例如Oauth-signpost。
答案 3 :(得分：0)
OAuth只是一个令牌，请求的应用程序将发出一个令牌。您可以在pingidentity.com上阅读更多内容，其中有关于此主题的多个网络研讨会（云身份和用户配置）。