在这个 SaaS 场景中，OAuth 是 RESTful API 的好选择吗? [英] Is OAuth good choice for RESTful API in this SaaS scenario?

问题描述

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

Is OAuth sensible to use when the user account info (user id's, passwords, roles, etc) is going to be maintained in our own back-end and when there will not be any sharing of resources with other sites? Or is sharing the whole point of using OAuth?

背景:

我正在开发企业 SaaS 产品，我们正在创建一个 RESTful API，供我们的前端应用程序使用.API 的使用者将是我们开发的浏览器和本机智能手机(iOS 和 Android)应用程序.由于我们将支持多种客户端类型，因此创建一个我们所有客户端应用都可以使用的 RESTful API 是有意义的.

I'm working on developing an enterprise SaaS product and we are creating a RESTful API to be used by our front-end applications. Consumers of the API will be browser and native smartphone (iOS & Android) applications that we develop. Since we'll be supporting multiple client types, it makes sense to create a RESTful API that all our client apps can consume.

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

Naturally we need to secure this RESTful API. We are considering authenticating using HTTPS / Basic Auth but we are aware of some of the well known drawbacks to this approach.

一些快速研究表明强烈建议使用 OAuth.但我在 OAuth 中发现的大部分内容都涉及授权网站代表用户共享信息.

Some quick research shows OAuth is highly recommended. But most of what I find with OAuth is in the context of authorizing web sites to share information on behalf of the user.

欢迎提供任何信息.

推荐答案

好问题，我们在 API Craft 上就这个问题进行了很好的讨论:

Good question, and we're having a good discussion on this over at API Craft:

https://groups.google.com/group/api-工艺/浏览线程/线程/b87fd667cccb9c00

这是我在那里发布的答案:

Here's the answer that I posted there:

实际上，我认为这是 OAuth 的一个很好的用例.

I think this is a good use case for OAuth, actually.

首先，通过 OAuth，您的移动应用可以在客户端存储 OAuth 令牌，而不是用户的真实"密码.因此，您可以通过获取 OAuth 令牌让应用程序自动登录用户"，而无需在设备上存储实际密码.如果用户丢失了设备或者设备以某种方式受到损害，他们(或您)可以擦除 OAuth 令牌，而无需用户更改密码并清除他们可能使用您的 API 做的其他事情.Ajax 风格的 Web 应用程序有类似的示例，但它更多地取决于您构建客户端的具体方式.

First of all, with OAuth your mobile app can store an OAuth token on the client rather than the user's "real" password. So, you can have the app automatically "log the user in" by getting an OAuth token without having to store the actual password on the device. If the user loses the device or if it's compromised somehow they (or you) can wipe the OAuth token without requiring that the user change the password and blow away other things that they might be doing with your API. There are similar examples for an Ajax-style web app but it depends more on the specific way that you build the client.

其次，OAuth 令牌与唯一密钥相关联，该密钥标识进行 API 调用的应用，进而标识构建该应用的开发者.这为您提供了诸如按应用程序跟踪使用情况、在不禁用整个 API 的情况下关闭可能已被入侵的应用程序等选项，如果您想向为您的 API 构建应用程序的第三方或合作伙伴开放访问权限，您可以提供不同的级别为其他客户提供服务.

Second, the OAuth token is associated with a unique key that identifies the app that is making the API call, and that in turn identifies which developer built the app. That gives you options like tracking usage by application, turning off an application that might have been compromised without disabling the whole API, and if you ever want to open access to third parties or partners who build apps for your API, you can offer different levels of service to other customers.

第三，如果您告诉 IT 安全人员您从不将密码存储在用户的移动设备上或将其存放在浏览器中的某个位置，他们会很高兴.

Third, your IT security people will be happy if you tell them that you never store a password on the user's mobile device or stash it somewhere in their browser.

第四，您可以选择基于浏览器登录移动应用程序.这意味着移动应用程序永远不会看到用户的密码，而且如果您想实现双因素安全或类似的东西，您可以在登录屏幕中执行此操作而无需更改移动应用程序.现在，缺点是用户会看到一个浏览器窗口弹出.这就是为什么 OAuth 为您提供了几种不同的方式来获取应用的访问令牌，因此您可以选择是需要基于浏览器登录还是让用户直接在应用中输入密码.

Fourth, you have the option of browser-based login for the mobile app. That means that the mobile app will never see the user's password, and also that if you want to implement two-factor security or something like that, you can do it in the login screen without changing the mobile apps. Now, the downside is that the user sees a browser window pop up. That's why OAuth gives you a few different ways to get an access token for an app, so you can choose whether you need to have browser-based login or have the user enter their password directly in the app.

第五，你怎么知道你的 API 只会被你自己的应用使用?如果您现在使用 OAuth，那么您以后可以更轻松地进行转换.

Fifth, how do you know that your API will only ever be used by your own apps? If you use OAuth now then you will have an easier time making that transition later.

这篇关于在这个 SaaS 场景中，OAuth 是 RESTful API 的好选择吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！