OpenIddictのアプリケーションテーブルの使い方を教えてください。 私はこの素晴らしいチュートリアルに従いますhttp://capesean.co.za/blog/asp-net-5-jwt-tokens/ それは完全に動作します。私はOpenIddictのために追加されたアプリケーションテーブルの機能の誤解を持っています。OpenIddictのApplicationsテーブルの使用方法
現在、フロントエンド（Angularjs）+バックエンド（ASP.NET CoreおよびOpenIddictを使用したWeb.API）は、1つのサーバーで正常に動作します。フロントエンドはトークンを受け取り、要求に使用します。バックエンドはトークンを生成し、トークンを評価します。すべていいですが、アプリケーションテーブルにはレコードがありません。
ありがとうございました。
Applicationsテーブルには、IDサーバーの使用が許可されているOAuth2 client applicationsが含まれています。 client_idが欠落しているかに対応していない場合は認証要求を拒否しますOpenIddict：authorization codeまたはimplicitのようなインタラクティブなフローを使用している場合、クライアント・アプリケーションは、有効なclient_idを送信するために持っているように新しいエントリを追加する
、必須ですあなたが完全に信頼するアプリケーション（すなわち、Applicationsテーブルに格納されているアプリケーション）。
にも同じ規則が適用され、有効なclient_idも必要です。 resource owner password credentials grantを使用しているとき、あなたが言及したブログ記事で示したように：これとは対照的に
は、client_idを送信することは必須ではありません一つのケースがあります。
specificationは、トークン要求を行うクライアントアプリケーションがclient_idを送信してもよいと明示的に述べています。つまり、このパラメータは必須ではありません。
クライアントは、トークンエンドポイントに要求を送信するときに、 "client_id"要求パラメータを使用して自身を識別することができます。
トークン要求からclient_idを抽出できない場合、OpenIddictはアプリケーションのIDを判断する方法がありません。この場合、client_id関連のチェックはスキップされ、Applicationsテーブルを使用せずに要求が処理されます。そのため、Applicationsテーブルにデータを読み込まなくてもアプリケーションが機能します。ログ記録の目的のために
便利なものの、誰もが同じclient_idを再使用して、アプリケーションを偽装することができ、アプリケーションが機密として宣言された、クライアントの資格情報を割り当てられた場合を除きclient_idを送信することは、grant_type=password要求はより安全にしません。 （「サーバーサイドアプリケーションのみ」を参照）。この場合、悪意のある発信者はclient_secretを知らなくても有効なトークン要求を送信できません。 （代わりにJWTベアラミドルウェアの）アクセストークンを検証するintrospection middlewareを使用する場合：OpenIddictで
は、明示的なアプリの登録を追加することは有用である場合があります。
required by the specificationとして、発信者がイントロスペクションのエンドポイントを使用することを認証する必要があります：OpenIddictはApplicationsテーブル内の対応するエントリを見つけることができない場合、要求は拒否され、イントロスペクションミドルウェアは動作しません。
詳細な回答ありがとうございます。 – Serg