为啥基于表单的身份验证不被视为 RESTful？

Posted 2023-03-08

技术标签:

【中文标题】为啥基于表单的身份验证不被视为 RESTful？【英文标题】：Why is form based authentication NOT considered RESTful?为什么基于表单的身份验证不被视为 RESTful？ 【发布时间】：2011-10-29 06:29:12 【问题描述】：

虽然我“认为”我理解它，但我需要一些澄清。使用 PURE Restful 身份验证，事情会变得有点笨拙，并且使用表单对应用程序的 UI 有很大帮助（即，获得单独的登录页面、忘记密码链接、更容易注销？等等）

现在表格出现了，有些人说“不平静” - 他们的“不平静”是什么？是不是没有对应的登录资源？还是它会强迫我缺少其他东西？

注意：如果有人与他们创建会话，那完全是另一回事。我更想知道“为什么”他们被称为宁静？只需在谷歌上搜索“基于表单的身份验证与静态身份验证”就会得到很多点击。

人们可以使用这些“表单”进行身份验证并传递令牌以供应用程序存储在 cookie 等中，我觉得这完全是宁静的（假设加密安全等）...

【问题讨论】：

【参考方案1】：

现在表格出现了，有些人说“不平静”——什么是“不平静”？

身份验证凭据不在标准位置。

REST 并没有消除对线索的需求。 REST 所做的是将对先验知识的需求集中到易于标准化的形式中。 -- Fielding, 2008

RFC 7235 描述了Authorization 标头；这为我们提供了一种区分授权请求（具有标头）和匿名请求（没有标头）的标准方法。

因为我们可以区分授权请求和匿名请求，通用组件可以做一些有趣的事情。

例如，如果源服务器限制对资源的访问，我们可能不希望共享缓存重复使用 HTTP 响应的副本来满足其他请求。因为授权有一个标准化的形式，我们可以定义caching semantics来限制共享缓存可以做什么。

将相同的信息放入 cookie 标头中，实际上隐藏了通用组件的授权语义。

（这有点类似于对safe 请求使用 POST 请求——通用组件无法区分语义上安全的 POST 请求和语义上不安全的 POST 请求，因此无法智能地利用安全处理进行任何操作)。

如果我们有更智能的表单处理——表单输入控件将信息复制到授权标头而不是查询字符串/请求正文——那么表单将很好。但是 (a) 我们没有，并且 (b) 我们不太可能得到它，因为向后兼容。

【讨论】：

【参考方案2】：

基于表单的身份验证不使用 HTTP 中内置的身份验证技术（例如基本身份验证、摘要式身份验证）。

REST 纯粹主义者会要求您尽可能使用 HTTP 内置的功能。尽管基于表单的身份验证非常普遍，但它并不是官方协议的一部分。因此，REST 纯粹主义者将基于表单的身份验证视为“在 HTTP 本身已经存在 的情况下在 HTTP 之上构建功能的实例。

【讨论】：

Errr 它不使用什么？只是凭据不是“WWW-授权”标头的一部分这一事实？您可以“始终”调整 UI 以发送数据，对吗？【参考方案3】：

发送您的凭据（可能是通过表单）进行身份验证并没有错。问题是大多数基于表单的系统都依赖会话，因此要求您只登录“一次”。

会话是服务器状态，因此违反了 REST 架构的无状态约束。

如果您必须每次都发送凭据，您可以将它们包含在有效负载中（即使用表单），也可以使用 HTTP 授权标头。

如果您将它们包含在负载中，您可以将它们包含在正文中，但仅适用于 POST 或 PUT，而不是 GET 或 DELETE（因为它们没有正文）。

如果您将它们作为查询参数的一部分包含在 URL 中，则 URL 不再一定代表实际资源。其他原则之一是 URL 与资源匹配。在查询参数中添加带外信息（例如凭据）会使约束有点混乱。

因此，对于基于 HTTP 的 REST 系统，您最好使用现有的 HTTP 授权机制，而不是解决其他问题。您也可以使用客户端特定的 SSL 证书，也可以正常工作。

【讨论】：

当您说“现有的 HTTP 授权机制”时，您是指基本/摘要吗？但是他们不会从创建漂亮的登录屏幕中带走“乐趣”吗？ :) 是的，相反，您会从尝试使用 Basic 和 Digest 注销网页的过程中获得乐趣！每个人都有很多乐趣。一点也不好玩，你只是在人体解剖学的各个部分上抓挠，只是想着如何解决它；）基于 cookie 的无会话方法怎么样？当然可以认为是 RESTful 的？当然。但是，如果您要这样做，为什么不简单地使用 Authorization 标头而不是 Cookie 标头来获取此信息？【参考方案4】：

来自this answer：