Web 应用程序的 RESTful 身份验证 [英] RESTful authentication for web applications

问题描述

您好，之前已经在这个问题上写了这个观察和问题，但后来才注意到这是一个古老而死"的问题.因为我真的很想从其他人那里获得一些见解，所以我将其作为一个新问题重新发布.

Hi already wrote this observation and question on this question earlier, but only later noticed that it was an old and "dead" question. As I'd really like some insights from others, I'm reposting it as a new question.

对于如何以REST方式进行身份验证的问题，人们普遍热情地高呼HTTP身份验证".但是，我怀疑这些人是否曾经尝试过使用 REST 制作基于浏览器的应用程序(而不是机器对机器的 Web 服务).(无意冒犯 - 我只是认为他们从未遇到过复杂情况)

To the question of how to do authentication RESTfully, people generally enthousiastically shout "HTTP Authentication". However, I sorf of doubt whether those people ever tried making a browser-based application (instead of a machine-to-machine web service) with REST. (no offense intended - I just don't think they ever faced the complications)

我在 RESTful 服务上使用 HTTP 身份验证发现的问题是:

Problems that I found with using HTTP Authentication on RESTful services that produce HTML pages to be viewed in a browser are:

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

一篇非常有洞察力的文章逐点解决这些问题是这里，但这结果导致很多浏览器特定的 javascript 黑客、变通方法等.因此，它也不向前兼容，因此随着新浏览器的发布需要不断维护.我不认为那种干净和清晰的设计，而且我觉得这是很多额外的工作和头痛，以便我可以热情地向我的朋友展示我的 REST 徽章.

A very insightful article that tackles these point by point is here, but this results to a lot of browser-specific javascript hackery, workarounds to workarounds, etcetera. As such, it is also not forward-compatible so will require constant maintenance as new browsers are released. I do not consider that clean and clear design, plus I feel it is a lot of extra work and headache just so that I can enthousiastically show my REST-badge to my friends.

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

I believe that cookies are the solution. But wait, cookies are evil, aren't they? No they're not, the way cookies are used often is evil. A cookie itself is just a piece of client-side information, just like the HTTP authentication info that the browser would keep track of while you browse. And this piece of client-side information is sent to the server at every request, again just like the HTTP Authentication info would be. Conceptually, the only difference is that the content of this piece of client-side state can be determined by the server as part of its response.

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

By making sessions a RESTful resource with just the following rules:

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

• A session maps a key to a user id (and possibly a last-action-timestamp for timeouts)
• If a session exists, then that means that the key is valid.
• Login means POSTing to /sessions, a new key is set as a cookie
• Logout means DELETEing /sessions/{key} (with overloaded POST, remember, we're a browser and HTML 5 is a long way to go yet)
• Authentication is done by sending the key as a cookie at every request and checking whether the session exists and is valid

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

The only difference to HTTP Authentication, now, is that the authentication key is generated by the server and sent to the client who keeps sending it back, instead of the client computing it from the entered credentials.

我觉得这是一个足够有效的解决方案，但我必须承认我不够安全专家来识别这个方案中的潜在漏洞 - 我所知道的是数百个非 RESTful Web 应用程序使用本质上是相同的登录协议($_SESSION inphp、HttpSession in j2ee 等).cookie 标头内容仅用于寻址服务器端资源，就像可以使用接受语言访问翻译资源等一样.我觉得是一样的，但也许其他人不一样?小伙伴们，你们怎么看?

I feel that this is a sufficient solution that works fine, but I must admit that I'm not enough of a security expert to identify potential holes in this scheme - all I know is that hundreds of non-RESTful web applications use essentially the same login protocol ($_SESSION inphp, HttpSession in j2ee, etc). The cookie header contents is simply used to address a server-side resource, just like an accept-language might be used to access translation resources, etcetera. I feel that it is the same, but maybe others don't? What do you think, guys?

推荐答案

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

An interesting question. I'm finishing up a REST API implementation right now - having used mod_rewrite and PHP. It uses HTTP basic auth across HTTPS. So far we're working on a Palm Pre client. The guy developing that client was a little put off at having to keep track of user credentials to submit with each request.

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

The idea of exposing SESSION as a resource is an interesting one. Including it would still violate strict RESTful principles. Even if you expose SESSION as a resource, you'd still be using the server to keep track of client state. Strict adherence to REST would probably require use of cookies, as that's the client-side persistent memory available to you from the browser. Problem is that leaves you to create a JavaScript (or FLash?) client to manage the HTTP requests client-side if you don't want users interacting with the browser-implemented gathering of HTTP credentials.

我发现一个有用的工具是 REST Client for Firefox 工具......但即使我使用它，我仍然将我的凭据输入到标准浏览器弹出窗口中.

One tool I've found helpful is the REST Client for Firefox tool... but I still enter my credentials into the standard browser popup even when I'm using that.

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

I have to admit to including some hacks in my implementation. If all you're doing is using sessions to allow for testing/browsing of the API by potential developers or something I don't think that using session-based authentication is such a big deal. Purists would disagree I'm sure. Really that's what this comes down to... this is essentially an academic argument. In real-life situations you have to do what works.

... 2012 年 10 月 23 日添加到此...

... adding to this on 10/23/2012 ...

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

The RESTful methodology insistence on making the client keep track of its own state isn't just academic. It has important implications for scalability and the addressability of the exposed resources. When I say this I assume that by client state we are talking about attributes specific to a requesting user which affect the responses issued by the RESTful interface(s). One of REST's strengths is its addressability. When you make its responses in any way dependent on information not passed in the request you start chipping away at that. Just an afterthought... 3 years later, lol.

这篇关于Web 应用程序的 RESTful 身份验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！