「JWT対Cookie」に関するいくつかの投稿を読みましたが、混乱しただけでした...

1. 私はいくつか欲しい明確化、「クッキー対トークンベース認証」の話を人々は、クッキーがここに単に参照セッションクッキーを？私の理解では、Cookieは媒体のようなものであり、トークンベースの認証（クライアント側でログインしているユーザーを識別できるものを保存する）またはセッションベースの認証（クライアント側で定数を保存する）を実装するために使用できますサーバー側のセッション情報と一致する）

2. JSON Webトークンが必要なのはなぜですか？私は標準のCookieを使用してトークンベースの認証を実装していました（セッションIDを使用せず、サーバーメモリまたはファイルストレージを使用しません）：Set-Cookie: user=innocent; preferred-color=azureと私が観察した唯一の違いは、JWTにペイロードと署名の両方が含まれていることです... httpヘッダーの署名付きまたはプレーンテキスト cookieの間。私の意見では、署名されたCookie（cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM'）はスペース効率が高く、唯一の欠点はクライアントがトークンを読み取ることができず、サーバーのみが読み取ることができることです...しかし、JWTのクレームがオプションであるのと同じように、トークンが意味がある

ベアラートークンとCookieの最大の違いは、ブラウザーが自動的にCookieを送信することです。ベアラートークンをHTTPリクエストに明示的に追加する必要があります。

この機能により、Cookieは、ユーザーがログインし、リンクを使用してページ間を移動するWebサイトを保護するための優れた方法になります。

Cookieを自動的に送信するブラウザには、CSRF攻撃という大きな欠点もあります。CSRF攻撃では、悪意のあるWebサイトは、ブラウザーがそのドメインへの要求に認証Cookieを自動的に添付し、ブラウザーをだまして要求を実行させるという事実を利用します。

https://www.example.comのWebサイトで、認証されたユーザーがユーザー名や古いパスワードを投稿しなくてもPOST、https： //www.example.com/changepasswordに新しいパスワードを入力することでパスワードを変更できるとします。

ブラウザにページを読み込んでそのアドレスへのPOSTをトリガーする悪意のあるWebサイトにアクセスしたときに、引き続きそのWebサイトにログインしている場合、ブラウザは認証Cookieを忠実に添付し、攻撃者がパスワードを変更できるようにします。

Cookieを使用してWebサービスを保護することもできますが、現在はベアラートークンが最もよく使用されています。Cookieを使用してWebサービスを保護する場合、同じ生成元のポリシーはCookieを別のドメインに送信しないため、そのサービスは認証Cookieが設定されているドメインに存在する必要があります。

また、Cookieにより、ブラウザーベース以外のアプリケーション（モバイルからタブレットへのアプリなど）がAPIを使用することがより困難になります。

概観

あなたが求めているのは、JSON Web Token（JWT）をクライアントからサーバーに送信するためのCookieとベアラートークンの違いです。

Cookieとベアラートークンの両方がデータを送信します。

違いの1つは、Cookieが任意のデータを送信および保存するためのものであるのに対し、ベアラートークンは特に認証データを送信するためのものです。

そのデータは、多くの場合、JWTとしてエンコードされます。

クッキー

Cookieは名前と値のペアであり、Webブラウザーに保管され、有効期限と関連ドメインがあります。

Cookieは、JavaScriptまたはHTTP応答ヘッダーを使用してWebブラウザーに保存します。

document.cookie = 'my_cookie_name=my_cookie_value'   // JavaScript
Set-Cookie: my_cookie_name=my_cookie_value           // HTTP Response Header

Webブラウザーは、すべての要求とと​​もにCookieのドメインへのCookieを自動的に送信します。

GET http://www.bigfont.ca
Cookie: my_cookie_name=my_cookie_value               // HTTP Request Header

無記名トークン

ベアラートークンは、AuthorizationHTTPリクエストのヘッダーに入る値です。自動的にはどこにも保存されず、有効期限もドメインも関連付けられていません。それは単なる価値です。その値をクライアントに手動で保存し、その値をHTTP Authorizationヘッダーに手動で追加します。

GET http://www.bigfont.ca
Authorization: Bearer my_bearer_token_value          // HTTP Request Header

JWTおよびトークンベースの認証

OpenID、OAuth、OpenID Connectなどのトークンベースの認証を行う場合、信頼できる機関からaccess_token（場合によってはid_token）を受け取ります。通常、それを保存し、保護されたリソースのHTTPリクエストと共に送信します。どうすればよいですか？

オプション1は、トークンをCookieに保存することです。これはストレージを処理しCookie、各リクエストのヘッダーでトークンをサーバーに自動的に送信します。次に、サーバーはCookieを解析し、トークンをチェックして、それに応じて応答します。

