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

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

我还不明白的是HATEOAS/REST和身份验证之间的关系是什么，或者更具体地说，一个“合适的”HATEOAS/restapi应该使用什么类型的身份验证

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

编辑：

更进一步地说，我的问题不是我在选择要实现什么身份验证时遇到问题，而是我不知道从API身份验证方面需要什么才能将其称为REST/HATEOAS API

---

因此（假设的）场景是：创建一个可以说是REST/HATEOAS的API，并获得1000000美元。犯一个违反协议的小错误，得到$0。也就是说，我们的目标不是做最有意义、最有效或对开发人员和/或用户有利的事情，而是要毫无疑问地做到100%的休息/休息。

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

的确，由值令牌实现的基于令牌的身份验证系统非常适合基于HTTP的API的无状态世界，因此这可能是对大多数常见场景的建议。但是，您应该研究场景的特定需求以做出最终决定，也许有一个更简单的选项，比如API键

记住，如果你选择了一个基于令牌的方法，那么以后仍然有很多事情要考虑。如果您不为应用程序定义获取访问令牌的方法，那么您的API将不会有多大用处，并且有很多方法可以实现这一点，例如：

• 您可以滚动您自己的系统，并围绕如何获取令牌以及API如何使用令牌定义您自己的流程，以便执行身份验证
  ⤷（不推荐，耗时且容易出错）

• 实施符合可用身份验证标准（如和）的身份提供商/授权服务器系统 ⤷（耗时且复杂，但通过遵循标准，您不太可能陷入混乱，而且还可以获得互操作性）

• 将身份验证委托给第三方身份验证提供商，如
  ⤷（易于启动，取决于使用量，它将花费您的金钱而不是时间）

---

---

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

你说我应该以独立的方式看待身份验证，我想知道你是基于什么假设的？我想要的是“根据RFC X，Y应该以Z的方式使用”，而不是像“我觉得休息应该像这样使用”或“我的意见是HATEOAS应该像这样使用”这样主观的东西。第一行之后的所有内容听起来都像是您对API身份验证实现的（非常有资格的）意见，这不是我要问的。我很抱歉，如果问题含糊不清，请让我知道它是否有问题。软件开发中的每一个决策都没有RFC。我也希望如此，但事实并非如此。如果您想要实现身份验证和授权，那么要遵循的RFC和规范就是我最初链接到的。它们将满足您的需求，但您需要根据您的特定场景和需求将这些部分组合起来。我认为您是对的，在软件开发中必须做出的每个决策都没有RFC，但我想知道是否有任何形式的规范（RFC或其他相关文档）涉及到身份验证时，涵盖REST和/或HATEOAS。你是说经过仔细检查，你发现没有？你是说据你所知，没有？或者你是说可能有，但你认为这无关紧要？（也许我的问题无意中误导了你我在寻找什么样的答案，所以我修改了它以澄清这一点。）据我所知，没有RFC将两者结合在一起。这取决于您对文档的定义，但很可能是互联网上有某种东西将两者结合在一起。我不认为花时间去寻找它是值得的，如果它有什么好处的话，那就很容易找到。你已经知道当前的身份验证/授权标准，你已经知道REST/HATEOS，现在它根据需要将这两者结合在一起。我不想对像你这样的热心帮助的人显得傲慢，但我个人认为，在你最后一次的评论中，你从没有回答我的问题变成了在对你答案的评论的前半部分以毫无根据的方式（没有证据）回答我的问题，我希望你能理解，这不足以让我接受。其余部分是一种建筑风格，而不是建筑本身。有许多可能的“正确”身份验证系统，即使您将自己的范围缩小到仅通过HTTP进行休息。@Nicholashanks好的，谢谢您的澄清。那么，哪些可能是“正确的”，为什么可能是“正确的”，哪些是“不正确的”，为什么？（我并不是想要一个完整的列表，只是这件事的原理和一两个例子）REST说“使用统一的接口”，这在HTTP上本质上意味着你应该使用HTTP的认证系统；不要把你的aut包起来