認証などの状況でセッションではなく JWT を使用する利点は何ですか?
これはスタンドアロンのアプローチとして使用されますか、それともセッション内で使用されるのでしょうか?
ベストアンサー1
JWT 自体には、「セッション」を使用するよりも利点はありません。JWT は、サーバー上でセッション状態を維持するのではなく、クライアント上でセッション状態を維持する手段を提供します。
これを尋ねるときによく言われるのは、「サーバー側セッションを使用する場合と比べて JWT を使用する利点は何ですか」ということです。
サーバー側セッションでは、セッション識別子をデータベースに保存するか、メモリ内に保持してクライアントが常に同じサーバーにアクセスするようにする必要があります。 どちらにも欠点があります。 データベース (またはその他の集中型ストレージ) の場合、これがボトルネックとなり、維持管理が必要になります。つまり、リクエストごとに追加のクエリを実行することになります。
インメモリ ソリューションを使用すると、水平スケーリングが制限され、セッションはネットワークの問題 (Wi-Fi とモバイル データ間のクライアントのローミング、サーバーの再起動など) の影響を受けます。
セッションをクライアントに移動すると、サーバー側セッションへの依存関係がなくなりますが、独自の課題が生じます。
- トークンを安全に保管します。
- 安全に輸送します。
- JWT セッションを無効にするのが難しい場合があります。
- 顧客の主張を信頼する。
これらの問題は、JWT やその他のクライアント側セッション メカニズムでも同様に発生します。
特に、JWT はこれらの最後の問題に対処します。JWT とは何かを理解すると役立つかもしれません。
これはちょっとした情報です。ユーザー セッションの場合、ユーザー名とトークンの有効期限を含めることができます。ただし、セッション ID やユーザーのプロファイル全体など、何でもかまいません (ただし、これはしないでください)。このトークンには、悪意のある第三者が偽のトークンを生成することを防ぐ安全な署名が付いています (署名するにはサーバーの秘密キーにアクセスする必要があり、署名後にトークンが変更されていないことを確認できます)。Cookie やAuthorizationヘッダーが送信されるのと同じように、リクエストごとに送信します。実際、これらは HTTPAuthorizationヘッダーで送信されるのが一般的ですが、Cookie を使用しても問題ありません。
トークンは署名されているため、サーバーはその発行元を検証できます。サーバーは安全に署名する自身の能力を信頼していると想定します (標準ライブラリを使用する必要があります。自分で署名しようとせず、サーバーを適切に保護してください)。
トークンを安全に転送するという問題に関しては、一般的には暗号化されたチャネル (通常は httpS) 経由で送信するのが答えです。
クライアントにトークンを安全に保存するには、悪意のあるユーザーがトークンにアクセスできないようにする必要があります。これは主に、悪意のある Web サイトの JS がトークンを読み取って送信できないようにすることを意味します。これは、他の種類の XSS 攻撃を軽減するために使用されるのと同じ戦略を使用して軽減されます。
JWT を無効にする必要がある場合、これを実現する方法は確実にあります。「他のセッションの終了」を要求したユーザーのみのユーザーごとのエポックを保存することは、おそらく十分な非常に効率的な方法です。アプリケーションでセッションごとの無効化が必要な場合は、セッション ID を同じ方法で維持し、「強制終了されたトークン」テーブルを完全なユーザー テーブルよりもはるかに小さく維持することができます (許可されている最長のトークン有効期間よりも新しいレコードのみを保持する必要があります)。したがって、トークンを無効にする機能により、このセッション強制終了状態を維持する必要があるという点で、クライアント側セッションの利点が部分的に打ち消されます。これは、元のセッション状態テーブルよりもはるかに小さいテーブルになる可能性が高いため、検索は依然として効率的です。
JWT トークンを使用するもう 1 つの利点は、おそらくすべての言語で利用可能なライブラリを使用して実装するのが比較的簡単なことです。また、初期のユーザー認証スキームから完全に切り離されているため、指紋ベースのシステムに移行する場合でも、セッション管理スキームを変更する必要はありません。
より微妙な利点: JWT は「情報」を運ぶことができ、クライアントがこれにアクセスできるため、いくつかのスマートなことを実行できるようになります。たとえば、ログアウトする数日前にセッションが期限切れになることをユーザーに通知し、トークンの有効期限に基づいて再認証するオプションを提供します。想像できるものは何でも可能です。
つまり、JWT は他のセッション技術のいくつかの疑問や欠点に答えてくれます。
DB ラウンドトリップを排除できるため (または少なくともクエリするテーブルがはるかに小さくなるため)、認証が「安価」になり、結果として水平方向のスケーラビリティが可能になります。
改ざん防止のクライアント側クレーム。
JWT は、安全な保管や転送などの他の問題には対応していませんが、新たなセキュリティ問題は発生しません。
JWT については否定的な意見が多くありますが、他の種類の認証と同じセキュリティを実装すれば問題ありません。
最後にもう 1 つ注意点があります。これは Cookie とトークンの問題ではありません。Cookie は情報ビットを保存および転送するためのメカニズムであり、JWT トークンを保存および転送するためにも使用できます。