基本 HTTP 身份验证：用户还是应用程序？答案

【问题标题】：Basic HTTP Authentication: User or Application?基本 HTTP 身份验证：用户还是应用程序？
【发布时间】：2011-11-12 22:10:32
【问题描述】：

应该是对我问题的简单回答，但在网络上我似乎得到了相互矛盾的信息。

假设我有一个使用基本 HTTP 身份验证的简单 API。移动应用程序使用我在 SSL 上的 API 来注册新用户 (POST) 和 (GET) ANY 用户信息/配置文件。

问题：我是在使用 HTTP 身份验证验证用户还是应用程序？

举个例子……

让我们说

api.somedomain.com/user/create

api.somedomain.com/user/{userID}

场景 1：API 在标头中使用基本身份验证，应用程序发送开发人员用户名和密码（不是登录到他们的应用程序的用户）。应用可以创建用户，应用可以查看用户帐号。

缺点：如果有人发现应用程序使用的用户名和密码，他们可以创建用户并查看帐户。

场景 2：我通过基本身份验证而不是应用程序来验证用户。这样用户可以在登录应用程序时查看他们的信息。

缺点：应用程序无法创建新用户，因为他们需要先以用户身份进行身份验证。

现在我知道第一个答案将是“使用 OAuth”，但在这种情况下，我想要一个基本身份验证的答案。

提前致谢

【问题讨论】：

你已经列出了优点和缺点。现在，您有什么要求？
移动应用程序需要允许用户通过 API 注册并通过 API 查看其他用户的个人资料。但是我只希望应用程序使用 API（也许稍后会有更多应用程序需要访问）。我的问题是，在场景 1 中，任何拥有应用程序密钥的人都可以创建一个帐户。不好！我知道，由于我无法控制移动应用程序，因此很难找到仍然可能的密钥。
我应该使用 HTTP 身份验证来验证用户或应用程序，还是两者兼而有之？该应用程序供用户在没有帐户时创建帐户，或查看其帐户详细信息或查看其他帐户（只读）。
您不需要在整个 API 中要求相同的身份验证。如果您打算使用基本身份验证，则可以仅对某些资源要求它（至少在 PHP 和 CGI 中；其他环境可能将身份验证完全留给 Web 服务器）。这意味着您可以拥有一个不需要身份验证的注册 API，而其他一切都需要。
我发现了一些我认为可以回答我的问题的东西： Quote: 首先重要的是，进行 REST 查询的系统不是交互式用户。因此，您永远不应要求或允许用户使用交互式用户凭据进行 REST 身份验证。唯一的例外是客户端/服务器应用程序，其中客户端代表交互式用户，客户端和服务器之间的协议是 RESTful API。 " broadcast.oreilly.com/2009/12/…

【解决方案1】：

好吧，无论如何你有两个用户（两种用户）。一种是活的人形，另一种是应用程序。

“应用类用户”被允许创建账户，“类人动物”被允许查看/编辑他的个人资料。

对于您的服务器，问题应该很简单：

像对待活人一样对待移动应用程序，让它们的区别仅在于权限。您的移动应用程序可能会在尝试创建帐户时向您发送自己的凭据，但只要有人提供了自己的登录名和密码，您的移动应用程序就可以使用由人类提供的。

【讨论】：

有点意思我找到了一句话：您的 REST 客户端不是交互式用户。客户可以通过创建一个专门用于 REST 身份验证的专用帐户来伪造这一点。不幸的是，这使攻击者能够将交互式帐户作为攻击媒介来破坏整个系统。此外，由于 REST 验证的是程序而不是个人，因此它允许比人类用户 ID/密码方案更强大的验证。 ---- 所以 make by 为 API 用户创建一个新表是要走的路。
如果您正确执行权限，客户将无法破坏系统。从安全的角度来看，从浏览器访问服务器或从您的移动应用程序访问服务器应该没有区别。你也不应该太相信你的应用程序。让它只执行它需要的操作，仅此而已。这是一个广泛的话题，我们可能很快就会用完 cmets 的空间；-)
是的，这是一个很大的话题，这就是为什么我只想查看“用户”或不查看“用户”的原因。我想从这里我有更好的理解，希望其他人也能这样。