JWTとクライアント証明書
異なるクライアントアプリケーションによって接続されているトランザクションサーバーがあります。要件は、クライアントアプリケーションがトランザクションサーバーと通信するための安全な認証手段を持つことです。検討されている2つのソリューションは、JWTとクライアント証明書です。
あなたの意見では、セキュリティと効率の観点から、どちらのオプションの長所と短所は何ですか。この質問は少し一般的であり、具体的には、これらのコンポーネントがまだ開発中であることを考慮して、特定のソリューションに移る前に、より一般化されたアイデアを得たいためです。
どちらかの技術を使用したことのある人からのアドバイスはいただければ幸いです！
少しコンテキストについては、JWTトークンベースの認証に重点的に取り組んできましたが、クライアント証明書の経験がほとんどないため、私の回答は（情報および意見の観点から）JWTに偏っています。
JWTトークン長所：
- 簡単に生成（または再生成）でき、失効した日付/時刻を含めて、盗まれたJWTトークンによる被害を軽減できます。
- ペイロードに「クレーム」を含めて、追加情報、おそらくクライアントデバイスの役割、または文字通り必要なキーと値のペアを運ぶことができます
- 一度エンコードされると文字列になるため、簡単に転送できます
- 大部分の言語には、ほとんどの面倒な作業を行うためのライブラリーがあります。参照： ライブラリページ
JWTトークンの短所：
- 通常、これらをディスペンスするには、認証サーバーまたはトランザクションサーバー上のモジュールが必要です。
- クライアントの認証方法によっては、状況が非常に複雑になったり、不可能になったりすることがあります。ユーザーがログイン資格情報を持っている限り、JWTトークンを送信する前にクライアントを最初に認証するために使用できる資格があります。それ以外の場合は、クライアントの信頼性を最初に確認するいくつかの手段が必要です
クライアント証明書の長所：
- 単一の証明書をインストールする必要があります（構成時に？依存します）
- JWTと同じ方法で証明書を作成および配布するためのサーバー側コードは必要ありません
クライアント証明書の短所：
- 証明書が侵害された場合、その証明書が有効である限り、再生スタイルの攻撃に使用できます（侵害されていることが発見されない場合、ブラックリストに登録される可能性があります）。
- クライアントデバイスに安全な永続ストレージポイントが必要です。メモリに安全に格納でき、クライアントのシャットダウンまたはアプリケーションの終了時に最終的に破棄できるJWTトークンとは異なり、証明書は安全な場所に永続的に保存する必要があります。クライアントが何であるかに応じて、これは非常に困難または不可能です。
私の意見：JWTトークンは安全で標準化されたクライアント認証方法であり、私はそれをお勧めします。
これはあなたの環境をもっと理解しないと答えられません。
- これはすべて自分のドメイン内にあるのですか、それともこれらの外部がサービスに接続していますか？
- これらのサービスには、互いに異なる権限のセットが必要ですか？
- これらのサービスは、ダウンストリームで使用されるユーザーIDを委任するために使用されますか？
- これらのサービスは互いにどのように通信していますか？残り？バイナリ？
- 使用している技術スタックは何ですか？
クライアント証明書は認証方法として役立ちますが、独自のサービスにアクセスするサービスに異なるアクセス許可を与えることが要件である場合は、クライアント証明書だけでは役に立ちません。上記のように、発行した証明書を管理する必要がありますが、この制約は、署名が必要なJWTにも存在します。外部用の複数の証明書がある場合は、
JWTは、コンシューマに異なる権限があり、RESTを介してサービスにアクセスしている場合に役立ちます。通信がRESTでない場合は、JWTを気にしないでください。JWTでも署名証明書を管理する必要があります。JWTを使用する場合は、弱点に注意してください。持ってる：
- none値を尊重するライブラリに対するAlgorithim攻撃
- JWTリプレイ攻撃
- JWTはトランスポート層でTLSを必要とします
- 一部のJWTフレームワークでは、アルゴリズムのタイプをRS256からHS256に切り替えて公開鍵で署名することにより、システムを攻撃できます
正しく実装されていれば、JWTには何の問題もありません。JWTの実装を台無しにできるだけです。検証で有効期限が無視されたためにセキュリティホールにつながる自分の組織のJWTパターンに現在対処しようとしているため、私はバイアスをかけています...