如何将安全性与网关结合起来？ [关闭]

Question

我正在研究微服务架构，现在主要关注 api 网关和安全性。

我发现有两种不同的方法：

1- 身份验证在网关之外，即用户

• 必须先进行身份验证，
• 获取令牌，
• 然后可以通过网关调用服务 我见过的最常见的场景，每个人都在实施/呈现），如图表链接中所述 Authentication outside of the gateway

2- 另一种方法是将所有东西都放在网关后面，也就是说，用户

• 尝试通过网关访问受保护的资源/服务，
• 他也通过网关被重定向到身份提供者登录页面，
• 通过身份验证，将令牌传回给客户端/用户，
• 最后到达请求服务，一切都通过网关的一个http调用，这将导致一些额外的调用（授权代码流，url回调客户端，如图链接中所述Authentication behind the gateway

虽然有些人可能会谈论第二种方法，但我似乎找不到任何实际的实现或详细描述。这让我想问……为什么？

如果我遵循微服务设计，我自然会使用第二个实现，但没有……每个人似乎都在使用第一个。

根据我读到的内容，是的，这需要更多的努力，因为您必须重新路由必要的身份验证和授权端点，但是是这样吗？难道没有其他的理由让我们更喜欢第一个而不是第二个吗？

有什么见解吗？

Answer 1

简答：

第二个选项是最常见的。你是对的。如果您不需要重定向用户，请不要。

长答案：

在微服务之前，所有“服务”都是单个应用程序中的不同路由。应用程序将用户流量路由到正确的位置。

在中间放置一个网关是将第一级路由器从单个应用程序抽象到它自己的应用程序。

• 如果网关只是将流量路由到后端服务，那么它就是一个负载平衡器（也称为应用感知代理、反向代理等）。负载平衡器是一个前端服务，它将流量重定向到正确的内部后端服务。李>
• 如果网关既提供页面服务，又将流量路由到后端服务，那么它就是一个 Web 应用程序和一个负载平衡器。

谈论使用不同用户可见目标 (url) 的身份验证流程的人们正在解决常见问题。我能想到的三个原因：

1. 在图表中清楚地表明哪一部分是身份验证，哪一部分是黑盒服务
2. 随着组织的发展，许多人构建自己的服务和身份验证流程。一个用于第一个产品，然后另一个用于他们的下一个产品，第三个用于他们的第三个产品。在某些时候，他们需要合理化如何将他们的身份验证整合到一个流程中。
3. 不同的 URL 设置不同的 cookie 范围。有时您需要多个域来隔离 Cookie。

例如，使用 Google Oauth 或 Okta SAML 之类的服务 - 您需要登录他们的域，并且需要一种方法将 token 恢复到您的域。由于您在 yoursite.com 上看不到 google.com 或 okta.com cookie，因此外部流程是必要的。当公司添加具有不同域的产品时，通常会出现这种情况。

每次登录时，Google 产品都会重定向几次。他们正在从 accounts.google.com 到 gmail.google.com 进行 cookie 管理，并始终保持 google.com cookie 隔离。但是，您每次都在使用同一个 google 负载均衡器（或者理论上可以）。