3

我正在尝试编写一个无状态的、基于 REST 的 API，我计划从几个不同的地方使用它，其中一个将是一个单页 Javascript webapp。这个想法基本上是拥有一个可用于各种不同客户端的 API——包括那些可能由其他人编写但仍可能需要访问用户数据的 API——而不是为不同的客户端使用不同的 API。

我目前遇到的问题是身份验证。理想情况下，我想在这里使用一些标准而不是自己滚动，但我正在努力寻找真正适合的标准。我还试图避免根据谁进行呼叫而使用不同的身份验证机制的解决方案。在这个阶段，我实际上只需要对实际使用应用程序的用户进行身份验证——通过用户名和密码或类似方式——但如果/当不是网页的客户端想要使用它时，他们应该可能也会被认证。

从我所看到的情况来看，似乎最好的方法实际上是通过 HTTPS 连接使用 HTTP Basic 身份验证。我不禁认为这是缺少一些东西。显而易见的替代方案似乎是 OAuth 1.0 - 它要求潜在不安全的 Javascript 会话知道客户端密钥 - 或 OAuth 2.0 - 这似乎回到使用 SSL 上的用户名/密码来生成访问令牌，然后使用该访问在 SSL 上再次请求未来请求上的令牌，这与 HTTP Basic 基本相同，但有点混淆。

请注意，我没有在这里计算 HTTP Digest，仅仅是因为 - 据我了解 - 传递给服务器的内容是包含不可检索形式（即散列）的密码，并且如果我将密码存储在后端以不可检索的形式，那么我无法比较两者......

4

1 回答 1

1

我将创建一个单独的 API 来处理用户登录。然后，您的 API 客户端（一个 JS 网页）可以通过 HTTP Digest + SSL 向此登录 API 提交用户名/密码。然后 API 将针对用户存储（数据库或文件等）执行登录，并返回结果 - 批准/拒绝访问。

如果获得批准，它应该返回一个经过身份验证的令牌（例如，用户名+密码+角色+权限+日期时间等的单向哈希函数）。

您的 JS 客户端（通过浏览器）的所有后续请求都需要将此令牌（将在用户会话对象中携带，也许在加密的 cookie 中）提交给您正在与之交互的所有 API。令牌可以定时过期，之后用户将被迫重新登录。

这种方法保持无状态，但有一些问题。如果登录令牌被盗或被用户共享怎么办？在令牌的生命周期内，任何拥有令牌副本的人都可以冒充您的用户（中间人）发起查询。SSL 应该防止它成为消息的最外层信封。

我可以想象在您的 REST（业务）API 和 REST（登录）API 之间进行某种握手。因此，当您的 REST 业务 API 收到此令牌时，也许它可以要求登录 API 验证它是否创建了此令牌以及为什么用户代理创建的。

无论如何，对于简单的应用程序，上述方法就足够了。

于 2013-11-20T03:07:05.050 回答