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

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

HTTPは本質的にステートレスであるため、セッション内の各リクエストは独立しており、以前のリクエストからの情報を思い出すことはありません。ユーザーに毎回のアクションで再認証を求めるのは面倒で、ユーザーエクスペリエンスを損ねます。

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

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

セッションベースの認証は、ユーザーの認証状態を保持するためにサーバーに依存しています。セッションを作成し管理することによって、サーバーはユーザーにログインし続けてもらい、毎回のリクエストで資格情報を再入力せずともアプリケーションとやり取りを続けることができます。

セッションベース認証はどのように機能しますか？#

セッション作成

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

セッションの検証

1. このプロセスはユーザーによって手動で（例：タブをクリック、ページを更新）またはクライアントによって自動的に（例：初期ページロード中、または SessionID を使用したAPIコールによって）トリガーされます。
2. それぞれの後続の呼び出しは、クライアントからセッションクッキーを含むHTTPリクエストをサーバーに送信します。
3. サーバーはセッションデータを参照して SessionID を検証します。
4. 有効である場合、サーバーはリクエストを処理し、ユーザーを認証します。

セッションを無効にするにはどうすればよいですか？#

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

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

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

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

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

• 分散システムの遅延: 複数のサーバーにまたがってセッションデータを維持する場合、常にセッションストアを同期する必要があります。これにより、サーバーが要求を行うたびにセッションストアを確認しなければならないため、追加の遅延が生じます。
• 高いリソース消費: 各セッションはサーバーリソースを消費し、ユーザーベースが拡大する場合、パフォーマンスに影響を及ぼします。
• セキュリティリスク: セッションハイジャック（盗まれたセッションクッキー経由）により未承認のアクセスが可能になります。
• APIには限定的な使用: セッションベース認証はモバイルアプリにとってあまり向いていません。サーバー上のセッションデータを保存し、多くのユーザーが使用する場合、負荷や複雑さが高まります。加えて、クッキーはモバイルデバイスで扱いにくいです。

JWT 認証とは何ですか？#

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

JWT 認証の動作方法#

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

• ヘッダーには署名アルゴリズム（例：HS256）とトークンのタイプ（JWT）が含まれています。
• ペイロードにはコアクレームが含まれ、ユーザーのアイデンティティ、ユーザーロール、有効期限が入ります。
• 署名はキーを使用してヘッダーとペイロードに署名し、署名が改ざんされていないことを確認できます。

JWT 発行

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

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

トークン検証

1. 後続の API リクエストの場合、クライアントは JWT を Authorization ヘッダー (Bearer <token>) に含めて送信します。
2. サーバーは秘密または公開キーを用いて JWT の署名を検証し、そのクレーム（例：有効期限、発行者）を確認します。
3. トークンが有効である場合、サーバーはクライアントに要求されたリソースへのアクセスを許可します。

セッションベース認証は、セッションストアをクエリするためサーバーが必須となり、特に外部または集中化されたデータベースに依存している場合、遅くなりがちです。これに対して、JWT 認証はステートレスで、すべての必要な情報はクライアントのトークンに保存され、署名を利用してセキュリティを保証します。これにより、セッション管理は不要になり、特に分散システムでより迅速でスケーラブルなものになります。

JWT を無効にするにはどうすればよいですか？#

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

JWT（JSON Web トークン）の取り消しは、ステートレスなので、特定の戦略を実施しない限り、発行後に無効にすることができません。一般的な方法には以下が含まれます：

• 短い有効期限: 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 をクリアし、ユーザーを再認証させます。

トークンベースの認証がスケールアップにさらに適しているため、それの欠点が管理可能であれば、より多くの現代的なアプリケーションで採用されています。

セッション対 JWT: 適切な方法を選択#

認証方法はアプリケーションのアーキテクチャと特定のニーズに応じて選ばれるべきです。ここでは、選択する際の簡単なガイドを提供します：

セッションベースの認証を使用すべき時#

セッションベースの認証は、リアルタイムのセッション制御が必要、集中管理が求められる、または拡張性が重大な懸念ではない場合に最適です。以下の場合に輝きます：

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

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

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

  銀行や金融サービスのようなアプリケーションは、サーバー制御のセッションデータから恩恵を受け、堅牢なアクセス管理とセキュリティを保証します。

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

  大規模な拡張性が必要でない内部ツールや小規模アプリは、簡単なセッション管理で使いやすさと信頼性が向上します。

JWT 認証を使用すべき時#

JWT 認証は、拡張性、効率性、分散システムを優先するアプリケーションに適しています。それはクライアントとサーバー間のステートレスなやり取りに特に有用です。以下のためにトークンベース認証を検討してください：

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

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

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

  モバイルアプリは API リクエストと共に安全にトークンを保存できるため、JWT を認証に使用することが多いです。Android / iOS 用の JWT 認証の迅速な統合を探ります。

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

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

• クロスドメイン認証

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

• APIとWebサービス

  RESTful API と Web サービスは、軽量でポータブルなため、JWT 認証を一般的に使用します。 サーバー側のセッション管理が不要になるため、マシン対マシンの認証 のシナリオについて詳しく学びます。

JWT 認証体験を向上させるベストプラクティス#

JWT 認証は優れたツールですが、ユーザーエクスペリエンスに影響を与える課題も伴います。Logto は、これらの障害を克服するための簡単で信頼性の高いソリューションを提供し、安全で効率的な認証を実現するためのトップの選択肢です。

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

JWT 認証における一般的な問題の一つは、適切なユーザーサインアウト体験を保証することです。Logto はその即対可能な SDK により、このプロセスを簡素化します。

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

これにより、エコシステム全体で一貫性のある安全なセッション管理を保証します。サインアウトの処理について詳しく学びます。

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

JWTでユーザーの権限のリアルタイムの変更を管理することは難しい場合があります。JWTはステートレスであるため、更新された権限や役割はトークンが期限切れになるまで有効にならない可能性があります。Logto はこの問題に効果的に対処するための戦略を提供します：

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

これらのソリューションは、権限を最新の状態に保ち、より安全で、より応答性の高いシステムを保証します。権限変更の処理について詳しく学びます。

Logto は、スケーラブルなアイデンティティアクセス管理インフラとして、クラウドサービスとオープンソース版の両方を提供する完全なアイデンティティソリューションです。