認証トークンの場合、クライアントは資格情報を送信し、トークンを受信して、後続のすべての呼び出しでこれを使用します。サーバーは、リクエストを検証するためにトークンを保存する必要があります。
たとえば、PHP セッションでは、サーバーはクライアントがすべてのリクエストで送信するセッション UID を返します。サーバーはセッションを保存する必要があります。
どちらの場合も、サーバーは状態を保存する必要があるのに、前者がステートレスと見なされるのはなぜですか?
質問する
1466 次
3 に答える
1
セマンティクス。セッションは通常、各ユーザーに一意の ID を割り当て、その ID をクライアント側の Cookie に格納することによって実装されます。認証トークンはまったく同じものです-ある種のユーザーごとの一意のIDです。Cookie はすべてのリクエストでブラウザによって自動的に送り返されます。認証トークンはすべてのリクエストで送り返すことができますが、通常は実際に認証が必要なリクエストでのみ送信する必要があります。
違いは、これらのトークンがサーバー上でどのように扱われるかに関係しています。セッション ID は、対応するセッションをストレージ (ファイル、データベース レコードなど) からロードするために使用され、そのセッション データはリクエスト間で保持されます。
認証トークンには、関連付けられたセッション ファイルがありません。それはむしろ「私はここにいることを許されている、そしてここにその証拠がある」ということです。
認証システムの実装にセッション ID を使用できない理由はありません。単純なものでさえ$_SESSION['logged_in'] = true、セッションを認証システムに変えます。
于 2013-11-07T15:58:56.367 に答える
0
まず、この質問で説明したのはセッション管理であり、トークン管理ではありません。
SessionId は、ビジネス システム自体によって生成されます。ワークフローは質問と同じです。
トークンは通常、ビジネス システムではなく、独立したシステムによって生成および管理されます。クライアントがトークンを取得した後にビジネス サーバーに後続の呼び出しを送信した場合、ビジネス サーバーはトークン システムからのトークンを検証する必要がありました。したがって、ビジネス システムについて話すときは、ステートレスであると言います。
さらに、私の見解では、トークンは認証を処理するために生まれているのではなく、重要な情報を安全に保つように設計されています。
参照：
于 2015-02-13T10:06:48.713 に答える