JSON Web Token-ペイロードが公開されているのはなぜですか？

JWTのクレーム/ペイロードをbase64デコード後に公開する理由を理解できません。

どうして？

シークレットで暗号化する方がはるかに便利だと思われます。

誰かがこのデータを公開することがなぜ役に立つのか、どのような状況で役立つのかを説明できますか？

他の何も暗号化しないことを選択したのと同じ理由でペイロードを暗号化しないことを選択します：コスト（それは小さいですが）は利点を上回り、多くのデータをそのように保護する必要はありません。

ほとんどの場合、保護が必要なのは、人々がデータを改ざんして間違ったレコードを更新したり、誰かの当座預金口座にそのはずのないお金を入れたりすることです。JSON Web Tokenの署名は、ヘッダー/ペイロード/署名の組み合わせの一部を変更するとパケットが無効になるため、これを実現します。

SSLを使用してトランスポート層でパケットを保護できることに注意してください。

RFCでの署名という用語の使用は、非対称暗号方式のデジタル署名に似ています。非対称暗号化では、送信者が秘密鍵でメッセージを暗号化する場合、メッセージを持っている人はだれでも送信者の公開鍵でメッセージを解読できます。したがって、署名という用語の目標は、メッセージを秘密にすることではなく、メッセージの整合性/送信者を検証することであり、それは変更されていません。

JWTの場合、送信システムはメッセージの作成者と消費者の両方であり（下図を参照）、目標はユーザーに渡されたトークンが改ざんされていないことを確認することです（たとえば、昇格された特権が与えられます）。

そして、@ Robertが述べたように、JWTはTLSで暗号化することができます/すべきです。

以下は、以下の画像のソースとなるJWTと署名の適切な説明です。JSON Web Token（JWT）を理解するための5つの簡単なステップ

Robert Harveysの回答に追加するには、ペイロードの暗号化には重大な欠点があります。つまり、サービスの受信者が認証サーバー（暗号化キー）と秘密を共有して、トークンの所有者が許可されているかどうかを理解する必要があることを意味しますか否か。対照的に、誰でも認証サーバーによって公開された公開鍵のみを使用してJWTを検証できます。

これは、クライアントアプリケーションが認証サーバーによって発行されたIDトークンを検証できるため、openid接続仕様の重要な部分です。また、リソースサーバーの展開が容易になります（シークレット暗号化へのアクセスで展開する必要がないため）キー）また、発行されたJWTの問題を診断するときに役立ちます。