セッション和クッキー
トークンの前にいえば、簡単にセッションとクッキー何について話しています。
-
私たちは、まずそのHTTP要求は、この要求と、そのような私たちのシステムのログとして最後の要求の関係か、の時間、および、システムがする必要がない場合、ユーザー名とパスワードは、各ページを開くことを確認したときにも、単に知らない、ステートレスで知っている必要がありますビットで各ログへのアクセスを避けるために、私たちがセッションを使用する必要があり、ここで、クッキー、ログイン操作、我々は撤退するためのイニシアチブをとるか、ログインタイムアウトは、ログアウトするまで。
-
クッキーは、クライアント（ブラウザ）上のユーザー情報を保存するための仕組みであり、各ブラウザが4キロバイトより通常これ以上、サイズに多少の違いが生じない保存します。
-
私たちは、多くの場合、顧客の許可情報を保存するための基本的な情報のセッションを使用するなどのサーバーに保存されたセッションは、顧客の状況を記録するために使用することができ、ユーザーがログオンする最初の時間が経過した後、サーバはセッションを作成します、ときに、ブラウザの訪問再び、ちょうどその上に、クライアントの情報からセッションを見上げます。
通常、セッションとクッキーを一緒に使用されています。
トークンとは何ですか
しかし、セッション、例えば、分散型アーキテクチャでは、あなたがセッション共有の問題を考慮する必要があり、追加の設計と開発を行う必要があり、場合コストは素晴らしいことだ、あなたはすべてのユーザー・セッション情報を保存するサーバー、問題があるでしょうそうそこに、トークンをあなたはどこにでも保存することができ、一部の人々は、この情報は、クライアントが保存することができます考える、それはこのような理由のためであり、その安全性を確保するため、Redisのは、共有内の情報を保存します。
トークンは、一連の文字列を生成し、サーバは、トークンを要求しているクライアントとして見ることができます。
-
クライアントからサーバーへの最初の訪問は、サーバは、トークン、次のクライアント要求を生成するために、いくつかの暗号化アルゴリズムを使用し、userIdを超える固有の識別パスに基づいて行われます、唯一のトークンを持参する必要がある場合、サーバは、要求を受信しますトークンを検証します。
-
一部の企業は、統一されたログインシステム（シングルサインオン）を構築クライアントシステムに行くトークンを取得し、他のシステムにアクセスするためのトークンを検証するためにそれらを取っただろう、API Gatewayはまた、同様の機能を提供することができ、当社はそのようなクライアントでありますアクセス時間は、インターフェイスへのアクセスを許可さによって検証ゲートウェイトークンに取得し、一定期間後、またはトークンを直します。
認証プロセスの下にトークンメカニズム
全体のプロセスは、このようなものです：
-
クライアントは、パスワード認証が行われているユーザー名を使用しています。
-
（また、統一されたサインオンプラットフォーム、ゲートウェイであってもよい）、サーバは要求を受信した後に認証します
-
認証が成功した後、トークンを発行するサーバーは、クライアントに返します。
-
クライアントは、クライアントにトークン格納された受信した後（クッキー、のlocalStorageでのsessionStorageに保存された）;たびに、トークン、リクエストのヘッダーにトークンヘッダと一緒に、サーバに要求を送信します。
-
トークン有効期限は有効期限が切れ、再確認する必要があります。
-
サーバは、トークン要求ヘッダを受信し、再度署名された確立された規則に従ってユーザのパラメータは、2人の署名が成功した場合、そうでない場合は改ざんデータ要求が失敗したことを合意しました。
（図は、署名を生成する例）
（図の例は、署名を検証します）
概要
-
クッキー：状態があり、サイズ制限があり、ブラウザで種を保存します。
-
セッション：サーバーに格納され、サーバはリソースのオーバーヘッドを有し、分散、クロスシステムを達成しません。
-
トークン：クライアントは、どこにでも分散展開を助ける無制限、無状態を保存することができますトークン。