我在工作场所中有一个Identity Server 4.0实现。除了隐式和身份验证代码流之外，我们还计划使用Client Credential流进行API到API的调用身份验证。
很少有API需要记录谁调用它的日志（调用API的名称）。我做了很多挖掘工作，但找不到令人信服（和安全）的方法。
据我了解，在Client Cred流程中，客户端将仅使用客户端机密访问IDS。显然，这将使IDS几乎不可能知道谁在调用它。我对吗？有什么方法可以了解客户（以便可以向令牌添加一些id声明）？
欢迎提出任何建议。
编辑： 为阐明我的问题并更好地解释我对这种特殊的OAuth流程的理解：
好的，让我说清楚。假设API X必须调用APIY。
它遵循以下顺序： （1）X前往IDS，其中包含Client-Id和Client-Secret。 （2）IDS验证Client-Id和Secret并向X发出访问令牌 （3）X使用给定的访问令牌调用Y
在上面的步骤（2）中，根据OAuth 2.0的客户端凭据流程，除了X要求提供的Client-ID和Client-Secret外，没有其他内容。现在，如果API Z想要与Y对话，它将使用相同的Client-ID和相同的Secret转到IDS。
如果IDS无法识别身份验证呼叫是来自X还是Z，那么如何在已发行令牌中添加任何其他声明？
因此，Y知道呼叫是来自X还是Z的唯一另一种方法是X或Z告诉自己（在标头，URL或发布数据中）自己（这使通过客户端授权的整个目的无效了）信誉流）。请记住，我的问题与认证无关。
答案 0 :(得分：3)
有两种方法：要么针对每个实例使用唯一的客户端凭据（API X，API Z是单独的客户端），要么使用相同的clientid和/或将其留给客户端以提供信息。
使用唯一的clientid，您可以在ClientClaims表中将有关客户端的信息作为声明添加，例如Claim（'ApiName'，'apiname'）。
此声明已添加到访问令牌中，并且可以在接收API中使用。
在这种情况下，客户端凭据用作ID /密码，从而允许客户端“登录”。
另一种方法是对所有API使用相同的clientid。现在由客户提供信息。
一种情况可能是发出可用于识别客户端的apikey，例如一个guid。您可以将其与每个呼叫一起发送。
此外，还有一个替代方法，添加一个自定义端点。不要使用客户端凭据，而要实现自己的端点。
使用extension grants，您可以请求所需的信息并将其转换为有效的访问令牌。
通过 ExtensionGrantValidationContext 对象，您可以访问传入的令牌请求-众所周知的验证值以及任何自定义值（通过Raw集合）
也许用APIKEY“扩展”客户端凭据流是一个主意。