HTTPのみのCookie内にJWTトークンを保存する方法は？
正しいログイン資格情報に基づいてサーバーから送信されたJWTを単に使用し、/apiバックエンドExpress.jsサーバー上のルート。
一方、AngularJSはこのトークンを取得してセッションストレージに保存し、認証インターセプターを使用してトークンをサーバーに送り返します。
私は最近、この習慣がどれほど危険かを理解するようになりました。
このシナリオでは、トークンのやり取りを理解しています。しかし、そのJWTをクライアント側のJavascriptが読み取れない安全なHTTP専用Cookieに格納する場合に行われる方法を、高レベルで説明するほど親切な人がいますか？
例：クレデンシャルの成功時
- cookieはサーバー上に作成され、
- cookieと同時にJWTを作成する
- jWTをトークンなどと呼ばれるCookieプロパティに保存します。
私はここでそれがどのように機能するかという精神モデルを獲得しようとしています。私の理解が正しい場合、この方法で行うと認証インターセプターはもう必要ありません。正しい資格情報にログインすると、サーバーがCookie内のトークンの転送をすべて行うからです。
Cookieの取り扱いには微妙な部分がありますが、高レベルでは、CookieはWebサーバーが設定できるデータの一部であり、ユーザーのWebブラウザーによって保存され、将来のリクエストでサーバーに返送されますCookieが有効であり、行われているリクエストに適用できる限り、ブラウザは同じサーバーに対して作成します。
（これがAngularインターセプターを使用する必要がなくなる理由です。これは、Cookieが送信されることを保証するのはブラウザー自体であるためです）
HTTPのみなどの特別なフラグオプションに加えて、より高いレベルで、特定のドメインとパスに関連付けられるようにCookieを設定できます。たとえば、サーバーは、/apiパスの下で行われたリクエストにブラウザからのみ送信されるようにCookieを設定できます。
まとめると、CookieはHTTPの状態管理メカニズムです。詳細については、関連する RFC 2617 を参照してください。
対照的に、JWTは、よく知られた表現を持ち、いくつかの規則に従う単なるデータです。より具体的には、JWTはヘッダー、ペイロード、および署名セクションで構成されており、ほとんどのJWTユースケースではペイロードのサイズを小さく保つことをお勧めします。詳細については、 JSON Webトークンの使用開始 を参照してください。
前の記事を読むと、JWTの最終的な表現は、ドットで区切られた3つのBase64urlエンコード文字列であることに気付くでしょう。これは、JWTがCookieの値としてなど、HTTP内での使用に適していることを意味するため、特に興味深いものです。
念頭に置いておくべきことの1つは、仕様では、ブラウザがCookieごとに最大4096バイトのCookieをサポートすることだけが保証されていることです（Cookieの名前、値、および属性の長さの合計で測定）。トークンに大量のデータを格納する場合を除き、問題は発生しませんが、常に考慮する必要があります。はい、JWTトークンを複数のCookieに分割することもできますが、事態はさらに複雑になり始めます。
さらに、Cookieには有効期限の概念があります。そのため、JWT自体も認証の範囲内で使用される場合、有効期限の概念も持つため、これも念頭に置いてください。
最後に、JWTをlocalStorage/sessionStorageに保存することに関する懸念に対処したいと思います。たとえば、ストレージが関連付けられているドメイン内のJavascriptコードは、トークンを読み取ることができるなど、その意味を理解する必要があります。ただし、HTTPのみのCookieも特効薬ではありません。次の記事を読んでください： Cookies vs Tokens：The Definitive Guide 。
従来のセッション識別子Cookieとトークンベース（JWT）認証システムの違いに焦点を当てており、Where to Store Tokens？というセクションは、ストレージのセキュリティ関連の側面に取り組む際に読み取りを保証します。
TL：DRの人々の要約：
Webサイトが直面する最も一般的な攻撃ベクトルの2つは、クロスサイトスクリプティング（XSS）とクロスサイトリクエストフォージェリ（XSRFまたはCSRF）です。クロスサイトスクリプティング）攻撃は、外部エンティティがWebサイトまたはアプリ内でコードを実行できる場合に発生します。 （...）
攻撃者がドメインでコードを実行できる場合、JWTトークン（in local storage）は脆弱です。 （...）
ローカルストレージでJWTを使用している場合、クロスサイトリクエストフォージェリ攻撃は問題になりません。一方、ユースケースでJWTをCookieに格納する必要がある場合は、XSRFから保護する必要があります
（強調は私のものです）
はい、認証インターセプターは必要ありません。ブラウザは、すべてのリクエストに対して設定した同じOriginにCookieを送信します。