让我们一次一个地回答你的问题。
据我了解，这一切都应该使用 SSL 处理，但是使用 Backbonejs，您不能简单地说应该使用 HTTPS 访问登录页面，因为 Backbone 是一个单页框架。那么这会迫使我在整个应用程序中使用 HTTPS 吗？
好的，那里有很多东西要解压。让我们从 SSL/HTTPS 开始。HTTPS 是一种协议；换句话说，它定义了如何向/从服务器发送数据包。它与您的应用程序是单页还是多页无关；任何一种类型的站点都可以使用 HTTP 或 HTTPS。
现在，话虽如此，通过 HTTP 发送登录信息（或任何其他包含密码的内容）是一个非常糟糕的主意，因为它使“坏人”很容易窃取用户的密码。因此，无论您是在做单页应用程序还是多页应用程序，在发送登录信息时都应该始终使用 HTTPS。由于必须同时支持 HTTP 和 HTTPS 很痛苦，而且由于其他非登录数据也可能很敏感，所以许多人选择只通过 HTTPS 完成所有请求（但你没有。
因此，要回答您的实际问题，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 帖子中可以解释的范围）。
希望有帮助。