我一直在阅读很多 REST API 身份验证线程，试图将它们的工作原理拼凑在一起。似乎有两个主要阵营，“只需使用 HTTP basic/digest 身份验证及其关联的 HTTP 标头，每次都发送用户密码”和“对 URL 进行一次身份验证”，获取令牌，存储它，然后随每个请求发送。 “每个人都同意不使用会话和使用 HTTPS，这是公平的。
我只是希望用户在登录后在浏览器上进行身份验证，而不必单独对 API 进行身份验证。大多数情况下，我希望我的 webservice 可以免费访问搜索等，并且只需要在某些位置对 create/edit/delete 操作进行身份验证。前端只是用户的浏览器，通过 ajax 调用来调用服务。
我的问题是：
-
如果您已经在站点上使用表单身份验证，那么如何最好地设置 HTTP 身份验证标头？您是否需要在登录表单上标记一些 jQuery(如此接受的答案通过表单发送基本认证信息)，以便您也可以对 API 进行身份验证并存储 i.e。设置/api/authenticate 部分，基本上只检查您的 HTTP 身份验证详细信息，以便它们由您的浏览器存储。
-
如果您收到一个令牌并发送该令牌而不是您的 user/pass 每个请求，您在哪里存储它？每个人都说不使用 cookies，但是在哪里浏览器可以存储类似的东西？我可以在一个智能设备上理解你有一个密钥环，或者在一个应用程序中，它有一个地方可以存储它，但不能在浏览器中
我认为，我看到的其他选项基本上是编写您的网络应用程序，并代表用户向 API 发送请求(因此您通常使用表单进行身份验证，然后 Web 应用程序执行 API 调用，发送用户凭证本身，可以存储，而不是直接来自用户。这似乎是解决问题的大量额外工作，如果一个人决定不完全是 REST，你可以整齐地绕过会话，并且还必须存储身份验证细节。
我是不是更好，只是不打扰完全宁静，因为它不适合这个目的和使用会话？看起来好多了。