JSON Web Token-ペイロードが公開されるのはなぜですか？
JWTのクレーム/ペイロードをbase64でデコードした後に公開する理由を理解できません。
どうして？
シークレットで暗号化するほうがはるかに便利なようです。
なぜ、またはどのような状況で、このデータを公開しておくことが有用であるかを誰かが説明できますか？
何も暗号化しないことを選択するのと同じ理由で、ペイロードを暗号化しないことを選択します。コストは小さくても）利点を上回り、多くのデータをそのように保護する必要はありません。
保護が最も必要なのは、人々がデータを改ざんして、間違ったレコードが更新されたり、誰かの当座預金口座にそれが持っているはずのないお金が入ったりすることです。ヘッダー/ペイロード/署名の組み合わせの一部を変更するとパケットが無効になるため、JSON Webトークンの署名がそれを実現します。
SSLを使用すると、トランスポート層でパケットを保護できることに注意してください。
RFCでの用語signatureの使用は、非対称暗号化でのデジタル署名に類似しています。非対称暗号化では、送信者が秘密キーを使用してメッセージを暗号化すると、メッセージを持っている人はだれでも、送信者の公開キーを使用してメッセージを解読できます。したがって、signatureという用語の目的は、メッセージを秘密に保つことではなく、メッセージの整合性/送信者を検証することであり、変更されていません。
JWTの場合、送信システムはメッセージの作成者とコンシューマーの両方であり（下の図を参照）、ユーザーに渡されたトークンが改ざんされていないことを確認することが目的です（例：昇格した特権）。
また、@ Robertが述べたように、JWTはTLSで暗号化することができます/そうする必要があります。
以下の画像のソースとなっているJWTとシグネチャの良い説明はここにあります。 JSON Web Token（JWT）を理解するための5つの簡単なステップ
Robert Harveysの回答に追加すると、ペイロードの暗号化には大きな欠点があります。つまり、サービスの受信者は、認証サーバー（暗号化キー）とシークレットを共有して、トークンのベアラーが承認されているかどうかを理解する必要があります。か否か。対照的にanyoneは、認証サーバーによって公開された公開鍵のみを使用してJWTを検証できます。
クライアントアプリケーションが認証サーバーによって発行されたIDトークンを検証できるため、これはopenid connect仕様の重要な部分です。また、リソースサーバーを簡単にデプロイできます（シークレット暗号化にアクセスしてデプロイする必要がないため）キー）、発行されたJWTの問題を診断するときにも役立ちます。