与kong集成的微服务的用户注册+身份验证 [英] User registration + authentication for microservices integrated with kong

问题描述

我正在开发基于微服务的node.js应用程序.开发了各个微服务，包括已经处理过身份验证，授权和注册过程的微服务.我正在审查使用kong作为api网关，但是正在寻找有关如何通过kong处理身份验证等方面的说明，但是仍然使用我已经创建的用户服务，该用户服务已经与db相关联.

I am in the process of developing a node.js microservices-based application. The individual microservices are developed including one that already handles the authentication, authorization and registration processes. I am reviewing using kong as the api gateway but am looking for clarity regarding how I can handle authentication, etc. through kong but still use the user service I already created, which already has a db associated with it.

理想情况下，如果可以将身份验证信息传递到用户服务以验证用户的登录凭据(用户名和密码)，并且如果身份验证成功，则可以让kong生成jwt令牌，则是更可取的.

Ideally, I would prefer if I could have kong pass the authentication information to the user service to validate the user's login credentials (username and password) and have kong generate the jwt token provided the authentication was successful.

kong可能出现这种情况吗?还是我必须以某种方式将所有此功能移至kong，身份验证，授权和注册?

Is this possible with kong or would I have to somehow move all of this functionality to kong, authentication, authorization and registration?

我发现以下文章概述了使用自定义身份验证服务器的方法，但这似乎很复杂:

I found the following article outlining an approach using a custom Authentication server, but this seems pretty involved: Custom Authentication Service in Kong API Gateway.

简而言之，我希望用户将用户名/密码组合传递给kong，该kong将以某种方式通过上游传递到我已经拥有的用户服务的端点.然后，这将验证用户并确认或拒绝用户/通行证是正确的.从这一点开始，kong将生成jwt并返回给用户.如果可能的话，那就太好了.如果我有一个实现自定义授权服务的工具，它也可以正常工作，但绝对不是首选.:-)

In a nutshell, I would like the user to pass a username/password combination to kong, which kong would somehow pass upstream to the endpoint of the user service I already have. This would then validate the user and confirm or deny user/pass is correct. From this point, kong would generate the jwt and return to the user. If this were possible it would be great. If I have a implement a custom authorization service that could work as well, but definitely not preferred.:-)

推荐答案

因此，在几个地方积极使用Kong的建议，我建议您 使用JWT，并且带有Kong的JWT插件，或使用OAuth2插件，但就我所知，两者的结合实际上是不可能的(据我所知).但是，请耐心一点.

So, what I would say from actively using Kong in a couple of places, I would suggest that you either use JWTs, and the JWT plugin with Kong, or use the OAuth2 plugin, but a combination of both is (as far as I know) actually not possible with Kong. But, bear with me for a little while.

对于您的情况，使用JWT可能是一个非常简单的解决方案.我现在在您的假设中看到的唯一误解是，Kong实际上可以帮助您制作JWT令牌，情况并非如此. Kong只能验证JWT，而不能制作它们.这必须由您自己的授权服务来完成.再说一次，要如何将令牌传递给使用服务又取决于服务的类型.

For your situation, using a JWT might be a fairly simple solution. The only misconception I see right now in your assumptions is that Kong actually helps you in crafting JWT tokens, which is not the case. Kong can only validate JWT, but not craft them; this has to be done by your own Authorization Service. Then again, how you want to pass the token to the consuming service is again something which depends on the type of the service.

在这里，您可能要使用OAuth2流，例如如果您的客户是SPA，则为隐式授予"，或其他一些授予(例如资源所有者密码授予")，但在两种情况下，Kong 都不会帮助您实施它.您将需要自己实现/authorize(用于隐式授予)或/token端点(用于资源所有者密码授予).再次:Kong将仅验证您制作的JWT，而不验证令牌.实施这些端点并不是很困难，但是需要阅读 RFC 6749 (值得努力).

Here, you might want to use an OAuth2 flow, e.g. the Implicit Grant if your client is an SPA, or some other grant (such as the Resource Owner Password Grant), but in both cases, Kong will not help you in implementing it. You will need to implement the /authorize (for the implicit grant) or the /token endpoints (for the Resource Owner Password Grant) by yourself. Once more: Kong will only validate the JWT which you craft, and not craft the token. Implementing those end points is not really difficult, but requires reading the RFC 6749 (which is worth the effort).

制作令牌时，请查看Kong的文档，了解Kong对JWT的期望，尤其是关于iss声明，该声明必须与您的API定义中的某些属性匹配.您可以为您的API手动检索，也可以使用Kong Admin API(端口8001)执行该操作.前者更容易，后者需要一些编码，但更可靠，更灵活.

When crafting your tokens, check the documentation of Kong on what Kong expects from the JWT, especially regarding the iss claim, which has to match a certain property inside your API definition. You can either retrieve that manually for your API, or you can use the Kong Admin API to do that (port 8001). The former is easier, the latter requires some coding but is more reliable and flexible.

您在其中找到的解决方案概述另一个问题提出了一个不同的解决方案，在该解决方案中，您实际上要实现一个真正的OAuth2授权服务器，并使用Kong OAuth2插件.

The solution outline you found in that other question suggests a different solution, where you actually implement a real OAuth2 Authorization Server, and make use of the Kong OAuth2 plugin.

这确实需要深入研究OAuth2规范，并且还非常了解Kong如何做到这一点(这有点特殊).我在该问题中提供的答案概述了必要的步骤.

This really requires digging into the OAuth2 spec, and also understanding quite well how Kong does this (which is a little special). The answer I provided in that question outlines the necessary steps.

使用这两种解决方案，您都可以受益于Kong验证您对API的调用，并且仅让具有有效令牌的调用通过. JWT选项使您可以精心设计令牌，并且还需要API后端实现检查令牌并取出所需的声明，例如JWT令牌中的用户ID"或范围"之类的东西. Kong不会为您完成这项工作，只会验证JWT令牌已正确签名.

With both solutions you get the benefit of Kong validating your calls to your API, and only letting calls with a valid token pass. The JWT option leaves you with crafting your token, and will also require your API backend implementation to inspect the token and take out which claims it needs, such as something like a "User ID" or "Scopes" from the JWT token. Kong will not do that work for you, it will just validate that the JWT token is correctly signed.

第二个选项将更多的负载分流到Kong，在授权用户时，您在不透明令牌中添加X-Authenticated-UserId和(可选)X-Authenticated-Scope，这反过来又丰富了对后端API的调用通过标题.这意味着您的API不需要做任何额外的工作即可将令牌拆开-信息可通过Kong注入的额外标头轻松获得.

The second option offloads that more to Kong, where you, when authorizing the user, add an X-Authenticated-UserId and (optionally) an X-Authenticated-Scope to the opaque token, which in turn is enriched to the call to your backend API via headers. Which means that your API does not have to do any extra work in taking the token apart - the information is readily available via Kong-injected extra headers.

这篇关于与kong集成的微服务的用户注册+身份验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！