JWTトークンを使用してApiに接続するjavascriptクライアントを作成していました。サーバー側には問題はありません。トークンに署名して後で署名を検証し、誰もトークンを改ざんしないようにすることができます。JWTトークン署名検証javacript
しかし、これはクライアント側でどのように行うのですか。私はJWTトークンをデコードし、ヘッダー、ペイロードと署名を見ることができます。しかし、どのように私はクライアントのサイトで署名を確認するのですか？このためのライブラリはありますか？公開鍵をクライアントにどのように転送しますか？
署名を確認しないと、トークンが改ざんされていないことをどのように知ることができますか？
クライアント側で署名を検証しないと、トークンが実際にサーバーから取得されていることをどのように確認できますか？たぶん、中間者攻撃の男を回避していないトークン
署名の検証を変更している途中で誰かがあります。攻撃者は、資格取り込むかさえも有効なトークン
どのようにすることができ、私は署名を検証していない場合はSSL/TLSチャネル（HTTPS）
を使用を使用してメッセージを変更するチャネルを盗聴可能性トークンが改ざんされていないことを知っていますか？
TLS信頼できるサーバが提供するトークンはおそらく有効です。（それはローカルストレージに変更された可能性があり）。署名を検証できます。この操作は通常サーバー側で実行されますが（@ sakutoの回答を参照）、ブラウザで完全に行うことができます。
しかし、クライアントサイトで署名を確認するにはどうすればよいですか？
これらの手順です
Webcryptoを使用することをお勧めします。 https://github.com/diafygi/webcrypto-examples/blob/master/README.md#rsassa-pkcs1-v1_5
通常、クライアント側では検証を行わず、重要なデータをトークンに保存しません。すべての制御と許可はバックエンドでチェックされます。つまり、ユーザーがトークンを改ざんしても、バックエンドコントロールを渡すことはできず、前面にもう1つのオプションしか表示されない可能性があります。
ただし、クライアント側で署名を検証しないと、トークンが実際にサーバーから取得されていることをどのように確認できますか？おそらく、トークンを変更している途中に誰かがいるかもしれません。トークンが有効であることを保証できない場合は、発行者をチェックするのは何ですか。あるいは、誰かが私のトラフィックを傍受し、サーバーとしてポーズを取っているかもしれません。私は今、 '偽の'サーバーを信用し、私は彼にクレジットカードのアカウント番号を送信します。 – Arno
@Arno - クライアント側では、通常、単純にペイロードを解析/デコードし、トークンの有効期限を検証します。これは不要なトークン呼び出しを避けるために行われています。改ざんなどの実際のトークン検証は、サーバー側で行われる必要があります。 –
中間の攻撃を行った人にSSLがどのように役立つのでしょうか？攻撃者が有効な証明書を持っている場合、私はその人の真ん中をサーバーであると信じています。一方、中央の人には、JWTトークンに署名するために必要な秘密鍵がありません。私がトークンを検証すると、トークンが正しいサーバーからのものではないことがわかります。 – Arno
SSL/TLSを使用すると、クライアント/ブラウザには、受け入れられた認証局とのトラストストアがあります。 **信頼できるCAが発行しないため、偽の証明書を生成しようとすると、発行者の証明書がトラストストアに存在しないため、クライアントはそれを拒否するため、攻撃者はホスト名に有効な証明書を提示できません。 – pedrofb
私が答えて言ったように、MITM攻撃（HTTPSなし）を使用すると、攻撃者は信頼できるサーバーからの有効なトークンを取得し、不正な操作を実行するためにそれを使用できます。 **盗まれたトークンが有効であるため、攻撃者はトークンを変更する必要はありません**。どの認証システムでも、これを避けるためにチャネルを保護する必要があります – pedrofb