クッキー対セッション対jwt

Webアプリケーションの認証/承認について読んでいます。誰かが私の現在の知識を確認/修正できますか？

• Cookie：初期のバージョンでは、一意のクライアントIDを含むテキストファイルと、クライアントについて必要なその他すべての情報（ロールなど）

• セッション：一意のクライアントIDのみがファイル（Cookieとも呼ばれます）で送信され、それ以外はすべてサーバーに保存されます

• JWT：すべてがトークンに保存されます（これは、Cookieとも呼ばれるテキストファイルに保存することもできます）

フィードバックをありがとう！

Cookie：初期のバージョンでは、一意のクライアントIDを含むテキストファイルと、クライアントについて必要なその他すべての情報（ロールなど）

Cookieは、クライアントのアクティビティに関連するデータkey-valueを保持するために本来アドレス指定されたタプルです。この保持は、セッションまたはアプリケーションの状態と呼ばれるものです。基本的に、これらはWebアプリケーションの状態を保持するために作成されました。より具体的には、クライアント側の状態。^（1）

Cookieは通常、サーバーによって応答ヘッダー（Set-Cookie key=value）を介して設定されます。ただし、クライアントでも設定できます。たとえば、DOM（document.cookie）によって。

Cookieについて知っておくべき重要なことの1つは、Cookieがユーザーを識別しないことです。むしろ、terna data-client-server / pathを関連付けます。^（3）

私たちは通常、Cookieをファイルに関連付けます。これは、Webブラウザーの初期の段階では、何らかの方法でCookieを永続化する必要があり、ファイルが最も実現可能なサポートであるためです。今日のブラウザーは、（とりわけ）Cookieをローカルストレージ（埋め込みDB）に保存します。

セッション：一意のクライアントIDのみがファイル（Cookieとも呼ばれます）で送信され、それ以外はすべてサーバーに保存されます。

セッションとは、サーバーセッションのことだと思います。私がコメントしたように、セッションはクライアント側でも実装できます。クライアント側セッションとの違いは、データがサーバー側のどこかに保存されることです。^（2）このようなシナリオでは、セッションIDが取得されます。クッキーの形でそれを取得します。セッションIDがないと、サーバーは受信リクエストをクライアントの以前のアクティビティと関連付けることができません。（3）たとえば、認証されたユーザー、ショッピングカートなど。

いずれの場合も、セッションIDは必ずしもユーザーを識別するとは限りません。特定のアプリケーションの状態をWebクライアントに関連付けます。セッションには、ユーザーデータが含まれる場合と含まれない場合があります。

分散アプリケーションでは、セッションは明らかな理由でシリアライズ可能でなければなりません。それらがメモリに格納されている場合、メモリ内ストレージ（コンポーネント）はシリアライズ可能でなければなりません。一般的な解決策は、セッションをファイルに保存することです。またはRedisのようなNoSQL DBで。

セキュリティについて。サーバー側のセッションは、クライアント側よりも安全です。ユーザーは通常、クライアントがさらされている非常に多くの脅威に気づいていないため、クライアントは脅威に対してより脆弱です。少なくとも通常のユーザーではありません。

一方、サーバー側のインフラストラクチャを攻撃することは簡単ではありません。

JWT：すべてがトークンに保存されます（これは、Cookieとも呼ばれるテキストファイルに保存することもできます）

あんまり。JWTは、主にトークンの承認と発行者に関連するデータを格納します。

ユーザーID（サブ）を含めるために使用しますが、認証されたユーザーを識別しないJWTが見つかります。たとえば、ゲストセッションのトークン。JWTの主な内容はクレームです。承認プロセスによってチェックされるアイテム。

JWTはグローバルストレージではないことに注意してください。セッションまたはアプリケーションの状態は、まだどこかに保存され、個別に管理する必要があります。

JWTについては、ローカルストレージに保存することもできますが、Cookieとして保存されることがよくあります。さらに、OWASPコミュニティは、sessionStorageが Webブラウザにとってより安全であると考えています。ただし、ブラウザのバージョンによって異なります。

1：World Wide Webはステートレスであることを意図しています。ステートレスサーバー側アプリケーションを構築する場合、セッションはクライアント側のどこかに保存する必要があります。

2：サーバーサイドアプリケーションをステートフルアプリケーションに変換します。

3：ユーザーではなく、アプリケーションとしてのクライアント。

Cookie：初期のバージョンでは、一意のクライアントIDを含むテキストファイルと、クライアントについて必要なその他すべての情報（ロールなど）

Cookieの定義は、Cookieの機能を実際に説明していません。CookieはSet-Cookie、サーバーによってHTTP応答ヘッダー（）を介して設定され、それらをサポートするクライアントによって格納されるキーと値のペアです。Cookieスキーム、ホスト、パス、httpsに一致するリクエストに対して、後続の各リクエスト（ヘッダー内）でCookieが返送され、Cookieの有効期限が切れていない。Cookieには何でも格納でき、HTTPのステートレスプロトコルで状態をサポートできます。

Cookie交換の例は次のようになります。

セッション：一意のクライアントIDのみがファイル（Cookieとも呼ばれます）で送信され、それ以外はすべてサーバーに保存されます

それはかなり正しいです。セッションは、ユーザーの現在のセッションについてサーバー側に保存されるデータです。HTTPなどのステートレスプロトコルでこれを機能させるには、ユーザーが各リクエストでセッションIDを送信する必要があるため、サーバーはユーザーの正しいセッションをフェッチできます。セッションIDは通常、Cookieに保存されます（上記を参照）。これは、他のCookieと異なるCookieではありません。データは、ユーザーセッションのサーバーのIDです。

JWT：すべてがトークンに保存されます（これは、Cookieとも呼ばれるテキストファイルに保存することもできます）

それはかなり本当です。すべてがトークンに格納されます。トークンはCookieに保存できます（上記を参照）。これはサーバーセッションの代替手段であり、トークンはサーバーによって署名および検証されるため機能します。したがって、トークンを変更したり偽造したりすることはできず、クライアント側に安全に保存できます。