もう1つのオプションは、トークンをローカル/セッションストレージに保存し、Authorization各リクエストのヘッダーを手動で設定することです。この場合、サーバーはヘッダーを読み取り、Cookieの場合と同様に処理を進めます。

詳細については、リンクされたRFCを読む価値があります。

MvdDが自動的に送信されるCookieについて述べたことに加えて、

1. Cookieは媒体になる可能性がありますが、最も重要な機能は、ブラウザとの対話方法です。Cookieはサーバーによって設定され、非常に特殊な方法でリクエストで送信されます。一方、JWTはもっぱら媒体であり、特定の構造におけるいくつかの事実の表明です。気が向いたら、認証CookieとしてJWTを使用できます。それらを比較する記事を読むとき、彼らは通常、フロントエンドコードによってベアラートークンとして送信されたJWTと、バックエンドでキャッシュされたセッションまたはユーザーデータに対応する認証Cookieを使用することについて話しています。
2. JWTは多くの機能を提供し、それらを標準化してパーティー間で使用できるようにします。JWTは、さまざまな場所でいくつかの事実の署名付きアサーションとして機能できます。Cookieは、どのデータを入力した場合でも、署名した場合でも、ブラウザと特定のバックエンド間で使用するのが実際に意味があります。JWTは、ブラウザーからバックエンドまで、さまざまなパーティーによって制御されるバックエンド間（OpenId Connectがその例です）、または1つのパーティーのバックエンドサービス内で使用できます。署名付きCookieの具体的な例については、そのユースケースではJWTと同じ機能（「セッションIDを使用せず、サーバーメモリまたはファイルストレージを使用しない」）を達成できる可能性がありますが、ライブラリとピアのレビューを失う標準、および他の回答で述べられたCSRF問題に加えて。

要約すると、あなたが読んでいる投稿はおそらく、ブラウザーからサーバーへの認証を目的としたベアラートークンとしてのJWTと認証Cookieを比較しているでしょう。しかし、JWTはさらに多くのことを実行できます。これは、おそらくあなたが考えているユースケースの外で使用するための標準化と機能をもたらします。

Cookieはリクエストとともに自動的に送信されるため、CSRF攻撃のリスクを高めるHttpOnlyことができますが、ページに挿入されたスクリプトは読み取ることができないため、フラグが設定されているとXSS攻撃のリスクを減らすことができます。クッキー。

CSRF：ユーザーが攻撃者のサイトのリンクをクリック（または画像を表示）すると、ブラウザが被害者のサイトにリクエストを送信します。被害者がCookieを使用する場合、ブラウザはリクエストにCookieを自動的に含めます。GETリクエストが読み取り専用以外のアクションを引き起こす可能性がある場合、被害者のサイトは攻撃に対して脆弱です。

XSS：攻撃者は被害者のサイトにスクリプトを埋め込み（被害者のサイトは、入力が正しくサニタイズされない場合にのみ脆弱です）、攻撃者のスクリプトは、JavaScriptがページで許可されているすべてのことを実行できます。JWTトークンをローカルストレージに保存している場合、攻撃者のスクリプトはそれらのトークンを読み取り、それらのトークンを制御するサーバーに送信する可能性があります。HttpOnlyフラグ付きのCookieを使用すると、攻撃者のスクリプトは、最初からCookieを読み取ることができません。とは言え、正常に注入されたスクリプトは、JavaScriptで実行できるすべてのことを実行できるため、IMOを利用できます（つまり、Cookieを読み取って、後で使用するために独自のサーバーに送信することができない場合があります。 、XHRを使用してvicitimサイトにリクエストを送信できます。これには、とにかくCookieが含まれます）。

参照-JSON Webトークンの必要性

クッキー

Cookieの場合、ユーザーが認証されると、Gmailサーバーは一意のセッションIDを作成します。このセッションIDに対応して、Gmailサーバーがユーザーを認識して操作を実行するために必要なすべてのユーザー情報をメモリに格納します。
また、その後のすべての要求と応答で、このセッションIDも渡されます。したがって、サーバーがリクエストを受信すると、セッションIDをチェックします。このセッションIDを使用すると、対応する情報があるかどうかがチェックされます。その後、ユーザーはリソースにアクセスして、セッションIDとともに応答を返すことができます。

クッキーの欠点

• Cookie /セッションIDは自己完結型ではありません。参照トークンです。各検証中に、Gmailサーバーはそれに対応する情報を取得する必要があります。
• 複数のAPIとサーバーを含むマイクロサービスアーキテクチャには適していません

JWT

• JWTは自己完結型です。バリュートークンです。したがって、各検証中に、Gmailサーバーはそれに対応する情報を取得する必要はありません。
• それはデジタル署名されているので、誰かがそれを変更した場合、サーバーはそれについて知っています
• マイクロサービスアーキテクチャに最適
• 有効期限を指定するなど、他にも利点があります。