TL;DR：速率限制是您唯一的选择。

当您将移动应用程序和网站作为 API 客户端时，您将向客户端设备发送 API 密钥/秘密 - 包括可能由攻击者控制的设备。您永远不能依赖这些密钥的机密性来做出安全决定。他们太容易妥协了。当然，您可以禁用并重新发布已泄露的密钥/密钥，但鉴于您的架构，您只需将新密钥/密钥发送给他们将再次受到泄露的客户端。基本上，您正在报名参加一场没完没了的打地鼠游戏。

即使密钥/机密没有泄露，因为您将允许第三方客户端，您必须防止请求过多数据的非恶意客户端，无论是由于设计不佳还是错误。因此，您绝对需要适当的速率限制 - 即使对于经过身份验证的客户端也是如此。

简而言之，您提出的身份验证几乎没有提供任何安全性，即使使用该身份验证，您也需要适当的速率限制。虽然您的 DoS 保护必须基于速率限制，但我仍会使用 API 密钥/秘密来协助监控和调试。

如果在严肃的 API 市场上出现上述两个位置中的任何一个，是否存在严重错误或会被嘲笑？

考虑到从 API 返回的数据是公共信息，我真的不明白为什么需要身份验证，假设您的陈述“有争议的是 API 是否应该要求对本质上是公共数据的内容进行身份验证。 ”是正确的。（那句话的本质部分让我想知道）

该声明：

“我们不能只让 API 对任何想调用它的人开放”

不完整，因为它没有描述原因。为什么不能对任何人开放？你有什么好怕的？

速率限制应明显实施，并且应由 DDoS 保护层解决它的声明不足，因为您应该使用深度防御方法。

这意味着您将保护嵌入到每个可能的层中（在合理范围内）。

开放的 API 可能被滥用或负载攻击。

一个示例是配置为 API 提供服务的 Web 服务器也具有速率限制，而不仅仅依赖于 DDoS 保护。

这里是否有正确的方法，或者这两种方法在安全性方面是否明智，并且可以根据其他考虑因素（例如方便/易于实施）进行选择？

是的，它们都是明智的，并且可以在这里应用成本/收益方法。为了保护公共数据，您愿意投资多少？

您遗漏了重要的一点：利用公共 API 更容易。对于老练的攻击者来说，绕过速率限制相对容易。如果存在任何类型的漏洞，例如 SQLi 或 XXE，自动化工具将很快检测到并滥用它，并且滥用行为将无法追踪到特定用户（如果没有的话）。

如果在严肃的 API 市场上出现上述两个位置中的任何一个，是否存在严重错误或会被嘲笑？这里是否有正确的方法，或者这两种方法在安全性方面是否明智，并且可以根据其他考虑因素（例如方便/易于实施）进行选择？

它们都是合理的立场，答案是肯定的，有一个正确的做法，你可以同时支持这两种立场：许多身份验证服务都有访客或匿名用户，相当于未经身份验证的访问。

最佳实践要求来宾用户设置适当的授权访问规则。为确保您的 API 使用方便 - 如果未提供身份验证凭据，则您的 API 将假定来宾用户访问。我强烈建议选择支持来宾用户概念的身份验证服务，因为默认情况下它的实现应该是相当安全的，尽管你会想要遵循它的配置建议。

然而，正如您所观察到的，引入未经身份验证的 API 访问确实会使您面临滥用行为 - 仅限制访客用户（可能来自同一 IP 地址）的速率可能有助于缓解某些情况。我还建议查看第三方解决方案，例如 Redhat 的apiman，以了解他们如何管理配额/限制。使用这种方法，您可以随时禁用来宾用户。