用于Web应用程序的RESTful身份验证
您已经在这个问题上早些时候写过这个观察和问题，但后来才注意到这是一个古老的“死”的问题。 由于我真的很喜欢别人的一些见解，所以我把它作为一个新问题重新发布。
对于如何以REST方式进行身份验证的问题，人们通常会大声疾呼“HTTP身份验证”。 然而，我怀疑这些人是否曾尝试用REST制作基于浏览器的应用程序（而不是机器到机器的Web服务）。 （没有冒犯的意图 - 我只是不认为他们曾经面临复杂情况）
我在使用HTTP身份验证在使用浏览器查看HTML页面的RESTful服务中发现的问题是：
一篇非常有洞察力的文章将逐一解决这些问题，但这会导致很多浏览器特定的JavaScript hackery，变通方法等等。 因此，它也不是向前兼容的，因此在新浏览器发布时需要不断的维护。 我不认为这是一个干净而清晰的设计，再加上我觉得这是一个额外的工作和头痛，所以我可以向我的朋友们展示我的REST徽章。
我相信饼干是解决方案。 但是等一下，饼干是邪恶的，不是吗？ 不，他们不是，饼干常常被用于邪恶的方式。 Cookie本身只是客户端信息的一部分，就像浏览器在浏览时将跟踪的HTTP身份验证信息一样。 这段客户端信息在每次请求时都会发送到服务器，就像HTTP身份验证信息一样。 从概念上讲，唯一的区别是，这段客户端状态的内容可以由服务器确定为响应的一部分。
通过仅使用以下规则将会话设置为RESTful资源：
与HTTP身份验证唯一的区别在于，身份验证密钥由服务器生成并发送给持续发回的客户端，而不是客户端从输入的凭据中计算出来。
我觉得这是一个很好的解决方案，但我必须承认，我不够安全专家来发现此方案中的潜在漏洞 - 我所知道的是，数百个非RESTful Web应用程序使用本质上相同登录协议（$ _SESSION inphp，j2ee中的HttpSession等）。 Cookie头内容仅用于解决服务器端资源问题，就像接受语言可能用于访问翻译资源等一样。 我觉得它是一样的，但也许别人没有？ 你们觉得怎么样？
一个有趣的问题。 我正在完成一个REST API实现 - 使用mod_rewrite和PHP。 它使用跨HTTPS的HTTP基本身份验证。 到目前为止，我们正在开发Palm Pre客户端。 开发该客户端的人有点迟疑不得不跟踪用户凭证提交每个请求。
将SESSION公开为资源的想法很有趣。 包括它仍然会违反严格的RESTful原则。 即使您将SESSION作为资源公开，您仍然会使用服务器来跟踪客户端状态。 严格遵守REST可能需要使用cookie，因为这是您可以从浏览器获得的客户端永久存储器。 问题是，如果您不希望用户与浏览器实现的HTTP凭证收集进行交互，那么您将创建一个JavaScript（或FLash？）客户端来管理客户端的HTTP请求。
我发现一个有用的工具是REST Client for Firefox工具...但即使在使用该工具时，我仍将我的凭据输入到标准浏览器弹出窗口中。
我必须承认在我的实施中包含一些黑客行为。 如果您所做的只是使用会话来允许潜在开发人员测试/浏览API，或者我认为使用基于会话的身份验证不是那么重要。 纯粹主义者会不同意我相信。 真的这就是这个......这实际上是一个学术论证。 在现实生活中，你必须做一些有效的工作。
...在10/23/2012添加到此...
RESTful方法坚持让客户跟踪自己的状态不仅仅是学术。 它对可扩展性和暴露资源的可寻址性有重要影响。 当我这样说时，我假设通过客户端状态，我们正在讨论特定于请求用户的属性，这些属性会影响RESTful接口发出的响应。 REST的优势之一是其可寻址性。 当你以任何方式作出回应时，都会依赖于请求中没有通过的信息，然后开始小心处理。 只是一个事后... 3年后，哈哈。
我知道这是一个老问题，但我认为这里的很多问题已经在不同的领域得到了解决。 特别是，我认为OAuth 2.0协议已经考虑了很多这些问题; 我不觉得有足够的权威性来提供他们在这里的答案摘要，但链接的网站有很多不同的用例明确地提出，这对于这个问题似乎非常有用，即使完整的OAuth 2.0并不是真的必要这里。
链接地址: http://www.djcxy.com/p/21967.html