JWT とセッション認証の比較

一般的に、アプリケーションを使用する最初のステップは認証です。エンドユーザーは自分の身元を証明するための資格情報を提供し、成功裏にログインします。このステップの後、アイデンティティシステム（例: アイデンティティプロバイダー、認証サーバーなど）は、ユーザーが誰であり、どのリソースにアクセスできるかを認識します。

HTTP は本質的にステートレスであるため、セッション内の各リクエストは独立しており、以前の情報を記憶しません。ユーザーが毎回アクションを実行する度に再認証を行うのは面倒であり、ユーザーエクスペリエンスを損ないます。

ここに登場するのが、セッションベースの認証とJWT (JSON Web Tokens) 認証です。この二つは認証状態を維持するための人気のある方法です。それぞれに独自の利点とトレードオフがあり、どちらを選ぶかはアプリケーションの特定のニーズに依存します。もし二つのうちどちらを選ぶか迷っているなら、このガイドが助けます。

セッションベースの認証とは何ですか？#

セッションベースの認証は、ユーザーの認証状態を保持するためにサーバーに依存します。セッションを作成・管理することで、サーバーはユーザーがログインしたままアプリケーションと継続してやり取りできるようにします。これにより、リクエスト毎に再び資格情報を入力する必要がなくなります。

セッションベースの認証の仕組み#

セッション作成

1. ユーザーが認証し、何らかの資格情報を提供します（例: メールアドレスとパスワード）。
2. 資格情報が有効であれば、サーバーはそのセッションを表す永続的な記録を作成します。セッションには、ランダムな文字列、ユーザー識別子、セッション開始時間、セッションの有効期限などの情報が含まれます。 
3. SessionID はデータベースに保存され、ユーザーのクライアントにクッキーとして返されます。

セッション検証

1. プロセスはユーザーによって手動でトリガーされるか（例: タブをクリックする、ページをリフレッシュする）、クライアントによって自動的にトリガーされるかです（初回ページ読み込み時または SessionID を含む API コール時など）。
2. 次の各コールは、クライアントからサーバーへのセッションクッキーを含む HTTP リクエストを送信します。
3. サーバーは、サーバーに保存されているセッションデータを参照して SessionID を検証します。
4. 有効であれば、サーバーはリクエストを処理し、ユーザーを認証します。

セッションの無効化方法#

セッションはリアルタイムで無効にすることができ、迅速なアクセスの取り消しが必要な場合に便利です。

• ユーザーが手動でログアウト: サーバーがセッションレコードを削除し、ユーザーをログアウトさせます。
• 管理者が強制的にユーザーをログアウト: 管理者やシステムは、データベースから削除することで特定のセッションを終了できます。例えば、セキュリティ侵害が発生した場合です。
• セッションの有効期限: セッションは一定の非活動時間後、または固定の時間制限後に自動で期限切れとなることができます。

セッションベースの認証の利点#

• シンプルで信頼性が高い: セッションレコードは、明確で集中型の情報源を提供し、高い信頼を確保し、認証決定をより信頼できるものにします。
• リアルタイム取り消し: セッションレコードを削除または無効化することで、ユーザーのアクセスは迅速に取り消すことができます。

セッションベースの認証の短所#

• 分散システムでの遅延: 複数のサーバー間でセッションデータを維持するためには、常にセッションストアを同期する必要があります。これにより、サーバーがリクエストするたびにセッションストアを確認するため、追加の遅延が生じます。
• リソース消費量が多い: 各セッションはサーバーリソースを消費し、ユーザーベースが拡大するにつれてパフォーマンスに影響を及ぼします。
• セキュリティリスク: セッションハイジャック（盗難されたセッションクッキーによる）により、無許可のアクセスがユーザーアカウントに行われる可能性があります。
• API 用途に限定される: セッションベースの認証は、モバイルアプリにはあまり適していません。セッションデータをサーバーに保存するため、多くのユーザーがいると負荷と複雑さが増します。さらに、クッキーを使用するため、モバイルデバイスでの取り扱いが難しくなります。

