Kong API Gateway中的自定义身份验证服务


我们目前正在分析微服务的API网关,Kong是可能的候选者之一.我们发现,Kong支持多个用于身份验证的插件,但全部基于存储在Kong数据库本身中的用户.我们需要将此责任委托给我们的自定义auth HTTP服务,并且不想在API网关数据库中添加这些用户.

We are currently analyzing the API gateway for our microservices and Kong is one of the possible candidate. We discovered that Kong support several plugins for authentication but the all based on users stored in Kong database itself. We need to delegate this responsibility to our custom auth HTTP service and don't want to add these users in API gateway database.

可以使用一些代码来实现此目的,而不是使用OpenID connect插件;实际上,您需要实现一个授权服务器,该服务器通过Admin(8001)端口与Kong进行通信,并授权使用带有外部给定用户ID的API.

It's possible to do this with some code around, instead of using the OpenID connect plugin; in effect you need to implement an Authorization Server which talks to Kong via the Admin (8001) port and authorizes the use of an API with externally given User Ids.


In short, it goes as follows (here for the Authorization Code grant):

  • 不是直接向Kong询问令牌,而是向授权服务器发送请求以获取特定API的令牌(硬编码或参数化,具体取决于您的需求),并包括需要的应用程序的客户端ID通话中进行访问(实际上是实现了/authorize端点)
  • 授权服务器现在需要使用所需的任何IdP进行身份验证,以便您在授权服务器中拥有经过身份验证的用户
  • 现在通过Kong Admin API获取API的配置代码,并点击Kong Gateway(端口8443)的/oauth2/authorize端点,包括配置密钥;请注意,您可能还需要通过Admin API查找应用程序客户端ID的客户端密码,以使此工作正常进行
  • POST/oauth2/authorize中包括客户端ID,客户端机密,经过身份验证的用户ID(来自您的自定义IdP)以及范围.这些值将使用应用程序现在可以使用授权码声明的访问令牌添加到对API的后端调用中
  • Kong会给您一个授权码,您将通过302重定向将其传递回应用程序(为此,您需要阅读OAuth2规范)
  • 应用程序使用其客户端和机密信息以及授权码从Kong的端口8443 URL /oauth2/token获取访问令牌(和刷新令牌).
  • Instead of asking Kong directly for tokens, hit the Authorization Server with a request to get a token for a specific API (either hard coded or parameterized, depending on what you need), and include the client ID of the application which needs access in the call (you implement the /authorize end point in fact)
  • The Authorization Server now needs to authenticate with whatever IdP you need, so that you have the authenticated user inside your Authorization Server
  • Now get the provision code for your API via the Kong Admin API, and hit the /oauth2/authorize end point of your Kong Gateway (port 8443), including the provision key; note that you may need to look up the client secret for the application client id also via the Admin API to make this work
  • Include client id, client secret, authenticated user id (from your custom IdP) and optinally scope in the POST to /oauth2/authorize; these values will be added to backend calls to your API using the access token the application can now claim using the authorization code
  • Kong will give you an Authorization Code back, which you pass back to the application via an 302 redirect (you will need to read the OAuth2 spec for this)
  • The application uses its client and secret, with the authorization code, to get the access token (and refresh token) from Kong's port 8443, URL /oauth2/token.


It sounds more involved than it is in the end. I did this for wicked.haufe.io, which is based on Kong and node.js, and adds an open source developer portal to Kong. There's a lot of code in the following two projects which show what can be done to integrate with any IdP:

  • https://github.com/apim-haufe-io/wicked.portal-kong-adapter
  • https://github.com/Haufe-Lexware/wicked.auth-passport
  • https://github.com/Haufe-Lexware/wicked.auth-saml


We're currently investigating to see whether we can also add a default authorization server to wicked, but right now you'd have to roll/fork your own.


Maybe this helps, Martin