私の質問は正確には「情報をトークン検証がWEBAPI側で管理されているか？」実装JWT認証
すなわち
Aその）各ユーザに固有の秘密鍵はありますか？
B）はいの場合、これらはどこに保存されていますか？
C）キーは、セッションごとに新しく生成されると言っている人もいます。
これはやり方がどのように考えられるかを指定します。
1）アプリケーションはユーザー名とパスワードを送信してApi（WebApiの一部）にログインします。
2）Apiはデータベースからの資格情報を検証し、JWTを作成します。
3）header = {'type'： 'JWT'、 'alg'： 'HMAC'}という標準ヘッダーが作成されます。
4）次に、クレーム/ペイロードセクションが作成され、そのユーザーの一意の識別子が埋め込まれます。
5）次に、（header.claims）はBase64URLEncodedであり、このエンコードされた情報と秘密鍵をパラメータとし、HMACアルゴリズムを使用して署名するメソッドに渡されます。
6）ヘッダー、クレーム、署名（前の手順で取得したもの）をピリオドで連結し、JWTを取得します。
7）このJWTは、アプリケーションに送り返されます。
8）次のリクエスト中、アプリケーションはリソースにアクセスしようとしているときにこのJWTをWebApiに返します。
9）WebApiは、JWTをチェックし、バックヘッダ、クレームをデコードします。
10）WebApiは、このユーザーがデータベースに存在するかどうかを確認し、要求から一意のユーザー識別子を取得します。
11）ユーザが見つかった場合、ユーザに関連付けられた秘密鍵が取得されます。この秘密鍵は、ユーザに対してデータベースにも格納されます。 （登録時に生成されたGUIDのみ）
12）トークンが期限切れになっているかどうかをチェックします。この情報はクレーム/ペイロードで 'exp'日付時刻などで利用できます。
13）トークンがまだ期限切れではないと仮定すると、WebApiはヘッダーとクレーム/ペイロードを取り、前回の秘密鍵と同じ方法でJWTを生成します。
14）こうして作成されたJWTは、アプリケーションによって送信されたJWTと照合されます。両方が一致（署名）している場合、トークンは正確であり、本当にWebApiによってこのユーザに発行されます。
15）WebApiはクレームIDを設定し、リソースへのアクセスを許可します。
データベースのユーザ識別子を探すたびに、WebApiはユーザの秘密鍵を保持してログインする際に静的なユーザアレイを維持することもできます。したがって、この配列から情報を取得できます。ユーザーがログアウトすると、そのユーザーは静的アレイからも削除されます（アレイ管理は今私が取り入れたいものではありません）
これは実装の考え方です。
私はそれが他の方法でどのように逸脱したのか知りたいですか？私は別の認証サーバーを作成したくありません。私は、WebApiがこれを簡単かつもちろん安全な方法で管理したいと思っています。私は、JWTを検証して検証するために、.Net 4.5用にMicrosoft JwtSecurityTokenHandlerを使用します。