有关使用 REST 和 Backbone 的身份验证工作流程的问题

Question

我目前正在开发一个使用 Backbone.js 构建的网站。该站点在 Symfony 中使用 FOSRestBundle 构建了一个 RESTful API。开发进展顺利，直到我偶然发现一些与用户相关的票证。

据我了解，处理此类问题的最佳方法是使用基于令牌的系统，在该系统中，用户在批准登录后会获得访问令牌。我将描述我目前对工作流程的看法，并在此过程中提出问题。更重要的是，如果我有误解，请纠正我。

首先，用户访问登录表单，然后用户输入凭据，然后向服务器发送 AJAX 请求。据我了解，这一切都应该使用 SSL 处理，但是使用 Backbonejs，您不能简单地说应该使用 HTTPS 访问登录页面，因为 Backbone 是一个单页框架。那么这会迫使我在整个应用程序中使用 HTTPS 吗？

在下一步中，REST 服务器验证凭据并获得批准，然后 REST 服务器向客户端发送访问令牌。这个令牌（在客户端）是保存在本地存储还是 cookie 中？

也是把登录信息保存在服务器上，让REST服务器在一定时间后把用户注销？

现在，客户端将这个访问令牌与其他请求一起发送，以便服务器可以识别客户端，并批准或不批准请求。那么访问令牌也存储在REST服务器上？

最后，这就是聪明人所说的“oauth”，还是和它有关？

谢谢。

Answer 1

让我们一次回答一个问题。

据我了解，这一切都应该使用 SSL 处理，但是使用 Backbonejs，你不能 简单说登录页面应该用HTTPS访问，因为Backbone是一页的 框架。那么这会迫使我在整个应用程序中使用 HTTPS 吗？

好的，那里有很多东西要解压。让我们从 SSL/HTTPS 开始。 HTTPS 是一个协议；换句话说，它定义了如何向/从服务器发送数据包。它与您的应用程序是单页还是多页无关；任何一种类型的网站都可以使用 HTTP 或 HTTPS。

话虽如此，通过 HTTP 发送登录信息（或任何其他包含密码的内容）是一个非常糟糕的主意，因为它使“坏人”很容易窃取用户的密码。因此，无论您是在做单页还是多页应用程序，在发送登录信息时都应该始终使用 HTTPS。由于必须同时支持 HTTP 和 HTTPS 很痛苦，而且由于其他非登录数据也可能很敏感，因此许多人选择只通过 HTTPS 完成所有请求（但您没有 em> 到）。

因此，为了回答您的实际问题，Backbone 并没有强迫您使用 HTTPS 进行登录。保护你的用户密码是强迫你的。

在下一步中，REST 服务器验证凭据，并且它们被批准，然后 REST 服务器向客户端发送访问令牌。此令牌是否已保存（在 客户端）在本地存储或 cookie 中？

虽然任何给定的框架可能会有所不同，但绝大多数使用 cookie 将令牌保存在本地。出于各种原因，它们是处理这类事情的最佳工具。

也是存储在服务器上的登录信息，以便 REST 服务器可以将用户注销 一定时间后？

您已经有了基本正确的想法，但是服务器并没有完全存储登录信息……它更像是服务器将用户登录并创建了一个“会话”。它为该会话提供一个 ID，然后每当用户发出新请求时，该会话 ID 都会随请求一起提供（因为这就是 cookie 的工作方式）。然后服务器可以说“哦，这是 Bob 的会话”并为 Bob 提供适当的内容。

现在，客户端将这个访问令牌与其他请求一起发送，以便服务器可以 识别客户，并批准或不批准请求。所以访问令牌也被存储 在 REST 服务器上？

如果您运行两个独立的服务器，它们就不会神奇地进行通信；你必须让他们互相交谈。因此，如果您的整个应用程序只有一个（可能是 REST-ful）服务器，您的生活会更轻松。如果你不能，那么你的 REST 服务器将不得不在每次收到请求时询问你的其他服务器“嘿，告诉我关于会话 SESSION ID”。

最后，这就是聪明人所说的“oauth”，还是和它有关？

有点，有点，不是真的。 OAuth 是一种授权标准，因此它有点相关，但除非您的登录系统涉及一个完全独立的服务器，否则您没有理由使用它。您可以使用 OAuth 来解决您的“两台服务器，一台 REST-ful 另一台不”的问题，但这可能是矫枉过正（而且不管它超出了我在这个 Stack Overflow 中可以解释的范围）发布）。

希望对您有所帮助。