使用 OpenID Connect 保护 Web 应用程序和 API答案

【问题标题】：Securing web app and api using OpenID Connect使用 OpenID Connect 保护 Web 应用程序和 API
【发布时间】：2019-01-03 11:34:02
【问题描述】：

我不想再推出自己的安全性，并且正在考虑将 OpenID Connect 与我的 c# API 和 AngularJS 应用程序一起使用。我可以让所有这些都正常工作。但是，我的大脑似乎无法理解如何为这两种用例正确保护我的 API：

用例 1：AngularJS SPA

我的 AngularJS 应用程序连接到我的 API 并发送一个不记名令牌来识别用户并包含用户声明。这个很简单，而且有大量的文档。

用例 2：API 到 API

一些客户希望直接访问我的 API，而不是通过我的 AngularJS 应用程序。在这种情况下，我认为我可以使用客户端 ID/Secret 进行基于 toen 的身份验证，这很好，除非我对使用客户端 ID/秘密的用户一无所知。可能有 10 个用户使用调用我的 API 的同一个自定义 API。如何通过 API 调用获取用户信息？我见过其他人使用 API 密钥，然后他们查找用户并创建 JWT，但我认为可能有更简单的方法。有什么想法吗？

【问题讨论】：

要回答您的问题：用例 2，我需要更多上下文。 a) 您是否需要知道授权访问 API 的用户是谁？ b) APP和用户是一对一还是一对多？ c) 谁在维护用户凭证和注册表？ d) 为什么这些客户想要“直接”访问您的 API？他们是否想要避免用户授权后续访问的单一设置？

标签： access-token openid-connect

【解决方案1】：

API 到 API 身份验证的全部意义在于没有用户上下文。或者，在这种情况下，用户就是试图访问您的 API 的机器。然后，您需要围绕它设计您的授权逻辑并实现基于范围的权限。或者，您的选择是使用您提到的 api 密钥，或者如果您希望 OAuth 协议在 api 到 api 场景中具有用户上下文 - 那么 ResourceOwnerCredentials 流是一个选项。

【讨论】：

ROPC 绝对不是这里的选项。此外，支持不存在用户（这是 API 的主要原因之一）和无用户上下文是完全不同的事情。有许多 API 需要用户上下文，因为通常情况下 API 需要知道在谁的授权下授予访问权限。

【解决方案2】：

API 到 API 通信

您可以使用通过 OAuth 2.0 定义的 Client Credentials Grant。这不需要您拥有最终用户凭据。现在这不是 OpenID Connect。 OpenID Connect 需要最终用户的参与并绑定到身份验证。另一方面，OAuth 2.0 是关于授权，检查实体是否可以访问资源。

通过客户端凭据授予，您的身份服务器将为特定客户端颁发令牌。因此，您的 API 之一成为客户端（资源使用者）。从请求处理 API 端点，您可以接受有效令牌并返回资源。

如果您需要来自请求处理 API 的细粒度访问控制，您将需要使用 token introspection 来识别此令牌的颁发对象。在这种情况下，它将识别特定的客户身份并在其上执行逻辑。您可以查看token introspection response来识别此类详细信息。

或者，访问令牌可以以 JWT 的形式出现。如果是这种情况，它们可以被视为自包含令牌，因此验证很简单。

【讨论】：

这几乎没有回答 OP 的问题，实际上包含不准确的内容，例如令牌内省，这些内容无关紧要，也无济于事，因为令牌已经通过适当的声明识别出它是发给谁的，而内省只允许重新验证令牌确实有效。
@VidmantasBlazevicius 注意你在说什么。如果访问令牌不透明，您如何在访问令牌中找到声明？好吧，我相信您还没有阅读并理解令牌自省端点的用途。你是从 OpenID 连接的角度说话，这与 OP 谈论客户端到客户端（API - API）通信无关
@VidmantasBlazevicius 也请解释一下你是如何做到的“令牌已经通过适当的声明识别出它是发给谁的”？如果知道您的方法，我将非常感激。
通常通过 client_id 声明来识别它已发给哪个客户端或 openidc 流的主题 ID 声明。也许您正在谈论向其发送身份令牌并取回用户声明的 UserInfo 端点？自省实际上通常是为了验证令牌是否有效和活跃。
@VidmantasBlazevicius 好吧，您的解释是关于授权服务器。它可以通过 client_id 参数验证客户端。但是一旦你拿到了访问令牌，你会如何说它属于哪个客户呢？特别是当访问令牌不透明时。这就是令牌内省出现的地方。此外，使用访问令牌调用 userinfo 端点，用于识别最终用户详细信息。但是对于 API 到 API 的通信，最终用户不是强制性的。这就是这里可以使用 OAuth 2.0 的原因。请仔细阅读规范以了解问题的核心。