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

Question

我正在尝试使用 Kong 的 oauth2 授权插件在顶部 kong 上添加一个 API。我按照他们的Kong 文档遵循的步骤：

• 创建 API 并添加 oauth2 插件
• 创建消费者
• 创建应用程序

我从上述步骤中获得了 client_id、client_secret、provision_key 等，但我想知道是否需要在我的一端创建 oauth2 服务器或 kong 本身在他们的一端配置它，我们只需要调用他们的端点。我正在 Laravel 中构建我的 API。

Answer 1

我认为我们对 Gitter 进行了简短的讨论，并且我已经说过这取决于您的用例。我将简要介绍典型用例，以及您需要哪种附加实现。

机器对机器通信

如果您需要两个系统从后端相互通信，并且这些系统相互信任，您可以使用 OAuth2“客户端凭据流”。在这种情况下，不涉及“最终用户”身份，仅涉及明确相互信任的两个系统。

对于这种情况，Kong 是您需要的一切——您只需使用您的客户端 ID 和 Secret向 Kong 的 API 令牌端点（<address of kong>:8443/your_api/oauth2/token对于基于 URI 的路由，或者fqdn.of.kong:8443/oauth2/token如果您使用基于主机的路由）请求访问令牌，您将获得一个背部。

例子：

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“授权代码授予”。在这种情况下，您还需要一个您需要自己实现的授权服务器。

授权服务器的任务是建立最终用户身份（请注意：这在 OAuth2 中未指定如何完成，由您决定；您可以与其他一些 IdP 联合，您可以要求提供用户名和密码， ...) 然后决定用户在访问 API 时获得哪些权限（=“范围”）。这完全取决于您，以及您的业务逻辑的一部分如何决定这一点。

流程是这样的：

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

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

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

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

5. Web 应用程序使用,和调用 Kong 的[/your_api]/oauth2/token端点，使用client_idclient_secretcodegrant_type=code

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

授权服务器必须由您实现；这并不是非常复杂，但您仍然需要确保您知道如何对用户进行身份验证，和/或如何将其委托给其他一些 IdP。

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

如果您需要从单页应用程序（例如从 Angular 应用程序或类似应用程序）访问 API，您应该查看 OAuth2“隐式流程”，这是一个比授权代码授权更简单的流程，但还有其他缺点，比如不能使用刷新令牌。

此流程按以下方式工作：

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

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

这种方法的缺点是您不能（那样）轻松刷新令牌，并且它的安全性比授权代码授予要低。但是在处理 SPA 时，没有很多其他安全的方式来委派对它的访问。

移动应用

我想在这里提到的最后一个场景是移动应用程序，例如 Android 或 iOS 应用程序。对于这些，可以使用最后一个 OAuth2 流程，即“资源所有者密码授予”。简而言之，通过此授权，您可以根据访问令牌和刷新令牌交换实际用户凭据（用户名和密码），这样您就不必在移动设备上临时存储用户名和密码。

此流程还需要一个授权服务器才能与 Kong 一起使用，尽管这次不那么复杂，即使您必须实现一个额外的token端点（除了 Kong 拥有的一个端点之外），这在 Kong 中没有理想地描述文档。

它会是这样的：

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

4. AS 向 Kong 的令牌端点发出调用[/your_api]/oauth2/token，如下所示：

   curl --insecure -d 'grant_type=password&provision_key=<...>&client_id=<...>&client_secret=<...>&authenticated_userid=<...>&scope=' https://:8443/your_api/oauth2 /令牌

注意，这个调用并没有包含用户名和密码; 那些不属于这里的，您必须根据自己的身份来源检查用户名和密码，Kong 不会帮助您。

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

将 Kong 与 OAuth2 结合使用是一件棘手且复杂的事情，但 Kong 确实可以帮助您做到这一点并分离您的顾虑。