API /系统设计[灵活认证/授权]？

Question

背景：

我们是一家规模较小的商店，生产许多需要认证和授权的产品。我们目前正在使用第三方服务为每个应用程序“划分新的auth”。然而，由于将来可能需要额外的安全需求，我想研究一下我们自己做这件事的潜在设计。我已经包括了下面的信息，并将感谢任何设计或支持，因为我是相对新鲜的设计，这种规模。

目标摘要：

允许开发人员通过网页为多个应用程序创建和管理身份验证API的接口。这包括编制新的auth API的主要自动化过程，以及理想情况下通过此页面进行某种形式的RBAC / ABAC更改的能力。

可接受的“限制”：

1. 所有的API都可以公开相同的公共端点，因此它们基本上只是彼此的“图像”。(即登录/注册等)
2. 虽然这在理想情况下是完全自动化的，但我认为手动操作的一些部分是：*域配置(将子域指向新的端点)*旋出额外的VM(需要？)*编制额外的DB或表？*微小的配置更改*其他我没有想到的？

用户故事：

• 作为一名开发人员，我想登录到一个web门户，以便我可以管理auth。
• 作为一个开发人员，我希望在web中创建一个新的API，这样我就可以将它集成到新的应用程序中。
• 作为一名开发人员，我希望管理web中的用户，这样我就可以监督对我们应用程序的访问。
• 作为一个开发者，我想**.

今后的考虑：

应用程序的每个新API都应该将用户存储区(包含用户信息的表)隔离到存储在不同硬件上的不同数据库中，以最小化攻击向量并提高安全性/扩展性。现在，我正在考虑不同的子域，或者请求参数来分离API？

思想：

我觉得可能有一些解决方案，包括在Azure上构建Auth的模板/映像，只复制VM或映像，但我也不太确定这条路线。显然，管理，维护，更新等这些将是更多的手工操作，但随时提供反馈，以及。

提前感谢！

Answer 1

你好像把很多东西都塞进了一个简短的问题里，或者我读得太多了.

身份验证:我建议研究开源社区中可用的和积极支持的内容，并考虑根据需要进行构建。https://en.wikipedia.org/wiki/Keycloak开源在人们心目中是值得一看的。在作出决定之前，我会先查几个，然后再试几个。

基础设施:基础设施的动态配置和部署听起来更像是Terraform，是一个很好的起点。我还想看看HashiCorp Consul+Vault，因为听起来您可能会根据这些用户故事来进行机密管理。将配置与代码分开，并将秘密存放在像Vault这样的秘密商店中。

扩展:我在用例上没有足够的上下文来“扩展额外的DB”，但是如果您试图扩展服务，Kubernetes和容器可能会有所帮助吗？

由于您从事的业务是提供基于服务的API，如果您还没有这样做，您可能需要查看OpenAPI 3.x。这在很多方面都很有帮助，包括为您的服务编写一些自动化的安全测试。

编辑:据我所知，你说你想推出自己的解决方案，这就是我提供的答案。考虑到您从商业云供应商(Google、AWS、Microsoft等)获得的服务质量。我会考虑你的需求是否会证明你需要的时间和成本是合理的。如果您有问题，我会与其中一个供应商联系，讨论他们是否能够支持您所需的内容，或者是否支持他们的开发领域。

对于即将出现在这个线程上的新主题，下面是一个5分钟的视频，介绍使用Google Cloud - https://www.youtube.com/watch?v=pBVAyU4pZOU和书面说明https://support.google.com/cloud/answer/6158849#zippy=%2Cweb-applications的API身份验证。