请解释一下OpenIddict中Applications表的用途。 我正在关注这个很棒的教程http://capesean.co.za/blog/asp-net-5-jwt-tokens/ 它完美地运作。我误解了为OpenIddict添加的Applications表的功能。
目前，我的前端（Angularjs）+后端（带有ASP.NET Core和OpenIddict的Web.API）在一台服务器上运行良好。前端接收令牌并在请求中使用它。后端生成令牌并对其进行评估。一切都很好，但Applications表没有任何记录。
感谢。
答案 0 :(得分：5)
Applications表包含允许使用您的身份服务器的OAuth2 client applications。
使用authorization code或implicit等交互式流时，必须添加新条目，因为客户端应用程序必须发送有效的client_id：如果{{{}}，OpenIddict将拒绝授权请求缺少1}}或者与您完全信任的应用程序（即存储在client_id表中的应用程序）不对应。
同样的规则适用于client credentials grant，这也需要有效的Applications。
相比之下，有一种情况是发送client_id不是强制性的：使用resource owner password credentials grant时，正如您提到的博文中所示。
specification明确声明发出令牌请求的客户端应用程序可以发送其client_id，这意味着此参数不是必需的。
客户端可以使用＆＃34; client_id＆＃34;请求参数在向令牌端点发送请求时标识自己。
如果无法从令牌请求中提取client_id，则OpenIddict无法确定应用程序的身份。在这种情况下，将跳过与client_id相关的检查，并在不使用client_id表的情况下处理请求。这就是为什么您的应用程序无需填充Applications表即可运行的原因。
虽然对于日志记录有用，但发送Applications并不会使client_id请求更安全，因为每个人都可以通过重复使用相同的grant_type=password来模拟应用程序，除非应用程序被声明为机密，并被分配了客户端凭据（仅读取＆＃34;服务器端应用程序＆＃34;）。在这种情况下，恶意调用者无法在不知道client_id的情况下发送有效的令牌请求。
在OpenIddict中，还有一种情况是添加显式应用注册很有用：使用introspection middleware验证访问令牌（而不是JWT承载中间件）。
作为required by the specification，调用者必须进行身份验证才能使用内省端点：如果OpenIddict无法在client_secret表中找到相应的条目，则该请求将被拒绝，并且内省中间件将永远不会工作