HATEOAS/REST API 的正确身份验证方法答案

【问题标题】：Proper authentication method for HATEOAS/REST APIHATEOAS/REST API 的正确身份验证方法
【发布时间】：2017-03-05 17:35:16
【问题描述】：

最近我一直在阅读一些关于 HTTP JSON REST API 中 HATEOAS 实现的内容（因为我制作了一个），并且我了解链接和操作等的一般概念，并且定义了许多不同的格式，例如如 HAL、JSON API 等。

我还不明白 HATEOAS/REST 和身份验证之间的关系是什么，或者更具体的问题是，“正确的”HATEOAS/REST API 应该使用哪种类型的身份验证？

显然，它应该是无状态的，例如 JWT 令牌或类似的东西，但是是否有任何标准和/或规则/指南或者身份验证完全不同的主题？

编辑：

为了进一步澄清，我的问题不是我在选择要实现的身份验证时遇到问题，而是我不知道 API 身份验证需要什么才能将其称为 REST/HATEOAS API。

所以（假设的）场景是：创建一个在任何意义上都可以说是 REST/HATEOAS 的 API，并获得 1,000,000 美元。犯一个违反协议的小错误并获得 0 美元。这意味着，目标不是做最有意义、最高效或有利于开发人员和/或用户的事情，而只是做到毫无疑问的 100% REST/HATEOAS。

【问题讨论】：

REST 是一种架构风格，而不是其本身的架构。有许多可能的“正确”身份验证系统，即使您将自己缩小到仅基于 HTTP 的 REST。
@NicholasShanks 好的，感谢您澄清这一点。那么哪些是可能的“正确”的，为什么它们可能是“正确的”，哪些不是“正确的”，为什么？（我不是要一个完整的列表，只是事情的原理和一两个例子）
REST 说“使用统一接口”，这通过 HTTP 本质上意味着您应该使用 HTTP 的身份验证系统；不要例如将您的身份验证参数包装在 XML 请求正文的某个深处（就像 SOAP 一样）。因此，任何使用（错误命名的）授权标头的东西都可以与识别它的中介一起使用。我个人经常使用 Bearer (token) 认证：tools.ietf.org/html/rfc6750
其他使用 HTTPS 接口的身份验证系统是基于 Cookie 的（通常也是令牌系统，但没有共享标头命名法）；并将用户名和密码放在 URL 中，你应该只考虑在专用网络上这样做，即使那样你也不应该这样做:-)
您需要满足所有 REST 约束 stackoverflow.com/a/25706876/607033 和所有相关标准，如 IRI、HTTP、JSON/XML/RDF 等。因此，它是关于寻找符合这些标准的身份验证解决方案。从 HATEOAS 开始，发送身份验证链接并不常见，这通常是硬编码到 REST 客户端的。我认为只有当你想在你的 REST 服务中支持多个身份验证方法并且你想让你的 REST 客户端发现他们可以支持的身份验证方法时，才有这样的链接才有意义。

标签： rest authentication hateoas

【解决方案1】：

正如你所说，你应该以独立的方式看待身份验证。

确实，使用按值令牌实现的基于令牌的身份验证系统非常适合基于 HTTP 的 API 的无状态世界，因此这可能是针对大多数常见场景的建议。但是，您应该查看您的场景的特定要求以做出最终决定，也许有更简单的选项可用，例如 API 密钥。

请记住，如果您选择基于令牌的方法，那么之后仍有很多事情需要考虑。如果您不为应用程序定义获取访问令牌的方法，那么您的 API 将没有多大用处，您可以通过多种方式来解决此问题，例如：

您可以推出自己的系统并围绕如何获取令牌定义自己的流程，然后由 API 使用以执行身份验证
⤷ （不推荐，耗时且容易出错）
实施符合可用身份验证标准（如OpenID Connect 和OAuth 2.0）的身份提供者/授权服务器系统
⤷ （耗时且复杂，但通过遵循标准，您不太可能搞砸，而且您还将获得互操作性）
将身份验证委托给第三方身份验证提供商，例如Auth0
⤷ （容易上手，取决于使用量，它会花费你金钱而不是时间）

披露：我是一名 Auth0 工程师。

【讨论】：

你说我应该以独立的方式看待身份验证，我想知道你这个假设的依据是什么？我正在寻找的是“根据 RFC X，Y 应该以 Z 的方式使用”之类的东西，而不是像“我觉得 REST 应该这样使用”或“我认为 HATEOAS应该这样使用”。第一行之后的所有内容听起来都像是您对 API 身份验证实施的（非常合格的）意见，这不是我所问的。如果问题含糊不清，我深表歉意，如果有问题请告诉我。
对于软件开发中必须做出的每一个决定都没有一个 RFC。我也想这样，但事实并非如此。如果要实现身份验证和授权，要遵循的 RFC 和规范是我最初链接到的。他们会满足您的要求，但您需要根据您的具体场景和要求将各个部分组合在一起。
我认为你是对的，没有针对软件开发中必须做出的每个决定的 RFC，但我想知道是否有任何形式的规范（RFC 或其他文档） ) 在身份验证方面涵盖 REST 和/或 HATEOAS。你是说仔细检查后发现没有？你是说据你所知，没有吗？或者你说可能有，但你认为没关系？（也许我的问题不小心误导了你我正在寻找什么样的答案，所以我对其进行了修改以澄清这一点。）
据我所知，没有将两者结合在一起的 RFC。取决于您对文档的定义，但很有可能 Internet 上有一些东西将两者结合在一起。我认为不值得花时间去寻找它，如果它有任何好处，它会很容易找到。您已经了解当前的身份验证/授权标准，您已经了解 REST/HATEOS，现在它根据要求将这两者放在一起。
我不想对像你这样愿意提供帮助的人显得傲慢，但在我看来，你最后的评论让你从没有回答我的问题变成了回答我的问题在对您答案的评论的前半部分以毫无根据的方式（没有证据）提出问题，我希望您能理解这不足以让我接受。