ユーザーのメールアドレスをJWTに保存することは悪い習慣ですか？
Webアプリケーションでユーザー認証にJWTを使用しています。各ユーザーの一意のIDがメールアドレスであるユーザーdbがあります。 JWTのサブジェクトを識別するために、私は現在、ユーザーの電子メールアドレスをトークンに格納する要求を持っています。セキュリティ上の問題はありますか？その場合、GUIDまたはIDとしてメールアドレスのハッシュを使用する必要がありますか？
短い答えはノーです。 emailは有効で 登録済みパブリッククレーム であるため、問題はありません。
各ユーザーの一意のIDが電子メールであるユーザーDBがあります...
さて、ユーザーのIDには保護された要求があります。クレームsub。
4.1.2。 "sub"（件名）クレーム
"sub"（サブジェクト）クレームは、JWTのサブジェクトであるプリンシパルを識別します。 JWTのクレームは通常、主題に関するステートメントです。 サブジェクト値は、発行者のコンテキストでローカルに一意であるか、グローバルに一意であるようにスコープを設定する必要があります。 このクレームの処理は、一般にアプリケーション固有です。 「sub」の値は、StringOrURI値を含む、大文字と小文字が区別される文字列です。このクレームの使用はオプションです。
おそらく、subではなくemailのクレームを使用する方が適切です。システムではメールはIDであり、おそらくフォーマットに関係なくそのように扱いたいからです。
つまり、subとemailの両方を実装することを妨げるものは何もありません。これもアプリケーション固有です。
セキュリティの観点から、主な関心事は [〜＃〜] tls [〜＃〜] （https）と トークンの署名/暗号化 を実装することです=。
はい、それは悪い習慣であり、セキュリティ上の問題です。
メールアドレスはPII（個人を特定できる情報）です。他のすべてのPIIと同様に、メールアドレスは暗号化されていない状態で保存しないでください。そうすることは本質的に安全ではありません。
JWTをデータベースやブラウザーのローカルストレージやセッションストレージなどのどこかに保存する場合は、PWTを公開するクレームをJWTで使用しないでください。
emailが登録済みのIANA JWTクレームであるという事実は重要ではありません-given_name、middle_name、family_name、birthdate、phone_number、およびaddressですが、これもすべてPIIです。
ユーザーの電子メールアドレスをトークンに格納することは一般的です。
上記の電子メールアドレスのプロパティは、アイデンティティプロバイダー次第です（一意であるか、変更できるかなど）。
安全でない可能性があるいくつかのシナリオは、ユーザーが自分の電子メールアドレスを変更し、別のユーザーがその電子メールアドレスを取得する場合です。または、ユーザーは自分のアカウントを削除し、同じ電子メールアドレスでそのアカウントを再作成します。また、IDプロバイダーの構成（存在する場合）で、管理者が誤って「固有の電子メールアドレスを強制する」チェックボックスをオフにするリスクもあります。
また、この電子メールアドレスがPIIをログに漏洩してレポートを作成することに注意してください。
UUIDまたはその他の推測できない安定した識別子を使用すると、これらの問題のほとんどが回避されます。新しいアカウントが作成されると、新しいUUIDを受け取り、新しいIDになりますが、電子メールアドレスは変更でき、同じIDのままです。