JWT Algの確認と変更方法

Question

私はWebAPI用のJWTを作成して使用するためにASP.Net OpenID Connect Serverプロジェクト（ASOS）を使用しています。

これで、トークンに対してさまざまな検証を実行しようとしています。

"alg"タイプを確認する方法を知りたいと思います。 "none"を渡すことができる問題を認識しています。つまり、誰かがトークンを偽造することができます（問題がある特定のライブラリであるかどうかわかりません。しかし、私がそのチェックを行っていれば、私はもっと安全だと思います）。

また、JWTの整合性を確認するにはどうすればよいですか？

現在のところ、私のトークン発行者とWebAPIは同じプロジェクトにありますので、自動的に私にチェックされていると思いますか？それとも全くチェックされていないのですか？

私が理解していることは、何も指定しなければ、ディスク上に何らかの署名証明書が追加されていることです。

署名証明書を提供すると自動的に「alg」プロパティが更新されますか？

トークン発行者が1台のサーバーにあり、WebAPIが完全に異なる場合はどうなりますか？トークンが私のトークン発行者から来たものであり、干渉されていないことを検証するにはどうすればよいでしょうか。

おそらく私は手動で証明書を追加してから、何とか公開鍵を共有する必要がありますか？ その場合、誰かがJWTの整合性をチェックする公開鍵を追加すべき場所を指摘できますか？ おそらくこの部分はOpenIDConnect Server（ASOS）よりもasp.net Coreについてですか？

ありがとうございました。

Answer 1

"alg"タイプを確認する方法を知りたいと思います。

あなたが探しているalg値が含まれているJWTのヘッダを読み取ることjwt.ioのようなツールを使用することができます。

"none"が渡される可能性があるので、誰かがトークンを偽造する可能性があることに気付いています（問題のある特定のライブラリのみかどうかわかりません。一般的にはチェックするのが良い練習ですが、私がそのチェックを行っていればもっと安全だと思います）。

ASOSは、JWTトークンを生成するためにIdentityModel（Microsoftが開発したフレームワーク）に依存しています（this other answer for more informationをご覧ください）。 AFAIK、あなたが言及しているセキュリティバグの影響を受けていませんでした。

自分で試してみるには、jwt.ioを使用してalgヘッダーの値を変更し、その結果のエンコードされたJWTをAPIに送信します。

また、JWTの整合性を確認するにはどうすればよいですか？

現在のところ、私のトークン発行者とWebAPIは同じプロジェクトにありますので、自動的に私にチェックされていると思いますか？それとも全くチェックされていないのですか？

トークン発行者が1台のサーバーにあり、WebAPIが完全に異なる場合はどうなりますか？トークンが私のトークン発行者から来たものであり、干渉されていないことを検証するにはどうすればよいでしょうか。

おそらく私は手動で証明書を追加してから、何とか公開鍵を共有する必要がありますか？その場合、誰かがJWTの整合性をチェックするために公開鍵を追加すべき場所を指摘できますか？おそらくこの部分はOpenIDConnect Server（ASOS）よりもasp.net Coreについてですか？

JWTベアラミドルウェアを使用すると、自動的に完了します。そのためには、ASOS' JWK set endpoint（デフォルトでは、/.well-known/jwks）で公開されている公開署名鍵を直接ダウンロードします。ここで

は例です：

私の理解では、あなたが任意の（私はそれを読んところわからない）を指定しない場合は、署名資格のいくつかの種類がディスクに自動的に追加されていることです。

これは最新の公式バージョン（beta6）でも当てはまりますが、この機能は次のバージョンでは削除されます。 X.509証明書を登録するか、一時的な署名キーを使用することをお勧めします（開発中）。そうしないと例外がスローされます。

署名証明書を提供すると自動的に「alg」プロパティが更新されますか？

はい。 ASOSはネイティブに対称キーとRSAキーの両方をサポートします。たとえば、options.SigningCredentials.AddKey(...)を呼び出すときにSymmetricSecurityKeyを使用すると、RS256（RSA-SHA256）の代わりにHS256（HMAC-SHA256）が返されます。 Addオーバーロードを使用してSigningCredentialsインスタンスを受け入れることで、追加のアルゴリズムを提供できます。