在这种 SaaS 场景中，OAuth 是 RESTful API 的好选择吗？

Posted 2023-03-08

【中文标题】在这种 SaaS 场景中，OAuth 是 RESTful API 的好选择吗？

【英文标题】：Is OAuth good choice for RESTful API in this SaaS scenario?

【发布时间】：2012-03-11 05:33:23

【问题描述】：

当用户帐户信息（用户 ID、密码、角色等）将在我们自己的后端维护并且不会与其他站点共享任何资源时，使用 OAuth 是否明智？还是分享使用 OAuth 的全部意义？

背景：

我正在开发一个企业 SaaS 产品，我们正在创建一个 RESTful API 供我们的前端应用程序使用。 API 的消费者将是我们开发的浏览器和原生智能手机（ios 和 android）应用程序。由于我们将支持多种客户端类型，因此创建一个所有客户端应用都可以使用的 RESTful API 是有意义的。

当然，我们需要保护这个 RESTful API。我们正在考虑使用 HTTPS / Basic Auth 进行身份验证，但我们知道这种方法存在一些众所周知的缺点。

一些快速研究表明，强烈建议使用 OAuth。但我发现 OAuth 的大部分内容是授权网站代表用户共享信息。

欢迎提供任何信息。

【问题讨论】：

“授权上下文..” 那是三足 OAuth。还有两条腿的oauth，这可能是您需要的。

【参考方案1】：

问得好，我们正在 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，那么您以后可以更轻松地进行转换。

【参考方案2】：

是的，这非常适合 OAuth。您仍然可以在握手期间使用基于 SSL 的 HTTP Basic 进行身份验证。 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

【讨论】：

两个链接都坏了。

【参考方案3】：

我使用活塞为 Django nonrel 实现了 OAuth，以将我的 API 公开给消费者。 OAuth（2-legs 3legs）中有多种类型。

一般来说，支持 OAuth 是一个相当大的挑战。您必须获取请求令牌，对其进行授权，存储访问令牌以签署您要验证的每个请求。

优势 - 您不必每次都发送用户名和密码，安全。 - 允许第三方使用您的应用。缺点 - 进行 2,3 次往返以进行身份​​验证。 - 自己实现它很复杂。

我很确定您可以找到许多库，让您： - 公开您的 Api 并支持 OAuth。例如 Django 活塞。 - 通过向它们添加标头来签署您的请求。例如 Oauth 路标。

【参考方案4】：

OAuth 只是一个令牌，发出请求的 App 会发出一个令牌。您可以在 pingidentity.com 上阅读更多内容，其中也有关于此主题（云身份和用户配置）的多个网络研讨会。

【讨论】：

非常没有帮助。提供与此问题相关的资源和信息的链接。