RESTful身份验证

RESTful身份验证的含义是什么？它是如何工做的？ 我没法在Google上找到一个很好的概述。 我惟一的理解是你在URL中传递会话密钥（remeberal），但这多是很是错误的。

---

#1楼

我怀疑那些热心地喊“HTTP身份验证”的人是否尝试过用REST建立一个基于浏览器的应用程序（而不是机器到机器的Web服务）（没有冒犯的意图 - 我只是以为他们没有遇到过复杂的问题） 。

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

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

铲球这些逐点很是有见地的文章是在这里 ，可是这致使了不少特定浏览器的JavaScript两轮牛车，变通办法变通办法，等等的。 所以，它也不是向前兼容的，所以在发布新浏览器时须要不断维护。 我不认为干净清晰的设计，并且我以为这是一项额外的工做和头痛，因此我能够热情地向个人朋友展现个人REST徽章。

我相信cookie是解决方案。 但等等，饼干是邪恶的，不是吗？ 不，他们不是，饼干常用的方式是邪恶的。 Cookie自己只是一条客户端信息，就像浏览器在浏览时会跟踪的HTTP身份验证信息同样。 这条客户端信息在每次请求时都会发送到服务器，就像HTTP身份验证信息同样。 在概念上，惟一不一样的是，这片客户端状态的内容能够由服务器做为其响应的一部分来肯定。

经过使用如下规则使会话成为RESTful资源：

• 会话将密钥映射到用户标识（多是超时的最后动做时间戳）
• 若是存在会话 ，则表示该密钥有效。
• 登陆意味着POST到/ sessions，新密钥被设置为cookie
• 注销意味着删除/ sessions / {key}（使用重载的POST，记住，咱们是浏览器，HTML 5还有很长的路要走）
• 经过在每一个请求时将密钥做为cookie发送并检查会话是否存在且有效来完成身份验证

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

converter42补充说，当使用https（咱们应该）时，重要的是cookie将设置其安全标志，以便永远不会经过非安全链接发送身份验证信息。 好极了，本身没见过。

我认为这是一个运行良好的充分解决方案，但我必须认可，我不足以识别此方案中的潜在漏洞 - 我所知道的是，数百个非RESTful Web应用程序使用的基本相同登陆协议（PHP中的$ _SESSION，Java EE中的HttpSession等）。 cookie头内容仅用于寻址服务器端资源，就像接受语言可能用于访问翻译资源同样，等等。 我以为它是同样的，但也许其余人不同？ 大家以为怎么样？

---

#2楼

@skrebel（ http://www.berenddeboer.net/rest/authentication.html ）提到的“很是富有洞察力”的文章讨论了一种使人费解但却很是破碎的身份验证方法。

您能够尝试访问该页面（应该只对通过身份验证的用户可查看） http://www.berenddeboer.net/rest/site/authenticated.html，无需任何登陆凭据。

（对不起，我没法对答案发表评论。）

我会说REST和身份验证根本不混合。 REST意味着无状态，但“通过身份验证”是一种状态。 你不能将它们放在同一层。 若是你是一个RESTful的拥护者并对国家不满，那么你必须使用HTTPS（即将安全问题留给另外一层）。

---

#3楼

首先，RESTful Web服务是STATELESS （或换句话说， SESSIONLESS ）。 所以，RESTful服务没有也不该该包含会话或cookie的概念。 在RESTful服务中进行身份验证或受权的方法是使用RFC 2616 HTTP规范中定义的HTTP Authorization标头。 每一个请求都应包含HTTP Authorization标头，而且请求应经过HTTP（SSL）链接发送。 这是在HTTP RESTful Web服务中进行身份验证和验证请求受权的正确方法。 我已经为Cisco Systems的Cisco PRIME Performance Manager应用程序实现了RESTful Web服务。 做为该Web服务的一部分，我也实现了身份验证/受权。

---

#4楼

说实话，我在这里看到了很好的答案，可是让我感到困扰的是当有人将整个无状态概念推向一个极端的教条时。 它让我想起那些只想拥抱纯粹OO的老Smalltalk粉丝，若是某些东西不是一个对象，那么你作错了。 给我一个休息时间。

RESTful方法应该让您的生活更轻松，减小会话的开销和成本，尝试遵循它，由于这是明智的作法，可是你遵循一个学科（任何学科/指南）到极端的那一刻再也不提供预期的好处，那么你作错了。 今天一些最好的语言同时具备函数式编程和面向对象。

若是您解决问题的最简单方法是将身份验证密钥存储在cookie中并在HTTP标头上发送，那么请执行此操做，只是不要滥用它。 请记住，若是会话变得沉重并且很大，若是全部会话都包含一个包含密钥的短字符串，那么会话有什么大不了？

我愿意在评论中接受更正，但我只是没有看到（到目前为止）让咱们的生活变得悲惨的一点，只是避免在咱们的服务器中保留一个大的哈希词典。

---

#5楼

这是一个真正彻底RESTful的身份验证解决方案：

1. 在身份验证服务器上建立公钥/私钥对。
2. 将公钥分发给全部服务器。

3. 当客户端进行身份验证时：

   3.1。 发出包含如下内容的令牌：

   • 到期时间
   • 用户名（可选）
   • 用户IP（可选）
   • 密码哈希（可选）

   3.2。 使用私钥加密令牌。

   3.3。 将加密的令牌发送回用户。

4. 当用户访问任何API时，他们还必须传递其身份验证令牌。

5. 服务器能够经过使用auth服务器的公钥解密来验证令牌是否有效。

这是无状态/ RESTful身份验证。

请注意，若是包含密码哈希，则用户还将发送未加密的密码以及身份验证令牌。 服务器能够经过比较哈希来验证密码是否与用于建立身份验证令牌的密码匹配。 使用HTTPS之类的安全链接是必要的。 客户端的Javascript能够处理获取用户密码并将其存储在客户端，能够存储在内存中，也能够存储在cookie中，可能使用服务器的公钥进行加密。