我们目前的设置是

我们希望为客户（即第三方客户）提供具有受限访问权限的API（单独的设置/声明子集）。这些客户端大多是非交互式脚本，可以下载数据。

这意味着我们不能使用（偶尔）需要用户交互的任何流程。个人访问令牌，例如github或其他一些生成一次，需要长时间重用 API密钥或令牌。

长令牌生存期不会成为安全问题，因为令牌应该只允许访问一些只读API并且只能访问该客户的数据 - 因此处理令牌的责任落在客户身上。

客户应该能够根据其声明创建和撤销此类API访问令牌。有些用户可能只声称访问某些API。

如果我们以后可以防止用户因许可要求而为多个客户端重复使用相同的令牌，那将是一件好事，但这可能是一个全新的问题

我怎么能实现这个目标？

我考虑通过自定义授权执行此操作，类似于委托授权：用户使用app调用asp.net核心API，该API使用该自定义授权执行auth，并保留该令牌某个地方（只是数据库中的一个普通表，里面只有客户api-only令牌？我不确定）并向用户显示 - 后来也可以从存储中检索它。

我正在考虑通过我们的API进行“委托” - 身份验证，这样我们就不会将秘密泄漏到Angular应用程序中。

我认为我们应该能够通过自定义授权获得长期访问令牌或至少刷新令牌。

2017-12-12我觉得我能解决它

我们想要一个用户在我们的应用程序中生成某些东西的过程（即通过我们的客户端），这个某些东西以后可以被用户的第三方客户端用来访问API - 或请求访问令牌，然后访问API。

我们希望此访问权限与用户相关联。这包括 - 禁用用户 - 锁定 - 特定索赔（例如租户）

这不适合直接发出访问令牌的解决方案，因为即使用户被禁用或锁定，令牌仍然有效。这意味着我们无法使用自定义授权或IdentityServerTools直接发放令牌。

因此，我们应该使用客户端凭据授权或类似的东西，因为这可能会产生新的，短期的访问令牌。

用户实际上生成了一个新客户端，该客户端预先填写了来自用户的索赔（例如租户 - 这是不可变的）并且具有与用户对应的声明。这是透明的。密码应由用户提供，并提供更改选项。我们只存储用户和已发布的客户端ID之间的关系，没有密码。
我们必须创建一个类似于客户端凭据的自定义授权，但也会检查相应的用户是否处于活动状态等（我认为应该可以通过注入UserManager来实现）
结果访问令牌的生命周期很短，与我们的API的交互预计会很短暂。

假设写这样的补助金是安全和容易的，我们应该能够涵盖我们需要的一切。当然，我可能完全忽略了一些事情：）