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