私はEntityFramework IdentityServer3ソリューションに厳密に従いながら、IdentityServer3アプリケーションを実装しています。しかし、問題はこれです...IdentityServer3では、トークンとクレームをカスタムTokenHandleStore実装でどのようにリンクする必要がありますか？
トークンオブジェクトが保存されるとき、トークンが保存されたときにクレームが何らかの形でトークンにリンクされていない場合、クライアントがリソースサーバーを呼び出すと必然的に不正な要求が発生します。トークンに元々添付されていたクレームが保存されていないため、トークンがデータベースから読み込まれたときにこれが発生します。
IdentityServer3のメモリー内のソリューションにはオブジェクトがメモリー内に残っているため、Tokenオブジェクト内のクレームのリストはトークンに「接続」されたままであるため、この問題は発生しません。インメモリソリューションについては、hereを参照してください。
保存時にトークンにクレームをリンクしないと、データベースから取得された参照トークンを検証できません。
トークンを保存するときにクレームとトークンの関係を保存する必要があると思います。ただし、コードのその時点で（hereを参照）、クレームがスコープクレーム、クライアントクレームまたはユーザークレームであるかどうかを簡単かつ確実に判断できないため、問題があります。
適切なクレームテーブルにトークンをリンクする参加/リンクテーブルにレコードを正しく挿入するにはどうすればよいですか？ ScopeClaimsテーブル、ClientClaimsテーブルがあり、UserClaimsテーブルが存在する可能性があります。通常、特定のトークンに関連付けられたクレームは、クライアント、スコープ、およびユーザークレームが混在しています。
トークンセーブを処理してクレームを維持するための推奨事項を教えてください。
更新 ジョンが指摘したように、EF溶液は、トークンが逆シリアル化プロセスを照会されるので、保存時における全トークンの目的は特許請求の範囲およびトークンであった他のフィールドを再水和こと生じるシリアライズ。このアプローチに従うと、ジョインテーブルなどを使用してクレームをトークンにリンクする方法を見つけ出す必要はありません。私は当初この重要な機能を見落としました。
JSONは余分なクレームをシリアル化し、別のブロブとして追加します。 –
@JohnKorsnesそれは間違いなく動作します。私は行って、EFアプリケーションのコードを見て、トークンが保存される直前にトークンオブジェクト全体をシリアライズしていることがわかります。したがって、暗黙のうちにこれらの主張を保持しています。私はこれまでにそれを理解していませんでした。これを回答として提出すれば、私はそれを受け入れます。ありがとう！ –
ええ、EFの実装を見ていることは、良いアプローチです - それは著者によって維持されています:)私はまた、私の実装で何をしているかに従います。 –