JWT 認証とは何ですか？#

JSON Web トークン (JWT) は、すべての関連するユーザー情報をトークン内に直接埋め込むことで異なるアプローチを取り、JSON オブジェクトを使用しますから。セッションベースの方法とは異なり、JWT はステートレスであり、サーバーは認証レコードを管理しません。

JWT 認証の仕組み#

JWT は 3 つの部分で構成されます：ヘッダー、ペイロード、および署名です。

• ヘッダーは、署名アルゴリズム（例: HS256）およびトークンの種類 (JWT) を含みます。
• ペイロードは、ユーザーのアイデンティティ、ユーザーロール、有効期限などの基本的なクレームを含みます。
• 署名は、ヘッダーとペイロードに署名するためにキーを使用し、署名が改ざんされていないかどうかを検証します。

JWT の発行

1. クライアントがユーザーの資格情報を認証サーバーに送信します（ユニバーサル アイデンティティ プロバイダーは、複数のドメイン間でのアクセス管理に特に有益です）。
2. 認証が成功すると、サーバーはヘッダー、ペイロード、および署名を含む JWT を生成します。
3. 認証サーバーは発行されたトークンをクライアントに送信します。クライアントは、 JWT を（例: クッキー、localStorage、または sessionStorage に）保存します。

セッションベースのワークフローも同様のプロセスに従います。ただし、認証後、ユーザー情報はセッション内にサーバーに格納され、 JWT は保管とその後の使用のためにクライアントに送信されたトークンに依存します。

トークン検証

1. 後続の API リクエストのために、クライアントは Authorization ヘッダー（Bearer <token>）で JWT を送信します。
2. サーバーは秘密または公開鍵を使用して JWT の署名を検証し、そのクレーム（例: 失効、発行者）をチェックします。
3. トークンが有効な場合、サーバーはクライアントに要求されたリソースへのアクセスを許可します。

セッションベースの認証では、サーバーはセッション ストアをクエリする必要があり、特に外部または集中型データベースに依存している場合、遅くなる可能性があります。これに対して、JWT 認証はステートレスであり、必要なすべての情報がクライアント トークンに格納され、署名を使用してセキュリティを確保します。これにより、セッション管理を排除し、より高速でスケーラブルになります、特に分散システムにおいて。

JWT の取り消し方法#

クライアント側では、サインアウトは通常、ローカルセッションをクリアし、トークン（ID、アクセス、リフレッシュトークン）をストレージから削除することを意味します。しかし、JWT 認証の場合、これによりユーザーはローカルでのみサインアウトされ、中央のセッションは認可サーバー上に残ります。その結果、トークンが期限切れになるか、手動で終了されるまで、ユーザーは同じセッション下で他のアプリにアクセスし続けることができます。

JWT（JSON Web トークン）の無効化は、特定の戦略を実装しない限り、JWT はステートレスで発行された後に無効化不可能であるため、セッションベースの認証よりも困難です。一般的な方法には次のようなものがあります：

• 短い有効期限：JWT に短い exp クレーム（例: 15 分）を設定します。期限が切れたら、ユーザーは再認証する必要があります。これにより、トークンが侵害された場合でも、攻撃者がそれを使用できるのは限られた時間であるため、リスクを最小限に抑えることができます。シームレスなユーザーエクスペリエンスを維持するために、リフレッシュトークンを使用して再認証の不便さを最小限に抑えることができます。
• トークンのブラックリスト：重要なケース（例: ユーザーのログアウト、パスワードの変更）に備えて、無効化されたトークンのブラックリストを保持します。サーバーは受信するトークンをこのブロックリストと照合し、一致するものを拒否します。効果的ですが、このアプローチは無効化されたトークンを追跡する必要があり、JWT のステートレスの性質と矛盾し、リストが大きくなると効率が悪化します。
• 無効化エンドポイント：トークン（例: リフレッシュトークン）を無効にする無効化エンドポイントを認証サーバー上に導入します。リフレッシュトークンが無効化されると、それから発行されたアクセス トークンは更新されなくなります。この方法はOAuth2フローでうまく機能します。

