我正在使用BackboneJS构建一个消息传递应用程序，它自然会继续使用REST接口。
我遇到的问题是我不知道如何限制用户可以从API撤回的数据。例如，对/ messages的调用此时将返回所有用户的消息。我希望该资源只返回属于当前用户的消息。
在线搜索似乎表明oAuth2是解决此问题的最佳方式，但所有教程都谈到了重定向到另一个地方以确认访问并检索访问令牌。
鉴于我的用户已经登录到消息应用程序并且REST API实际上是同一应用程序的一部分，我不喜欢要求用户确认我自己的应用程序可以访问我自己的API。
有更好的方法吗？
答案 0 :(得分：1)
oAuth2有四种不同的风格，称为授权授权类型：
授权码：这是您正在考虑的类型。它通常被称为三脚oAuth，因为令牌授予过程中有三个角色（app，资源所有者和用户）。该应用程序询问用户资源所有者是否可以提供对资源的特定访问类型。这是一个相当复杂的过程，允许验证用户凭据，而不允许应用程序访问它们。在您的情况下，这不是必需的，因为您既是应用程序所有者又是资源所有者。
客户端凭据：这是一种使用服务器授权客户端应用程序的方法。它根本不使用用户凭据。如果您完全信任您的客户端应用程序（所有客户端应用程序）以正确保护用户数据并且不使用该应用程序向用户公开其他用户的数据，或者您仅提供非用户数据通过API（例如，地图数据或目录数据），您可以使用这种相当简单的oAuth2类型。但是，如果您希望保护用户数据（并且不允许应用程序在没有用户提供凭据的情况下访问数据），您可能不会使用此数据。
资源所有者密码凭据：用户的用户名和密码通过https传递到后端服务器，后端服务器通过提供访问令牌来验证和授权访问。然后可以在每次调用时传递访问令牌，并且在可配置的时间段过去之前，它仍然有效用于访问后端。这意味着拦截令牌的人只能在有限的时间内成功使用它（通常是几分钟）。拦截器不会知道用户的用户名和密码。此外，您可以为应用程序提供刷新令牌，该令牌可用于在新的访问令牌到期后获取（直到刷新令牌到期 - 通常具有明显更长的到期日期）。由于凭证通常不会通过线路传递（并且必须仅加密传递），因此这通常是保护用户凭据并且不要求用户经常传递它们的最佳解决方案（良好的用户体验）。实现比授权代码授予类型简单得多。
隐式：这是最不安全的方法 - 根本没有凭证验证服务器端。这通常用于无法安全存储凭据的客户端脚本语言。如果您担心安全问题，请尽可能避免使用此类型。
因此，请查看OAuth 2.0，然后查找资源所有者密码凭据授予类型。