JWTと一部のjsonをAESで手動で暗号化することの違いは何ですか？
JSON Web Token（JWT）を使用することと、単純にAESキーを持ち、クライアントから暗号化されたJSONを送受信することの違いは何ですか？
たとえば、これはクライアントに送信できます。
AES256.encrypt(JSON.stringify({id: 5552, admin: true}), key)
JSON Web Token（= JWT）は RFC 7519 に基づいており、すべての違いがそこで説明されています。これを見てみると、あなたが考えているように見えるものよりもはるかに多くあることがわかります。
とりわけ、これらのトークン：
- 主張を表明するために使用されます（たとえば、「管理者としてログイン」）
- メッセージ認証コード（HMAC-SHA256など）で署名されている（アルゴリズムはJWTのヘッダーで指定されている）
- クレームを含むペイロードを持っている（タイムスタンプを備えている）
署名はbase64urlでエンコードされています。これは、RFCの セクション3.1 および 付録A.1 で説明されています。
あなたは共有クレームの手の込んだ実装でこれをすべて行うことができますが、なぜあなたはそうしますか？
理由には、標準、規範、RFCがあります。それらは専門家によってテストされ、信頼され、人々は理由のためにそれらを使用します。ほぼ全員が果物をキロで計量し、距離をキロで移動するのは良いことです。標準化されたシステムにより、情報の共有が容易になり、多くの人が簡単に使用できるようになります。
この背後にあるあなたの要点の結論：テストされ信頼されたソリューションがある問題に対して過度に複雑なソリューションを構築しないでください。
また、別の「違いは何ですか？」については、こちらをご覧ください。質問： SHAとAES暗号化の違いは何ですか？
私の他のセクションSEから answer ：
JWTは、異なるシステム間で認証情報を共有するために使用される自己完結型のトークンです。 JWTの検証に必要なすべての情報がトークン自体に含まれているため、認証トークンの検証をサードパーティに依存するという問題を解決します。これにより、最小限の統合が必要になるため、シングルサインオンシステムでのオンボーディングプロセスが簡素化されます。 JWTは単なるBASE-64文字列であるため、HTTPにも対応しています。
アプリケーションアーキテクチャに関する十分な情報が提供されていません。特定のケースでは、他のサードパーティまたは信頼されたリソースサーバーが、ユーザーが発行したAESトークンを検証するのは困難です。これを行う唯一の方法は、あなたが発行した認証トークンを検証したいすべての人とAES暗号化キーを共有することです。これは設計上の悪い決定であり、重大な機密性と整合性の問題が発生する可能性があります。
さらに、トークンは、タイムスタンプなどの重要なセキュリティ機能をサポートする必要があります。これにより、リソースはトークンのリプレイ攻撃を防ぐことができます。あなたのデザインはこれをサポートしていません。
AES256.encrypt(JSON.stringify({id: 5552, admin: true}), key)
一意のID 5552を持つ管理ユーザーのセキュリティトークンは、常に同じ値になります。要するに、ホイールを再発明して、認証のために既存のメソッドとフレームワークに依存しようとするべきではありません。 JWTは、過去にセキュリティのシェア issues を共有してきました。読む more 。
違い：
- JWTはプレーンテキストとそのhmacを送信しますが、代わりに暗号化されたメッセージを送信します
- JWTは標準であり、複数の言語のライブラリーがあります
システムの問題は、クライアントがトークンの内容（たとえば、どのユーザーが所有者であるか）を読み取れないことです。