【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
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的身份验证解决方案：
- 在身份验证服务器上创建公钥/私钥对。
- 将公钥分发给所有服务器。
当客户端进行身份验证时：
3.1。 发出包含以下内容的令牌：
- 到期时间
- 用户名（可选）
- 用户IP（可选）
- 密码哈希（可选）
3.2。 使用私钥加密令牌。
3.3。 将加密的令牌发送回用户。
当用户访问任何API时，他们还必须传递其身份验证令牌。
- 服务器可以通过使用auth服务器的公钥解密来验证令牌是否有效。
这是无状态/ RESTful身份验证。
请注意，如果包含密码哈希，则用户还将发送未加密的密码以及身份验证令牌。 服务器可以通过比较哈希来验证密码是否与用于创建身份验证令牌的密码匹配。 使用HTTPS之类的安全连接是必要的。 客户端的Javascript可以处理获取用户密码并将其存储在客户端，可以存储在内存中，也可以存储在cookie中，可能使用服务器的公钥进行加密。
来源：oschina
链接：https://my.oschina.net/u/3797416/blog/3145966