node.js api 网关实现和护照认证

Posted 2023-03-08

【中文标题】node.js api 网关实现和护照认证

【英文标题】：node.js api gateway implementation and passport authentication

【发布时间】：2017-08-19 10:34:03

【问题描述】：

我正在使用 node.js 实现基于微服务的应用程序。在搜索有关如何实现 api 网关的示例时，我偶然发现了以下文章，该文章似乎提供了有关实现 api 网关的示例：https://memz.co/api-gateway-microservices-docker-node-js/。虽然到目前为止，在 node.js 中找到实现 api 网关模式的示例似乎有点困难，但这篇文章似乎是一个非常好的示例。

有一些项目仍不清楚，我在查找文档时仍然遇到问题。在。

1) 安全性是应用程序的主要项目。我正在开发，我无法看到应该在哪里进行身份验证（即使用护照，我是否应该在 api 网关中添加身份验证项并将 jwt 令牌与请求一起传递给相应的微服务，因为用户的登录信息是某些活动需要？这里唯一的问题似乎是所有微服务都需要护照才能解密 jwt 令牌以获取用户的个人资料信息。除了通过 api 网关外，微服务在技术上是否对外界无法访问因为这似乎是目标？

2) 如果我需要扩展到多台服务器，每台服务器上都有 docker 映像，这种情况会发生什么变化？这将如何影响负载平衡，因为似乎必须有更高级别的东西来处理负载平衡？

【问题讨论】：

可能Information Security 是一个更好的提问地点。

【参考方案1】：

我可以说这在很大程度上取决于您的应用程序要求。真的。 我现在已经拥有 5 年的生产微服务经验，使用多种语言从中型到超大型系统。

他们都没有相同的要求，如果不深入了解您的需求以及您的业务（产品）要求是什么，就很难知道什么是正确的答案，顺便说一下，我将尝试分享一些经验可以帮助您做对。

理想情况下，您希望将安全性封装在外部服务中，以便您可以更快地更新和应用新策略。此外，如果您发现系统存在漏洞，或者您团队中的某个人无意中将某些密钥（或证书）推送到外部服务，您也可以弃用所有现有令牌。

您可以处理每个服务的身份验证或使用边缘网络工具（例如 API 网关）。小心选择如何处理它，因为每个人都有自己的特权：

选择 API 网关，您的服务将保持轻量级，并且不需要了解任何有关身份验证步骤的信息，但肯定在某些时候您需要知道经过身份验证的用户是谁，并且您需要一些简单的参考它（JSON 记录、“用户配置文件”服务的链接或 ID）。您如何做这取决于您的要求，我们甚至可以更深入地讨论适用于您的案例的每种可能选择的不同利弊。

选择在服务级别处理它需要您（和您的团队）更好地了解正在发生的安全过程（您可以使用好的库将其隐藏）并且您需要向他们提供支持您的安全团队（也可能是您自己，顺便说一句，您知道实现安全的服务越多，您必须考虑的事情就越多，以避免添加不必要的功能）。这里最大的问题是，你经常会停止你的任务来思考什么可以帮助你完成这个特定的服务，你会很想扩展你的身份验证服务（天哪，除非你真的知道你在做什么做，不要添加身份验证不需要的单个调用）。

有一件事很容易确定：您肯定需要考虑令牌（jwt、jwe 或者，再次，无论您的要求强加什么）。

JWT 有很好的优势，但数据容易受到欺骗，因此切勿将敏感数据或您不会公开分享的有关用户的内容放入其中（例如，ID 可能没问题，而安全问题或 2FA 解决方案则不会）。 JWE 是规范的加密形式。一个通用令牌（没有意义）需要一个后端来获取数据，但它的工作原理很像 cookie 会话，并且数据不会离开您的服务器。

您需要为自己定义服务的边界并帮自己一个忙：让每个服务边界清晰、明确和标准。

尝试定义通用策略并标准化交互，我知道在这里添加一个队列、那里添加一个 REST 端点、那里添加一个 RPC 可能会更容易，但是你很快就会得到一堆你无法使用的 IPC不再处理，它很快就会引起你的注意。

此外，如果您的业务解决方案非常繁重，我认为自己做 API 网关、安全性等不是一个好主意。我会选择开源、社区支持（如果您有预算，甚至是公司支持）和经过生产测试的解决方案。

根据定义，微服务架构是非常动态的，您将努力使其在每个部署版本之间保持不变，但除非您是一家大公司，否则您无法努力保持数千台服务器的实时运行。这意味着您会发现仅在某些情况下才会出现的错误，而您在其他环境中无法发现（通常无法重现它们）。

通过选择自己开发整个堆栈，您同意必须在整个堆栈中处理维护和错误发现。因此，当您尝试加载具有 25 个交互服务的页面时，您知道它可能会因为以下错误而失败：您的 API 网关、您的安全实现、您的令牌解析器、您的用户帐户服务、您的业务服务 A 到 N、您的数据库服务（如果有）、您的数据库负载平衡（如果有）、您的数据库实例。

我知道做任何事情都很诱人，但请尽量保持平稳并做你需要做的事情。沿着这条路走，你会想到你的产品，我认为这是现在最重要的想法。

为了完成我的回答，关于缩放问题： 没关系。无论您选择什么，它都会无缝扩展：

API 网关应该能够在后端池上工作（因此，您应该能够从该服务器重定向到 N 台后端机器，您可以在需要时投入使用，您甚至可以有一些 API 来支持自动注册新实例，甚至简单地将 Elastic Load Balancer 或 HAproxy 或等价物的 IP 放入其中，当您向它们添加后端时，它将正常工作 - 您已将多个 IP 问题从 API 网关移至一层） .

如果您在服务级别处理身份验证（并且您有 API 网关），请参阅 #1

如果您在服务级别处理身份验证（没有 API 网关），那么您需要查看堆栈中的其他级别：负载平衡（第 3 层或第 7 层）或 DNS 级别，您可以使用DNS 的多种功能可以让不同的 IP 进行响应，如果您需要延迟分布，甚至可以使用 Anycast 等高级功能。

我知道这个答案引入了很多其他问题，但我真的很想回答你的问题。事实是，在规划微服务架构时，您需要了解和评估很多事情，如果我办公室的每一面墙上都印有非常书面的计划，我不会编写 SLOC。

您通常需要集中精神并退出单一服务，以查看全球视野并检查一切是否正常。

我不想吓到你，我只是想让你觉得成功。 我只是希望您在决定从头开始做所有事情之前确保您正确评估了所有可能性。

附：如果您选择使用 API 网关进行操作，请务必将服务限制为仅接受通过它的请求。在同一台机器上开始监听本地主机，在多台机器上你需要一些高级网络规则，具体取决于你的操作系统。

祝你好运！

【讨论】：

这条评论不仅很好地概述了在何处放置安全性的决策，而且还对微服务架构提供了很好的可靠意见。我绝对喜欢它，/拍手