開発者ツール · JWT デコーダー
JWT 対セッション Cookie: ステートレス トークンが Web 認証をどのように変えたか
· 背景
jwt 認証 Web セキュリティ
JWT がステートレスであることを約束するまで、何年もの間、サーバー側セッションが Web 認証を支配していました。この投稿では、その変化を追跡し、その変化によって導入されたコストを比較検討し、ほとんどのチームが最終的に採用するハイブリッド設計について説明します。
セッション Cookie を使用しないのはなぜでしょうか? — JWT を採用する前に本当の答えが必要な質問
JWT を採用する前に、サーバー側のセッションで解決できない問題は何かを考えてください。不透明な Cookie 値を大規模な自己完結型資格情報に置き換えると、失効、開示、検証の責任が変わります。ステートレス性は多くのプロパティのうちの 1 つであり、セキュリティやスケーラビリティが自動的にアップグレードされるものではありません。
ToolAcre は、すべてのリクエストで JWT が何を実行するかを表示できますが、アプリケーションのスループットを比較したり、アーキテクチャを規定したりすることはできません。デコードされたサイズと主張を証拠として使用し、展開、脅威モデル、既存のセッション インフラストラクチャと照らし合わせて比較検討します。
サーバー側セッション — サーバー状態を示す Cookie の不透明な ID、およびそのモデルの機能
従来のサーバー側セッションでは、ブラウザーは不透明な識別子を保持し、サーバーはそれを現在の状態にマップします。このルックアップは、セッションを終了し、権限を変更し、クライアントから離れた場所にデータを保持するための自然な場所を提供します。また、ストレージと可用性に対する責任も生じます。
Cookie とセッションは同義語ではありません。Cookie はトランスポート コンテナーですが、状態はサーバー上に存在します。そのセキュリティは、属性、起点の境界、およびアプリケーションの動作に依存します。ランダムに見えるセッション ID はベアラー資格情報として残り、不用意に公開してはなりません。
自己完結型検証により、共有セッションの検索を減らすことができます。サービス間の信頼は自動的には作成されません
自己完結型トークンを使用すると、リソース サーバーはリクエストごとに共有セッション ルックアップを行わずに、保護されたバイトとクレームを検証できます。これは分散システムには適していますが、この形式ではサービス間の信頼が構築されません。サービスには引き続き、信頼できる発行者キー、承認されたアルゴリズム、対象ユーザー ポリシー、および互換性のあるトークン プロファイルが必要です。
ToolAcre はこれらの信頼関係を提供しません。ヘッダーとペイロードをデコードし、署名が未検証であると報告します。独自の構成をスキップするサービスは、中央のセッションの依存関係を安全でない受け入れパスに置き換えるだけです。
コスト — 失効、すべてのリクエストのトークン サイズ、Cookie と Web ストレージの間のストレージのジレンマ
クレームと暗号マテリアルが繰り返し送信されるため、自己完結型の資格情報は大きくなる可能性があります。外部状態や短い承認期間が導入されない限り、即時取り消しは難しくなります。 Cookie、ブラウザのメモリ、または Web ストレージに保存すると、危険性が排除されるのではなく、危険性が変化します。
読み取り可能なペイロードは、ログや仲介者間で個人データや認証データを複製する可能性もあります。クレームを最小限に抑え、エンコーディングを機密情報として扱うことは避けてください。セッション識別子によって開示される構造は少なくなりますが、セッションがアクティブなままであれば、盗難によって権限が付与される可能性があります。
CSRF と XSS は、単純に JWT とセッション ラベルではなく、資格情報のトランスポートとストレージの選択に依存します。
CSRF リスクは、ブラウザーが自動的に添付する認証情報に強く関連していますが、XSS はページ スクリプトで利用可能なデータとアクションを公開する可能性があります。 Cookie 内の JWT は Cookie トランスポート動作の対象となることはなく、Web ストレージのセッション識別子はベアラー シークレットであることは変わりません。
したがって、形式ラベルだけでは防御を選択できません。認証情報が保存される場所、認証情報を読み取ることができる人、ブラウザーが認証情報を送信するタイミング、および状態を変更するリクエストがどのように保護されるかをモデル化します。 1 つのアーキテクチャが「CSRF を解決する」または「XSS を解決する」という単純な主張は避けてください。
実用的な例 — セッションと JWT で説明した同じログイン フローをステップバイステップで説明します
セッション フローでは、ログインによってサーバー状態が確立され、不透明な識別子が返されます。後のリクエストではそれが提示され、サーバーは現在のポリシーをロードします。 JWT フローでは、ログインによって保護されたトークンが発行されます。後のリクエストではより大きな値が送信され、リソース サーバーはその値と関連するクレームを検証します。
ログアウトは両方のフローでブラウザーのコピーを削除できますが、サーバーの即時無効化は当然セッション状態に関連付けられているため、自己完結型トークン用に明示的に設計する必要があります。 ToolAcre は、ログアウトまたは取り消しが実際に有効になったかどうかではなく、JWT のアサートされた有効期限と対象ユーザーを表示できます。
ハイブリッド設計には依然として明示的な更新、取り消し、検証ポリシーが必要です
ハイブリッド設計では、ステートフル更新プロセスで制限付きアクセス トークンを使用することも、制御されたサービス間でのみ JWT で不透明な外部資格情報を使用することもできます。これらのアプローチは、国家を廃止するのではなく、国家を動かすものです。安全な更新ストレージ、キーのローテーション、取り消し動作、およびポリシーのテストが依然として必要です。
このリポジトリではユニバーサル トークンの有効期間やハイブリッド レシピが定義されていないため、この記事では何も提供しません。測定されたリスクと運用上の制約から期間とメカニズムを選択し、アーキテクチャ上のラベルに依存するのではなく、トークンの盗難とログアウトのシナリオをテストします。
要点: ステートレス性はアップグレードではなくトレードです。JWT を選択した場合、ToolAcre JWT デコーダーは、各リクエストで各トークンが何を伝送するかを示します。
無国籍は取引であり、アップグレードではありません。サーバー セッションは、検索を犠牲にして現在の状態と失効を一元管理します。自己完結型トークンは、より大きな認証情報、読みやすいクレーム、より明示的な無効化設計を犠牲にして検証を分散します。
JWT が適合する場合は、ToolAcre を使用して安全な例を検査し、各リクエストが何を運ぶのかを理解してください。その表示を真正性または認可の証明として扱わないでください。このアーキテクチャは、信頼できる検証者、ストレージの選択、取り消しメカニズムが脅威モデルと一致する場合にのみ成功します。