JWT 認証の利点#

• 迅速かつ情報豊富: JWT の自己完結型の性質により、クライアントサイドの検証はサーバーのやり取りを必要とせず、より迅速で効率的です。また、トークン内にカスタムクレーム（例: ユーザーロールやその他の関連データ）を含めることができ、サーバーがデータベースを照会せずにロールを判断できるようにします。
• 強化されたセキュリティ: JWT は署名と暗号化技術を使用し、攻撃を困難にします。
• クロスドメイン対応: JWT はシングルサインオン (SSO)およびクロスドメイン認証に最適です。同じトークンで複数のドメインまたはサービスで認証を行うことができます。
• モバイルフレンドリー: JWT はステートレス認証が必要なモバイルアプリケーションに最適です。トークンはクライアントサイドに保存され、各リクエストに同伴して送信され、効率性と使いやすさを向上させます。

JWT 認証の短所#

• JWT はリアルタイムに更新されない

  一旦署名された JWT は取り消したり更新したりできません。署名が有効で期限切れでない限り、有効とされます。

  ユーザーのアクセス権が変更された場合（通常は縮小される）、ユーザーは JWT が期限切れになるまで削除されたリソースへのアクセス権を持ち続けます。同様に、JWT にロールベースの認可情報が含まれている場合、新しい認可範囲は古い JWT が期限切れになるまで影響しません。言い換えれば、JWT はリアルタイムでの取り消しには適しておらず、ユーザーは適切な期限を設定することでこれを軽減できます。

• 複数デバイスと取り消しのジレンマ

  発行されたすべての JWT が期限切れになる前に、このユーザーのすべてのデバイスを取り消すための検証は不可能です。理論的には署名キーを取り消して JWT を無効にすることが可能ですが、この場合そのキーを使用しているすべての JWT が無効になります。そしてキャッシュキーの扱いが障害になり、このアプローチは単純なユーザー取り消し操作には実用的ではありません。

いくつかのアイデンティティプロバイダーは、これらの JWT 問題に対する事前構築されたソリューションを持っているかもしれません。詳しくは「JWT 認証体験を向上させるためのベストプラクティス」をご覧ください。

JWT とセッションの違いは何ですか？#

セッションと JWT は、ステートレスな HTTP 環境における認証および認可コンテキストを持続させるための二つの人気のあるアプローチです。これら二つの方法はそれぞれ利点と欠点を持っており、それぞれ異なる利点と欠点を提供します。

セッションは、個々のリクエストに対する認可に強力な保証を提供し、安全に実装するのが簡単です。しかし、サーバーのデータベース検証に依存するため、遅延のオーバーヘッドが生じ、非常に応答性の高いアプリケーションのユーザー体験に悪影響を与える可能性があります。

一方、JWT は、より迅速な認可と外部アプリとの相互運用性に利点がありますが、セキュリティの複雑さに対処するためには、より多くの開発者の労力が必要です。たとえば、ユーザーのアクセスが取り消された際にクライアントに通知するためにWebhookを使用し、クライアントがキャッシュされた JWT をクリアしてユーザーに再認証を促すことができます。

トークンベースの認証は、スケールアップに適しており課題も管理可能であるため、ますます多くのモダンなアプリケーションに採用されています。

セッション vs. JWT: 適切な方法の選択#

あなたの認証方法は、アプリのアーキテクチャーと特定のニーズに合ったものであるべきです。以下に選択のためのクイックガイドを示します：

セッションベースの認証が必要な場合#

セッションベースの認証は、リアルタイムのセッション管理が必要であったり、集中管理が必要だったり、スケーラビリティがあまり重要でない場合に最適です。ここで優れている点：

• 持続的セッションを持つ Web アプリケーション

  オンラインショッピングサイトのようなプラットフォームでは、ユーザー、ショッピングカート、および訪問中の嗜好を追跡するためにセッションが不可欠です。

• リアルタイムのセッション管理が必要なアプリケーション

  銀行や金融サービスなどのアプリケーションは、サーバー制御されたセッションデータによる強力なアクセス管理とセキュリティを享受します。

