クッキー対セッション対jwt
Webアプリケーションの認証/承認について読んでいます。誰かが私の現在の知識を確認/修正できますか？
Cookie：初期のバージョンでは、一意のクライアントIDを含むテキストファイルと、クライアントについて必要なその他すべての情報（ロールなど）
セッション：一意のクライアントIDのみがファイル（Cookieとも呼ばれます）で送信され、それ以外はすべてサーバーに保存されます
JWT：すべてがトークンに格納されます（これは、Cookieとも呼ばれるテキストファイルに格納することもできます）
フィードバックをありがとう！
Cookie：初期のバージョンでは、一意のクライアントIDを含むテキストファイルと、クライアントについて必要なその他すべての情報（ロールなど）
Cookieはタプルkey-value最初はクライアントのアクティビティに関連するretainデータに対処していました。このretentionは、sessionまたはapplication stateとして知られています。基本的に、これらはWebアプリケーションの状態を保持するために作成されました。より具体的には、クライアント側の状態。 （1）
Cookieは通常、応答ヘッダー（Set-Cookie key=value）。ただし、クライアントでも設定できます。たとえば、DOM（document.cookie）。
Cookieについて知っておくべき重要なことの1つは、Cookieがユーザーを識別しないことです。それらはむしろ、ternadata-client-server/pathを関連付けます。 （3）
私たちは通常、Cookieをファイルに関連付けます。これは、Webブラウザーの初期の段階では、何らかの方法でCookieを永続化する必要があり、ファイルが最も実現可能なサポートであるためです。今日のブラウザーは、（とりわけ）Cookieをローカルストレージ（埋め込みDB）に保存します。
セッション：一意のクライアントIDのみがファイル（Cookieとも呼ばれます）で送信され、それ以外はすべてサーバーに保存されます。
セッションとは、server sessionsを意味していると思います。私がコメントしたように、セッションはクライアント側でも実装できます。クライアント側セッションとの違いは、データがサーバー側のどこかに保存されることです。 （2） このようなシナリオでは、取得するのはセッションIDです。 Cookieの形で取得します。セッションIDがないと、サーバーは受信リクエストをクライアントの以前のアクティビティと関連付けることができません。 （3） たとえば、認証されたユーザー、ショッピングカートなどです。
いずれの場合も、セッションIDは必ずしもユーザーを識別するとは限りません。特定のアプリケーションの状態をWebクライアントに関連付けます。セッションには、ユーザーデータが含まれる場合と含まれない場合があります。
分散アプリケーションでは、明らかな理由により、セッションをシリアライズ可能にする必要があります。それらがメモリに格納されている場合、メモリ内ストレージ（コンポーネント）はシリアライズ可能でなければなりません。一般的な解決策は、セッションをファイルに保存することです。またはRedisのようなNoSQL DBで。
セキュリティについて。サーバー側のセッションはクライアント側よりも安全です。ユーザーは通常、クライアントがさらされている非常に多くの脅威に気づいていないため、クライアントは脅威に対してより脆弱です。少なくとも通常のユーザーではありません。
一方、サーバー側のインフラストラクチャを攻撃することは簡単ではありません。
JWT：すべてがトークンに保存されます（これは、Cookieとも呼ばれるテキストファイルに保存することもできます）
あんまり。 JWTは、主にトークンの承認と発行者に関連するデータを格納します。
ユーザーID（サブ）を含めるために使用されますが、認証されたユーザーを識別しないJWTが見つかります。たとえば、ゲストセッションのトークン。 JWTの主な内容はclaims;です。承認プロセスによってチェックされるアイテム。
JWTはグローバルストレージではないことに注意してください。 sessionまたはapplication stateは、どこかに保存され、個別に管理される必要があります。
JWTについては、ローカルストレージに保存することもできますが、Cookieとして保存されることがよくあります。さらに、 OWASPコミュニティは、sessionStorageがより安全であると見なしています Webブラウザーの場合。ただし、 ブラウザのバージョンによって異なります 。
1：World Wide Webはステートレスであることを意図しています。ステートレスサーバー側アプリケーションを構築する場合、セッションはクライアント側のどこかに保存する必要があります。
2：サーバー側アプリケーションをstatefulアプリケーションに変換します。
3：ユーザーではなく、アプリケーションとしてのクライアント。
Cookie：初期のバージョンでは、一意のクライアントIDを含むテキストファイルと、クライアントについて必要なその他すべての情報（ロールなど）
Cookieの定義は、Cookieの機能を実際に説明していません。 Cookieは、HTTP応答ヘッダー（Set-Cookie）サーバーによって、それらをサポートするクライアントによって格納されます。スキーム、ホスト、パス、httpsに一致するリクエストの後続のリクエストごとに（Cookieヘッダーで）Cookieが返送されますが、Cookieの有効期限は切れていません。 Cookieには何でも格納でき、HTTPのステートレスプロトコルで状態をサポートできます。
Cookie交換の例は次のようになります。
セッション：一意のクライアントIDのみがファイル（Cookieとも呼ばれます）で送信され、それ以外はすべてサーバーに保存されます
それはかなり正しいです。セッションは、ユーザーの現在のセッションについてサーバー側に保存されるデータです。 HTTPなどのステートレスプロトコルでこれを機能させるには、ユーザーが各リクエストでセッションIDを送信する必要があるため、サーバーはユーザーの正しいセッションをフェッチできます。セッションIDは通常、Cookieに保存されます（上記を参照）。これは、他のどのCookieとも異なるCookieではありません。データは、ユーザーセッションのサーバーのIDにすぎません。
JWT：すべてがトークンに保存されます（これは、Cookieとも呼ばれるテキストファイルに保存することもできます）
それはかなり本当です。すべてがトークンに格納されます。トークンはCookieに保存できます（上記を参照）。これはサーバーセッションの代替手段であり、トークンはサーバーによって署名および検証されるため機能します。したがって、トークンを変更したり偽造したりすることはできず、クライアント側に保存しても安全です。