如何在Kong的顶部添加带有oauth2的API

时间：2017-11-16 07:47:32

标签： php oauth-2.0 authorization microservices kong

我尝试使用Kong的oauth2授权插件在顶级kong上添加API。步骤 我按照Kong documentation：

进行了跟踪
  • 创建API并添加oauth2插件
  • 创建消费者
  • 创建应用程序

我从上面的步骤中获得了client_id，client_secret，provision_key等，但我想知道如果我需要在我的末端创建oauth2服务器或者kong本身在它们的末尾配置它们我们只需要调用它们的端点。 我在laravel中构建我的API。

1 个答案:

答案 0 :(得分：2)

我认为我们在Gitter上的发言非常简短，我已经说过这取决于你的用例。我将简要介绍一下典型的用例，以及需要哪种额外实现的地方。

机器到机器的通信

如果您需要两个系统从后端相互通信，并且这些系统相互信任，您可以使用OAuth2＆＃34;客户端凭据流＆＃34;。在这种情况下，没有＆＃34;最终用户＆＃34;所涉及的身份，只有两个明确相互信任的系统。

对于这种情况，Kong就是您需要的一切 - 您只需询问Kong的API令牌终点（<address of kong>:8443/your_api/oauth2/token用于基于URI的路由，或fqdn.of.kong:8443/oauth2/token如果您正在使用主机基于路由）对于使用您的客户端ID和密钥的访问令牌，您将得到一个。

示例：

curl --insecure -d 'grant_type=client_credentials&client_id=<...>&client_secret=<..>' https://<address of kong>:8443/your_api/oauth2_token

您的后端服务会注入一些额外的标头，例如X-Consumer-Id和X-Custom-ConsumerId，这些标头会映射到您在Kong创建的消费者。

具有最终用户上下文的机密Web应用程序

如果您需要使用机密（=经典）Web应用程序中的API，并且每次调用都需要最终用户上下文，您可能需要使用OAuth2＆＃34;授权代码授权＆＃34 ;。在这种情况下，您还需要一个需要自己实现的授权服务器。

授权服务器的任务是建立最终用户身份（请注意：这是OAuth2中指定的不如何完成此操作，取决于您;您可以联合其他人IdP，您可以要求输入用户名和密码，...）然后决定用户在访问API时获得的权利（=＆＃34;范围＆＃34;）。这完全取决于您，以及您的业务逻辑的一部分如何决定这一点。

流程如下：

  1. 您（重新）将用户定向到授权服务器的网页
  2. AS对用户进行身份验证（通过任何方式）并决定范围（通过其他方式）

  3. AS在两个不同的层面与Kong进行对话

    • 通过Kong Admin API，检索所需API的provision_key
    • 通过[/your_api]/oauth2/authorize端点，用于获取包含授权码的重定向URI，在经过身份验证的用户及其范围（scope和authenticated_userid）的上下文中;要调用此结束点，您需要response_type=code，client_id，client_secret，provision_key，authenticated_userid（适用的任何内容）以及scope （如果你想使用它，也需要在API上定义范围）

  4. 如果成功，AS会使用Kong返回的重定向URI重定向回Web应用程序

  5. 网络应用使用[/your_api]/oauth2/token
    6. 使用client_id，client_secret和code调用Kong的grant_type=code终点

    现在，您将拥有一个访问令牌（和刷新令牌），可让您的Web应用程序代表经过身份验证的用户访问API 。

    授权服务器必须由您实施;这不是非常复杂，但您仍需要确保知道如何验证用户，和/或如何将其委托给其他IdP。

    具有最终用户上下文的公共客户端（单页应用程序）

    如果您需要从单页应用程序（例如Angular应用程序或类似应用程序）访问API，您应该查看OAuth2＆＃34; Implicit Flow＆＃34;，这是一个比授权更简单的流程代码授予，但有其他缺点，例如无法使用刷新令牌。

    此流程按以下方式工作：

    1. 就像授权代码授权一样，您将用户重定向到授权服务器
    2. AS建立身份并决定范围（再一次，这取决于你）
    3. AS调用授权端点，就像授权代码授权一样，但这次使用response_type=token
    4. Kong，如果成功，将返回已包含令牌的重定向URI
    5. AS使用来自Kong的重定向URI重定向回SPA，该URI在＆＃34;片段＆＃34;中具有访问令牌。的URI（例如https://your.app.com/#access_token=<...>&token_type=bearer&...）

      6. 您的SPA现在可以使用访问令牌来访问API，就像授权代码授权一样，代表经过身份验证的用户。

      这种方法的缺点是你不能轻易刷新令牌，并且它比授权码授权的安全性稍差。但是在处理SPA时，没有很多其他安全的方式来委托访问它。

      移动应用程序

      我想在这里触及的最后一个场景是移动应用程序，如Android或iOS应用程序。对于这些，最后的OAuth2流程，＆＃34;资源所有者密码授予＆＃34;可以使用。简而言之，使用此授权，您可以将实际用户凭据（用户名和密码）与访问令牌和刷新令牌进行交换，这样您就不必在移动设备上存储用户名和密码，而不是暂时存储。

      此流程还需要授权服务器能够与Kong一起使用，虽然这次不太复杂，即使您必须实现额外的token端点（除了Kong之外），在香港文件中没有理想的描述。

      它是这样的：

      1. 移动应用使用其client_id（不是秘密，不应将秘密与应用程序一起部署），用户名和密码来调用授权服务器的令牌端点
      2. 授权服务器检查用户名和密码（无论如何，你知道故事）并决定范围（...）
      3. AS再次与Kong讨论管理API，获取所提供的client_secret的{​​{1}}和所需API的client_id

      4. AS发出对Kong的令牌终点provision_key的调用，如下所示：

        curl --insecure -d＆＃39; grant_type = password＆amp; provision_key =＆lt; ...＆gt;＆amp; client_id =＆lt; ...＆gt;＆amp; client_secret =＆lt; ...＆gt;＆amp; authenticated_userid = LT; ...＆GT;＆安培;范围=＆＃39; HTTPS：//：8443 / your_api /的oauth2 /令牌

        5. 请注意，此次通话不包含用户名和密码;那些不属于这里的人，你必须根据自己的身份来源检查用户名和密码，Kong不会帮助你。

        此调用应返回访问令牌和刷新令牌，然后您可以在设备上存储（尽可能安全）。这些替换用户名和密码，不得存储在设备上。访问令牌可以与其他最终用户上下文流（授权代码授予，隐式授权）一样用于代表经过身份验证的用户访问API 。

        我希望这有助于揭示如何在OAuth2中使用Kong。这很棘手且很复杂，但Kong真的可以帮助你做到这一点，并将你的担忧分开。

相关问题
最新问题