Web应用程序的RESTful身份验证

Question

嗨已经写了这个观察和问题,关于这个问题的较早,但后来才发现,这是一个老"死"的问题.由于我非常喜欢其他人的一些见解,我将其作为一个新问题重新发布.

对于如何进行RESTful身份验证的问题,人们通常会热情地喊出"HTTP身份验证".但是,我怀疑这些人是否曾尝试使用REST 制作基于浏览器的应用程序(而不是机器到机器的Web服务).(没有违法行为 - 我只是认为他们没有遇到过并发症)

我在RESTful服务上使用HTTP身份验证发现的问题是生成可在浏览器中查看的HTML页面:

• 用户通常会得到一个丑陋的浏览器制作的登录框,这对用户不友好.你不能添加密码检索,帮助框等.
• 以不同的名称注销或登录是一个问题 - 浏览器将继续向站点发送身份验证信息,直到您关闭窗口
• 超时很难

铲球这些逐点非常有见地的文章是在这里,但是这导致的很多特定浏览器的JavaScript两轮牛车,变通办法变通办法,等等的.因此,它也不是向前兼容的,因此在发布新浏览器时需要不断维护.我不认为干净清晰的设计,而且我觉得这是一项额外的工作和头痛,这样我就可以热情地向我的朋友展示我的REST徽章.

我相信cookie是解决方案.但等等,饼干是邪恶的,不是吗？不,他们不是,饼干的使用方式往往是邪恶的.Cookie本身只是一条客户端信息,就像浏览器在浏览时会跟踪的HTTP身份验证信息一样.这条客户端信息在每次请求时都会发送到服务器,就像HTTP身份验证信息一样.在概念上,唯一的区别是所述内容这块客户端状态中的可以由确定服务器作为其响应的一部分.

通过使用以下规则使会话成为RESTful资源:

• 一个会话映射一个关键用户ID(也可能是最后行动时间戳超时)
• 如果存在会话,则表示该密钥有效.
• 登录意味着POST到/ sessions,新密钥被设置为cookie
• 注销意味着DELETEing/sessions/{key}(重载POST,请记住,我们是浏览器,HTML 5还有很长的路要走)
• 通过在每个请求时将密钥作为cookie发送并检查会话是否存在且有效来完成身份验证

现在,与HTTP身份验证的唯一区别在于,身份验证密钥由服务器生成并发送给不断发送回来的客户端,而不是客户端从输入的凭据计算它.

我认为这是一个运行良好的充分解决方案,但我必须承认,我不足以识别此方案中的潜在漏洞 - 我所知道的是,数百个非RESTful Web应用程序使用的基本相同登录协议($ _SESSION inphp,j2ee中的HttpSession等).cookie头内容仅用于寻址服务器端资源,就像接受语言可能用于访问翻译资源一样,等等.我觉得它是一样的,但也许其他人不一样？你们觉得怎么样？

Answer 1

一个有趣的问题。我现在正在完成 REST API 实现 - 使用了 mod_rewrite 和 PHP。它使用跨 HTTPS 的 HTTP 基本身份验证。到目前为止，我们正在开发 Palm Pre 客户端。开发该客户端的人对必须跟踪每个请求提交的用户凭据感到有点犹豫。

将 SESSION 作为资源公开的想法很有趣。包含它仍然会违反严格的 RESTful 原则。即使您将 SESSION 作为资源公开，您仍然会使用服务器来跟踪客户端状态。严格遵守 REST 可能需要使用 cookie，因为这是浏览器提供给您的客户端持久内存。问题是，如果您不希望用户与浏览器实现的 HTTP 凭据收集进行交互，那么您就需要创建一个 JavaScript（或 FLash？）客户端来管理客户端的 HTTP 请求。

我发现一个有用的工具是 Firefox 的 REST 客户端工具...但即使在使用该工具时，我仍然会在标准浏览器弹出窗口中输入我的凭据。

我必须承认在我的实现中包含了一些技巧。如果您所做的只是使用会话来允许潜在开发人员测试/浏览 API，或者我认为使用基于会话的身份验证没什么大不了的。我确信纯粹主义者会不同意。确实，这就是归结为……这本质上是一个学术争论。在现实生活中，你必须做有效的事情。

... 于 2012 年 10 月 23 日添加此内容 ...

RESTful 方法坚持让客户端跟踪自己的状态不仅仅是学术上的。它对于公开资源的可扩展性和可寻址性具有重要影响。当我这么说时，我假设通过客户端状态，我们正在讨论特定于请求用户的属性，这些属性会影响 RESTful 接口发出的响应。REST 的优势之一是其可寻址性。当您以任何方式根据请求中未传递的信息做出响应时，您就开始削弱它。只是事后的想法......三年后，哈哈。