当用户帐户信息(用户 ID、密码、角色等)将在我们自己的后端维护并且不会与其他站点共享任何资源时，使用 OAuth 是否明智？或者分享使用 OAuth 的全部意义？
背景:
我正在开发一个企业 SaaS 产品，我们正在创建一个 RESTful API 供我们的前端应用程序使用。 API 的使用者将是我们开发的浏览器和 native 智能手机(iOS 和 Android)应用程序。由于我们将支持多种客户端类型，因此创建一个可供所有客户端应用程序使用的 RESTful API 是有意义的。
当然，我们需要保护这个 RESTful API。我们正在考虑使用 HTTPS/基本身份验证进行身份验证，但我们意识到这种方法的一些众所周知的缺点。
一些快速研究表明强烈建议使用 OAuth。但我发现 OAuth 的大部分内容是授权网站代表用户共享信息。
欢迎提供任何信息。
最佳答案
好问题，我们在 API Craft 上对此进行了很好的讨论:
https://groups.google.com/group/api-craft/browse_thread/thread/b87fd667cccb9c00
这是我在那里发布的答案:
实际上，我认为这是 OAuth 的一个很好的用例。
首先，通过 OAuth，您的移动应用程序可以在客户端上存储 OAuth token ，而不是用户的“真实”密码。因此，您可以通过获取 OAuth token 让应用程序自动“让用户登录”，而无需在设备上存储实际密码。如果用户丢失设备或者设备因某种原因受到损害，他们(或您)可以删除 OAuth token ，而无需用户更改密码并清除他们可能使用您的 API 执行的其他操作。 Ajax 风格的 Web 应用程序有类似的示例，但它更多地取决于构建客户端的具体方式。
其次，OAuth token 与唯一 key 相关联，该 key 标识进行 API 调用的应用程序，进而标识哪个开发人员构建了该应用程序。这为您提供了一些选项，例如按应用程序跟踪使用情况、关闭可能已受到损害的应用程序而不禁用整个 API，如果您想向为您的 API 构建应用程序的第三方或合作伙伴开放访问权限，您可以提供不同的级别为其他客户提供服务。
第三，如果您告诉 IT 安全人员您从不在用户的移动设备上存储密码或将密码隐藏在他们的浏览器中的某个位置，他们会很高兴。
第四，您可以选择基于浏览器登录移动应用程序。这意味着移动应用程序永远不会看到用户的密码，而且如果您想实现双因素安全或类似的操作，您可以在登录屏幕中执行此操作，而无需更改移动应用程序。现在，缺点是用户会看到弹出的浏览器窗口。这就是为什么 OAuth 为您提供了几种不同的方法来获取应用程序的访问 token ，以便您可以选择是否需要基于浏览器的登录或让用户直接在应用程序中输入密码。
第五，您如何知道您的 API 只会被您自己的应用程序使用？如果您现在使用 OAuth，那么稍后您将可以更轻松地进行转换。
关于rest - 在这个 SaaS 场景中，OAuth 是 RESTful API 的好选择吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9368548/