HTTP 基本身份验证 + 访问令牌？答案

【问题标题】：HTTP Basic Authentication + Access Token?HTTP 基本身份验证 + 访问令牌？
【发布时间】：2014-12-17 14:38:52
【问题描述】：

我正在开发一个 REST API，我打算将它与 Web 和 IOS 应用程序一起使用。我打算让这个 API 私有一段时间（私有意味着我只希望我的 web 应用和 ios 应用访问 api）。

我已经阅读了许多不同的身份验证方法，但我仍然对为我的 API 选择合适的身份验证方法感到困惑。

据我了解，oAuth2 是为了允许用户使用其他服务提供商登录您的 APP，以便您可以访问相应服务提供商的数据。我在自己的 API 中访问数据，所以我认为这不适用于我？

所以，这就是我的想法：

1) 使用 HTTP 基本身份验证将用户/密码发送到服务器。
2) 服务器验证登录后，返回一个将在 x 小时后过期的访问令牌。这将允许我简单地存储令牌而不是用户/通行证。

我在 Google 上搜索过这种技术，但并没有真正找到任何关于这种方法的信息，这让我相信这不是一个好方法，因为我可能正在尝试重新发明一些东西？

我该怎么办？我正在寻找两条腿的 oAuth 吗？

【问题讨论】：

标签： security authentication oauth oauth-2.0 basic-authentication

【解决方案1】：

OAuth 2.0 已成为保护 Web API 的首选协议。它需要用户授权应用程序访问您的 Web API。

您希望您的应用程序是唯一可以访问某些 API 的应用程序。 OAuth 2.0 允许这样做。

在您的授权服务器中，实现 Authorization Code Grant 并需要客户端凭据（非可选）。使其只有您的应用程序（或配置的列表操作第一方应用程序）可以获得进行这些 API 调用所需的范围。只要您确实为客户保密，您的应用程序将是唯一能够获得具有所需范围的访问令牌的应用程序。在 Web API 中，确保将范围授予用于调用 API 的访问令牌。

良好的授权服务器，例如 The Identity Hub，将允许您这样做。

不要使用Resource Owner Password Credentials Grant。正如规范所说：

仅当存在高资源所有者和客户之间的信任程度（例如，客户端是设备操作系统的一部分或具有高度特权的应用程序），并且当其他授权授予类型不是可用（例如授权码）。

这是重复的later on：

授权服务器应特别注意以下情况启用此授权类型，并且仅在其他流未启用时才允许可行的。

如果密码凭证授权可用，任何应用程序都可以通过向用户询问用户 ID 和密码来获取令牌。这正是你不想要的。

关于使用密码固有问题的规范is very clear：

在传统的客户端-服务器身份验证模型中，客户端请求访问受限的资源（受保护的资源）通过使用资源所有者的服务器与服务器进行身份验证证书。为了提供第三方应用程序访问受限资源，资源所有者与第三方。这会产生一些问题和限制

OAuth 2.0 专门用于克服使用密码的一些问题：

OAuth 通过引入授权层解决了这些问题并将客户端的角色与资源的角色分开所有者。在 OAuth 中，客户端请求访问受控资源由资源所有者和资源服务器托管，并且是颁发了一组不同于资源的凭据所有者。

此外，如果您的 API 想要了解用户（除了了解客户端应用程序），则不可能滥用 Resource Owner Password Credentials Grant 来验证客户端（即应用程序）而不是资源所有者（即用户)，正如 Florent Morselli 所建议的那样。

【讨论】：

Kris Vandermotten，这让我更加困惑。我认为授权授予适用于您想通过其他提供商登录到应用程序时。比如，如果我希望用户通过 Facebook 或 Twitter 登录我的应用程序。我的 IOS 应用程序是我网站的官方应用程序。就像您访问 Facebook 应用程序并使用您的用户名/密码登录 Facebook 一样。我正在登录自己的 API。由于它是我的官方应用程序，因此具有很高的信任度。因此，如果我将用户名/密码从 IOS 发布到我的 API，我还需要发送客户端凭据，但我无法将这些安全地存储在 IOS 中。
@AlexLacayo 我不知道您是否可以将它们安全地存储在 IOS 中。但我确实知道，通过资源所有者密码凭据授予，您的授权服务器以及您的 API 无法判断是您的应用程序发出了调用，还是其他应用程序。这违反了您的主要要求，即您首先提出这个问题的原因：您的 API 根本不是私有的。
如果我错了，请纠正我，但使用资源所有者密码凭据授予您将用户凭据与客户端凭据一起传递给 API 以获取令牌。因此，从技术上讲，它会知道请求来自哪里 (tools.ietf.org/html/rfc6749#section-4.3.2)。但是，我知道我无法将客户端凭据安全地存储在 IOS 中。假设我的公司/网站被称为“X”。因此，当用户下载我的应用程序时，它会说“使用 X 登录”，而不是简单地使用用户名/密码登录表单（如 twitter、fb、IG 等为其官方应用程序所做的）。这是不是有点傻？
这就是我的观点：规范允许使用密码授权进行可选的客户端身份验证，但您不能从设备应用程序中使用它。但是为什么你的应用程序应该说“使用 X 登录”而不是“登录”，我看不到。你选择你在那个按钮上写的东西，不是吗？同样，您确定呈现给用户的网页的外观，以便它与您的应用程序融为一体。事实上，代码授权只是获取用户凭据并将其转换为令牌的一种更安全的方式。为什么会很傻？
您是说将登录作为网站嵌入到我的应用程序中吗？我想我想象的是当用户打开应用程序时，用户将被要求单击“登录到 x”（或我决定的任何内容），然后他们将被重定向到某个地方，而不是简单地在立即加载屏幕上显示一个表单在应用程序中（就像 IG、FB）。当我下载一个随机应用程序并选择“使用 Facebook 登录”时，我将被重定向到 FB 以获得批准。那么，在我的个人应用程序中，这是我的困惑吗？这有意义吗？

【解决方案2】：

实际上，OAuth2 并不是专门用于验证您的用户，而是授权客户端（网站或应用程序）访问资源（用户信息、页面、文件...）。

由于您的网站和应用程序是私有的（因此您对它们有高度的信任），我建议您使用Resource Owner Password Credentials 授权类型。仅需要用户名/密码来获取访问令牌（如果需要，还需要刷新令牌）。您的客户不必像您提到的那样存储这些凭据。

只是一个精度：OAuth2 可能用于 HTTP 基本身份验证to authenticate the client，而不是资源所有者/用户。

【讨论】：