Javascript中的REST API身份验证
我正在编写一个基于REST的无状态API，我计划从几个不同的地方使用这些API，其中一个将是单页Javascript Web应用程序。这个想法基本上是让一个API用于各种不同的客户端 - 包括那些可能由其他人编写的API，但仍然可能需要访问用户数据 - 而不是针对不同的客户端使用不同的API。Javascript中的REST API身份验证
我现在碰到的问题是验证。理想情况下，我想在这里使用标准，而不是滚动自己的标准，但我正在努力寻找适合的标准。我也试图根据谁在打电话来避免不同验证机制的解决方案。在这个阶段，我实际上并不仅仅需要验证实际使用应用程序的用户身份 - 通过用户名和密码或类似的方式 - 但是如果/当客户端不是网页的客户端想要使用它时，他们应该可能也会被认证。
从我一直在看，看起来最好的方法是使用HTTP基本身份验证通过HTTPS连接。我忍不住想，但这是错过了一些东西。显而易见的替代方案似乎是OAuth 1.0 - 这要求潜在的不安全的Javascript会话知道客户端密钥 - 或OAuth 2.0 - 似乎要回到使用SSL上的用户名/密码生成访问令牌，然后使用该访问令牌再次通过SSL请求，这与HTTP Basic基本相同，但稍微有些混淆。
请注意，我没有在这里计算HTTP摘要，只是因为 - 据我了解 - 传递给服务器的内容是包含以不可检索形式（即散列）的密码的东西，如果我存储密码在后端以不可检索的形式以及我不能比较这两个...
我会创建一个单独的API来处理用户登录。您的API客户端（JS网页）可以通过HTTP Digest + SSL将用户名/密码提交给此登录API。然后API将针对用户存储（数据库或文件等）执行登录，并返回结果 - 批准/拒绝访问。
如果获得批准，它应该返回一个经过身份验证的令牌（例如，通过用户名+密码+角色+权限+日期时间或其他）的单向散列函数。
您的JS客户端（通过浏览器）发出的所有后续请求都需要将此令牌（可能会在用户会话对象中，或者加密cookie中）传递给您正在与之交互的所有API。令牌可以定时到期，之后用户将被强制重新登录。
这种方法保持无状态，但有一些问题。如果登录令牌被盗用或被用户共享会怎么样？在令牌的整个生命周期中，任何拥有令牌副本的人都可以发起假装成为用户的查询（中间人）。 SSL应该防止它成为消息的最外层信封。
我可以想像在你的REST（业务）API和REST（登录）API之间做某种手摇。因此，当您的REST业务API收到此令牌时，可能会要求登录API验证它是否创建了此用户代理。
无论如何，对于简单的应用，上述方法应该就足够了。