ステートレスおよびステートフルのアーキテクチャ

アプリケーションの状態、つまり、特定の時点でのアプリケーションの状態または品質を指します。ステートレス認証では、セッションやユーザーは保存されず、静的コンテンツのみが含まれます。これは、動的コンテンツ.

ステートレス プロセスは分離されたリソースであり、他のサービスや他のシステムとの対話を参照しません。ステートレス認証 はこのタイプのデータを保存しないため ; 古いトランザクションから情報を取得することなく、コードのその部分でのみ動作します。各 操作は最初から実行されます .

ステートフル認証では、情報を 複数回使用でき、前のトランザクションのコンテキストに基づいて実行されます。したがって、応答や既存のデータを待つ必要があるアプリケーションでは、別のシステムまたはデータベースに存在するかどうかに関係なく、ステートフルが使用されます。

ステートレス認証

ステートレス認証は、資格情報を提供した後、ユーザーが応答としてアクセス トークンを受け取る戦略で構成されます。このトークンには、トークンを発行したサービスやデータベースを継続的に参照する必要がなく、トークンを生成したユーザーを識別するために必要なすべての情報がすでに含まれています。

このトークンは クライアント側 (ブラウザ) に保存されているため、サーバーはペイロードと署名が一致することを確認することによってトークンの有効性をチェックすることしかできません。

ステートレス認証 JWT

JSON Web Token (JWT) は、RFC-7519 で確立された標準を備えたキーであり、宣言の形式で独立したエンティティが含まれており、サーバーがトークンを再検証します。

文字列は、秘密キーを使用して Base64 標準でエンコードされています。例:

メリットとデメリット

利点:

• サーバーのメモリ消費量が少ない。
• 拡張性に優れています。
• API やマイクロサービスなどの分散アプリケーションに最適です。
• サードパーティに依存せず、分離されたアプリケーションでトークンを生成および配布します。
• トークン ユーザー データの簡単な解釈と検証。

欠点:

• アクセス制御が困難です。
• いつでも簡単にトークンを取り消すことはできません。
• 誰かがトークンにアクセスできると、悪意のある第三者の侵入が容易になる可能性があります。
• トークンの有効期限が切れるまでセッションは変更できません。
• JWT トークンはより複雑で、モノリスなどの集中型アプリケーションでは不要になる可能性があります。

ステートフル認証

さまざまなアプリケーション、特にスケーラビリティをそれほど必要としないアプリケーションで一般的に使用され、ステートフル セッションはアプリケーションの バックエンド で作成され、セッション参照が対応するユーザーに送り返されます。 。ユーザーがリクエストを行うたびに、アプリケーションの一部がトークンを生成します。その瞬間から、新しいリクエストごとに、アクセスを再検証するためにこのトークンがアプリケーションに再度送信されます。このモデルでは、ユーザー データに変更があった場合、トークンを簡単に取り消すことができます。

これらは不透明なアクセス トークン、つまり、トークンに関連する識別子やユーザー データを含まない独自形式の 単純な文字列です。受信者は、トークンを検証するために、トークンを作成したサーバーを呼び出す必要があります。

トークンの例: 8c90e55a-e867-45d5-9e42-8fcbd9c30a74

この ID は、トークンを所有するユーザーと一緒にデータベースに保存する必要があります。

メリットとデメリット

利点:

• 一元化された実装ロジック。
• 簡素化されたアクセス管理と制御。
• モノリス、MVC アプリケーション、内部プロセスに最適です。
• 悪意のある第三者に対してより安全です。

欠点:

• トークンの検証を担当する API にオーバーロードがある可能性があります。
• スケーラビリティの点で失敗しました。
• マイクロサービス間で認証を分散することがさらに困難になります。
• 分散アプリケーションでは、認証サービスが失敗すると、他のすべてのサービスが利用できなくなります。
• 実装がより複雑になります。
• サードパーティ システムとの統合がより困難になります。

それぞれのアプローチをいつ使用するか?

JWT トークンとステートレス認証を使用する場合

• API の過負荷を心配せずに、より優れたパフォーマンスが必要な場合。
• サービス間で複数の通信が分散している場合。
• 異なるサービスのシステム内でどのユーザーがアクションを実行しているかを識別する必要がある場合。
• ユーザーのデータを永続化することが目的ではない場合、初期登録のみ。
• サービスへの外部アクセスを生成する必要がある場合。
• システムへの影響を最小限に抑えながら、特定のアクションを実行している人のデータを操作する必要がある場合。

不透明トークンとステートフル認証を使用する場合

• 主にアクセス階層を定義するために、システムのユーザーの完全なアクセス制御が必要な場合。
• 分散サービスや外部サービスとの通信を行わない集中アプリケーション内。

最終的な考慮事項:

• 「API ストレス」などの一部の場所では、わかりやすくするためにこの用語が「API オーバーヘッド」に置き換えられる場合があります。
• 対象読者がより詳しいコンテキストを必要とする場合、「JWT トークン」に関するセクションには、RFC-7519 で言及されている「宣言」が何であるかについてのより詳細な説明が含まれる可能性があります。
• ステートフル認証に関するセクションで、「アプリケーションの一部がトークンを生成する」という表現は、アプリケーションのどの特定の部分がこれを担当するかを説明することで明確になります。