我不想再承担自己的安全性，并且正在考虑将OpenID Connect与我的c＃API和AngularJS应用结合使用。我可以使所有工作正常进行。但是，我的大脑似乎无法理解如何针对两种用例正确保护我的API：
使用案例1：AngularJS SPA
我的AngularJS应用程序连接到我的API，并发送一个标识用户的承载令牌，并包含用户声明。这很容易，上面有大量文档。
用例2：API到API
一些客户希望直接访问我的API，而不是通过我的AngularJS应用访问。在这种情况下，我以为我可以将客户端ID /秘密用于基于Toen的身份验证，这很不错，除了那时我不知道使用客户端ID /秘密的用户。可能有10个用户使用与调用我的API相同的自定义API。如何通过API调用获取用户信息？我见过其他人使用API密钥，然后他们会查找用户并创建JWT，但我认为可能会有更简单的方法。有什么想法吗？
答案 0 :(得分：0)
API到API身份验证的全部要点是没有用户上下文。或者，在这种情况下，用户就是尝试访问您的API的计算机。然后，您需要围绕该主题设计授权逻辑并实现基于范围的权限。另外，您的选择是使用您提到的api键，或者如果您想在api到api方案中使用带有用户上下文的OAuth协议-那么ResourceOwnerCredentials流是一个选项。
答案 1 :(得分：0)
API到API的通信
您可以使用通过OAuth 2.0定义的 Client Credentials Grant 。这不需要您具有最终用户凭据。现在，它将不再是OpenID Connect。 OpenID Connect需要最终用户参与并绑定到身份验证。另一方面，OAuth 2.0与授权有关，检查实体是否可以访问资源。
使用“客户端凭据授予”，您的身份服务器将为特定客户端颁发令牌。因此，您的一种API成为了客户端（资源使用者）。从请求处理API端点，您可以接受有效的令牌并以资源作为响应。
如果您需要通过请求处理API进行细粒度的访问控制，则将需要使用token introspection来标识此令牌的颁发者。在这种情况下，它将是特定客户端身份的标识，并在其之上执行逻辑。您可以检查 token introspection response 来识别此类详细信息。
或者，访问令牌可以JWT的形式出现。如果是这种情况，则可以将它们视为自包含令牌，因此验证非常简单。