我正在使用身份服务器4，已按照本教程进行操作，因此我有一个api，mvc客户端，控制台客户端和js客户端。
我也看到了这个博客，它可能与我所需要的接近： https://medium.com/all-technology-feeds/testing-your-asp-net-core-webapi-secured-with-identityserver4-in-postman-97eee976aa16
我需要的是一个api，客户端可以在其中访问数据，但是首先，他们需要进行身份验证。
我们还有控制台客户端，它也很接近我的需求。
此示例的唯一问题是，在两种情况下，客户端都知道秘密。但是在我们的例子中，多个客户端应该使用相同的api，并且如果它们都具有相同的机密，则它们可以代表彼此登录，但是我不想拥有不同的机密。
所以我想我可以做的是创建一个使用用户名和密码并返回令牌的api。但是我不确定这是做事的正确方法吗？感觉就像资源所有者流，如果我正确的话，不应该将其用于面向客户端的API。但是在那种情况下，我应该怎么走呢？
谢谢
答案 0 :(得分：1)
似乎有些混乱。请允许我简要介绍一下。首先是terminology：
资源是您要使用IdentityServer保护的东西-用户的身份数据或API。
Client credentials：最简单的授予类型，用于服务器到服务器的通信-令牌始终代表客户端而不是用户请求。
现在有关认证。客户端在IdentityServer端点上请求令牌。当您将客户端与客户端凭据流结合使用时，您将需要一个clientid + secret。秘密是真正的秘密，仅应由客户知道。您不能在此处使用相同的秘密。与用户相比似乎合乎逻辑，他们也不共享相同的密码。
这与资源所有者流很近，但是客户端无法以用户身份登录。为此，您需要另一个流程，例如 hybrid 流程。在这种情况下，客户端代表用户 登录。区别在于令牌中存在“ sub”声明（用户的ID）。
在这种情况下，客户端是您的应用程序：控制台或mvc。前者仅在必须使用机密的情况下才支持客户端凭据，而后者则支持混合流，其中可以省略机密：
在某些情况下，客户需要通过 identityserver，例如
- 在令牌端点请求令牌的机密应用程序（也称为客户端）
- 自省端点验证参考令牌的API
Api是您要保护的资源。 Api永远不会验证用户或客户端。这是由IdentityServer完成的。它仅验证令牌（使用IdentityServer4.AccessTokenValidation包）。为此，它具有自己的秘密，只有Api才能知道。
为了授予客户端访问资源的权限，您需要在IdentityServer的配置中将范围添加到客户端。然后允许（不是必需的）客户端请求授予访问资源的令牌。
同样，Api与身份验证无关。它也没有绑定到一个客户端。多个客户端可以访问资源。您要做的就是将范围添加到应该有权访问资源的每个客户端中。
因此，对于客户和资源知道他们的秘密的确没有什么反对。您无需更改任何内容。您要做的就是选择合适的流程。