• 単一サーバーまたは小規模システム

  重度なスケーラビリティニーズがない内部ツールや小規模アプリは、簡単なセッション管理によって使いやすく信頼性があります。

JWT 認証を使用する場合#

JWT 認証は、スケーラビリティ、効率、分散システムを優先するアプリケーションにより適しています。クライアントとサーバー間のステートレスなやり取りに特に役立ちます。以下にトークンベースの認証を検討する場面を挙げます：

• シングルサインオン (SSO)

  JWT は シングルサインオンに最適であり、ユーザーが一度認証し、同じトークンを使って複数のサービスやアプリケーションにシームレスにアクセスすることを可能にします。OAuth 2.0 と OIDC を使用してクラウドベースのアプリケーションを安全にする詳細説明、および JWT 形式のアクセス トークンと ID トークンを参照してください。

• モバイルアプリケーション

  モバイルアプリは通常、JWT を認証に選びます。トークンはデバイス上に安全に保存でき、各 API リクエストに同伴して送信されます。Android/iOS 向け JWT 認証のクイック統合を探ってください。

• マイクロサービスアーキテクチャ

  マイクロサービス環境では、JWT により各サービスが中央のセッションストアに依存することなくトークンを独立して検証でき、スケーラビリティと効率性を確保します。

• クロスドメイン認証

  JWT は、複数のドメインやサブドメイン（例: api.example.com、dashboard.example.com、docs.example.com）を含むシナリオに優れています。クッキーとは異なり、追加の依存関係なしにドメイン全体で認証を可能にします。

• API と Web サービス

  RESTful API や Web サービスは、軽量で持ち運びでき、サーバーサイドのセッション管理を必要としないため、認証に JWT をよく使用します。あなたのアプリがリソースと直接通信する必要があるシナリオにおけるマシンツーマシン認証について詳しく学んでください。

JWT 認証体験を改善するベストプラクティス#

JWT 認証は優れたツールですが、ユーザー体験に影響を及ぼす課題を伴うことがあります。 Logto は、これらの課題を克服するための簡単かつ信頼できるソリューションを提供し、安全かつ効率的な認証のためのトップチョイスとなっています。

JWT を使用したユーザーサインアウト問題の処理#

JWT 認証で一般的な問題の一つは、適切なユーザーサインアウト体験を提供することです。Logto は、その使いやすい SDK によってこのプロセスを簡素化します。

• クライアントサイドでトークンとローカルセッションをクリアし、ユーザーを Logto のエンドセッションエンドポイントにリダイレクトすることで、クライアントアプリケーションとサーバーの両方でセッションを簡単に終了できます。
• さらに、Logto はバックチャネルログアウトをサポートし、ユーザーがサインアウトする際に同じセッションを共有しているすべてのクライアントアプリケーションに通知するための認証サーバーを有効にします。

これにより、エコシステム全体で一貫性のある安全なセッション管理が確保されます。サインアウトメカニズムとサインアウトの実装方法について詳しく学んでください。

ユーザー権限変更の処理#

JWT を利用してユーザー権限のリアルタイム変更を管理することも困難です。JWT はステートレス設計であるため、更新された権限やロールは、トークンの有効期限が切れるまで反映されない可能性があります。Logto はこれを効果的に処理するための戦略を提供します：

• このユーザーの権限を減少させる場合: 短いアクセス トークンの有効期限を設定するか、API コールを通じて動的に権限を確認します。
• このユーザーに新しい権限を追加する場合: 認証サーバーを更新して新しい許可範囲を含め、これらの変更を適用するためにユーザーに再同意させます。

これらのソリューションは権限を最新の状態に保ち、より安全で応答性の高いシステムを確保する助けとなります。ユーザー権限のリアルタイム変更を管理する詳細情報についてです。

Logto は、スケーラブルなアイデンティティアクセス管理インフラストラクチャであり、クラウドサービスとオープンソース版の両方が利用可能な完全なアイデンティティソリューションを提供します。