JWT認証方法は嘘である

JWTs、すなわちJSON Web Tokensは、私たちに美しい嘘を売りつけました。それはstateless authenticationの約束です。その売り込みは洗練されていました。サーバーはログイン時に署名済みの小さなトークンをあなたに渡し、すぐにセッション状態を忘れます。この自己完結型の驚異は、データベースルックアップの削減、水平スケーリングの簡素化、そして一見するとより軽いサーバーフットプリントを意味しました。素晴らしい響きで、人々はそれを信じました。

しかし、この約束のまさに基盤は、精査の下で崩れ去りました。真にstateless tokenは取り消すことができません。ログアウトしても、禁止されても、あるいはさらに恐ろしいことに、トークンが侵害で盗まれたとしても、有効期限が切れるまで完全に有効なままです。サーバーは設計上、それを「殺す」メカニズムを持っていません。この根本的なセキュリティ脆弱性が、ステートレスな夢を悪夢に変えます。

ほとんどすべての開発者の回避策がその欺瞞を露呈させます。取り消し不能なトークンに対抗するため、人々はサーバーサイドの「revoked token list」を実装します。このリストはすべてのリクエストでチェックされ、セッション状態を再導入し、コアとなるステートレスの利点を完全に無効にします。Better Stackによる「The Boring Auth Method That Actually Works」が的確に指摘しているように、あなたはそもそもJWTを選んだ理由をすべて捨ててしまったのです。あなたは状態管理に戻ったことになりますが、今度は余分な手順と固有の脆弱性を伴います。

多くの開発者は、ステートレスな夢を追いかける中で、重大な誤りを犯しています。彼らはJWTをブラウザのlocal storageに格納するのです。この方法は便利なセッション永続性を提供し、ユーザーが追加のサーバー参照なしにブラウザセッションをまたいでログイン状態を維持できるようにします。しかし、この利便性は容認できないセキュリティコストを伴います。

この一見無害なストレージの選択は、攻撃者にとって大きなバックドアを作り出します。多くの場合、エスケープされていないユーザー入力に起因する成功したCross-Site Scripting (XSS)の脆弱性は、ページに注入された悪意のあるJavaScriptが正規のアプリケーションと同じ権限で実行されることを可能にします。人々はこれらのトークンをローカルストレージに詰め込むため、攻撃者にとって格好の餌食となります。

攻撃者がスクリプトを実行すると、ローカルストレージに保存されたJWTは簡単に抽出されます。盗まれたトークンを使用すると、攻撃者は被害者のアカウントに即座に無制限にアクセスでき、すべての認証メカニズムをバイパスします。これは単なる軽微な侵害ではなく、完全なアカウント乗っ取りであり、攻撃者にあなたのデジタル王国の鍵を与えることになります。

決定的に重要なのは、このセキュリティ上の大惨事がJWT標準自体の欠陥ではないということです。問題は、広範にわたる危険なimplementation errorにあります。開発者は、セッション管理への簡単な道を探す中で、強力な暗号プリミティブを負債に変え、予測可能な経路を通じてユーザーアカウントを侵害する手段を攻撃者に与えているのです。

この自ら招いたJWTの傷に対する解決策は、Better Stackの専門家が「The Boring Auth Method That Actually Works」で的確に表現しているように、見かけによらずシンプルで、むしろ「退屈」です。複雑で自己完結型のトークンの代わりに、私たちはopaque session tokensに戻ります。これらはランダムに生成された意味のない文字列です。これらのトークンは単なるポインタとして機能し、サーバーサイドデータベースに安全に保存された豊富で変更可能なセッションレコードに直接マッピングされ、JWTが排除すると約束した制御を取り戻します。

この従来のアプローチは、セッション管理におけるJWTsが抱える重大な問題を即座に解決します。ユーザーがログアウトしたり、禁止されたり、トークンが盗まれたりした場合、サーバーは対応するセッション記録を直ちに無効化し、盗まれたトークンを無効にできます。重要なことに、トークン自体はユーザーデータや認証クレームを一切開示しません。それは単なるランダムな識別子であり、RFC 7519 - JSON Web Token (JWT)で詳述されている情報密度の高いJWTsとは対照的です。これにより、JWTsが不器用な回避策なしには本質的に欠いている即時失効の機能を取り戻すことができます。

さらに、これらの不透明なトークンに対する適切な保存メカニズムは、私たちが議論したXSSベースの盗難ベクトルを排除します。私たちは安全なHttpOnly cookiesを推奨します。これらのクッキーはすべてのリクエストとともに自動的に送信されますが、クライアントサイドのJavaScriptからはアクセスできないため、攻撃者がCross-Site Scriptingの脆弱性を介してそれらを奪取するのを防ぎます。この方法は堅牢なクライアントサイド保護を提供し、真のサーバーサイド制御を取り戻させます。これはクライアントサイドのlocal storageを信頼するよりもはるかに優れた解決策です。

JWTsは悪役ではありません。ただ誤った役割を与えられているだけです。その真の力は、主要なセッション管理としてではなく、特定の制約されたシナリオにあります。短命なAPI access tokensとして使用し、絶え間ないデータベース参照なしに一時的で詳細な権限を付与します。バックエンドシステムが信頼できる自己完結型の情報を交換するサービス間通信において優れており、宣伝されているstateless designを妥協なく活用できます。

現代の認証は、よりスマートなアプローチ、すなわちハイブリッドモデルを要求します。推測不可能な文字列である安全で不透明なrefresh tokenを発行し、それをHttpOnly cookieに安全に格納することで、悪意のあるクライアントサイドスクリプトからアクセスできないようにします。この堅牢なrefresh tokenは、超短命のJWT access tokensをアプリケーションメモリに直接発行します。これらのephemeral JWTsはリクエストに対して即座の認証を提供し、重大な負債となる前に迅速に期限切れとなり、ユーザーの介入なしにバックグラウンドでシームレスに更新されます。

認証の状況は絶え間ない進化を続けています。私たちはパスワードを完全に超え、優れたセキュリティとユーザーエクスペリエンスを提供するPasskeysやその他のpasswordless methodsを採用しています。リアルタイムでリスク要因を評価するAdaptive authenticationは、防御をさらに強化し、正当なユーザーにとってより堅牢で侵入的でないセキュリティの未来を築きます。

local storageにJWTを保存することが安全でないとされるのはなぜですか？

local storageにJWTsを保存すると、Cross-Site Scripting (XSS) attacksに対して脆弱になります。ウェブサイトに注入された悪意のあるJavaScriptは、トークンにアクセスして盗むことができ、攻撃者がユーザーになりすますことを完全に可能にします。

opaque session tokenとは何ですか？

opaque session tokenは、クライアントに保存される（理想的にはHttpOnly cookieに）ランダムで意味のない識別子です。これはサーバーサイドデータベースに保存されている詳細なセッション記録を参照し、即時失効と制御を可能にします。

JWTsがsessionsにとってリスクがある場合、その適切な使用例は何ですか？

JWTsは、APIsの保護、microservicesにおけるserver-to-server communicationの認証、またはより複雑なhybrid authentication systemにおけるtemporary access tokensとしての役割など、短命でstatelessなシナリオに非常に適しています。

JWTは期限切れになる前に本当に失効させることができますか？

直接的にはできません。JWTsはstatelessであるため、発行された後、サーバーはそれらを記憶していません。JWTを「失効」させる唯一の方法は、サーバーサイドのblocklistを維持することですが、これは状態を再導入し、JWTを使用する主な利点を損ないます。