带有 HTTP 基本认证的 Restful API 设计

Question

注意：我知道有很多其他 StackOverflow 问题涉及这个主题。我已经阅读了其中的许多，以及许多其他网站。我还有以下问题。

所以，我正在为一个新产品构建一个 REST API。目前，API 完全供我们的网站和手机应用程序私人使用。不过，我认为设计 API 以便将来公开它可能是明智之举。

认证

虽然我研究过 OAuth，但我认为基于 SSL 的 HTTP 基本身份验证对于我们的 API 来说已经足够安全了。据我了解，基于 SSL 的 HTTP 基本身份验证是一种完全可行的 REST API 身份验证方式。它也很简单，这对我很有吸引力，因为我是 API 开发的新手。

授权

如果用户使用其用户名和密码登录 API，他们将只能访问 API 的某些部分。这意味着他们可以访问自己的内容，但不能访问其他用户的内容。此外，他们可能仅限于他们都可以做的事情。

除了用户帐户之外，我还计划拥有其他（非用户）帐户来执行更多全局管理任务。这些帐户可能拥有对 API 的完全访问权限。

这是一个好的设计吗？或者，以这种方式对用户进行身份验证是否不好？我应该只以这种方式验证我的客户（即应用程序）吗？

会话

我最大的问题是，当用户登录我们的网络应用程序时，我如何管理他们的会话？ REST 规定在每个请求中发送用户名和密码。此外，REST API 是无状态的，所以我无法在那里管理会话。但是，我需要跟踪他们是否以某种方式登录了网络应用程序。他们显然不可能为每个请求手动登录。

一种方法是，在用户登录后，我们将他们的登录凭据（电子邮件和密码）保存到 PHP 会话中。然后，对 API 的每个后续请求都可以使用这些凭据。然而，在 PHP 会话中保存用户名和密码感觉是错误的并且非常不安全。但如果不这样做，人们在与 REST API 交互时如何管理会话？

手机应用程序更简单，因为您可以将用户的登录凭据保存到钥匙串中。

谁能帮忙解答我的设计问题？

Answer 1

我知道这个问题有点老了，也许你已经完成了你的工作，但我想给你一些提示。也许这些可以帮助您或将来的任何人。 :)

身份验证

基于 SSL 的 HTTP 基本身份验证非常简单，没错，但并不像您想象的那么安全。您只需在客户端上安装 1 个“假” SSL 证书，并且通过中间人攻击您就可以嗅探流量。

如何安装假证书？在浏览器中这并不难，很多用户在看到巨大的红色警告屏幕时只需点击确定即可。例如在手机上：http://cryptopath.wordpress.com/2010/01/29/iphone-certificate-flaws/

使用此解决方案，您只需拦截一次流量，您将获得用户密码！

我的提示：在登录时生成一个临时密码，并在所有其他请求中使用它。所以攻击者必须拦截密码的登录过程，如果你将这个密码存储在本地手机上，那就更难了。 （当然，您可以为其添加过期时间等...）

授权

我真的不明白你会怎么做。用户访问管理是一件好事，但它取决于给定的项目。

会话

不仅是 REST API，整个 HTTP 世界都是无状态的。如果您使用 PHP 会话，它会将会话 ID 存储在客户端的 cookie 中，并且浏览器每次都会将此 cookie 值发送到服务器。

用户不必每次都登录。他们登录一次并获得令牌/临时密码等......并且（或者如果您不使用这些东西）他们会在每次请求时向您发送一个基本的身份验证标头。 通过这种方式，您可以轻松跟踪谁向您发送了请求，因为您现在已经是该用户，您可以在服务器上存储和链接一些数据。

与用户打交道的方法有很多。基本身份验证就是其中之一。并检查：OAuth's tokens and sessions in REST “OAuth 令牌是明确的会话标识符，......”

您不必存储用户的密码和电子邮件，您只需在每个请求中检查来自客户端的标头/cookies/等...。

手机应用程序更简单，因为您可以保存用户的登录信息 凭证到钥匙串中。

他们可以，但是将用户的真实密码保存在手机上是一种非常糟糕的做法。保存限时令牌会更好一些。 :)

如果需要，您可以在所有其他语言中存储值。例如，如果您想为您的 API 使用 Python 客户端：它会验证并将令牌或它需要的东西存储在变量中，并且在每次其他请求时，它都会使用此存储的数据。

补充说明：

但是，在 PHP 会话中保存用户名和密码只是感觉 错误且非常不安全。

确实不安全，但是（真正的）PHP 会话存储在服务器端，正如我所说，它在客户端只存储一个会话 ID。任何可以获取此会话 ID 的人都可以冒充给定的用户。 （有IP检查等对策……）