進化のアイデンティティの伝統的な角度トークンベースの認証から身元を確認するために、Webアプリケーションからのこの記事では、セッション、クッキー、トークンを導入しています。
昔、ウェブは、イエローページのネットワークとして、基本的な文書としてアプリケーションを閲覧します。ただブラウジングので、サーバは文書を閲覧している時間の一定期間内に特定のユーザーを記録する必要はありません、すべての要求は、サーバーの新しいHTTPプロトコルが新しいです。
アイデンティティのセッションベースの検証
など、ログインする必要があり、ショッピングなどのインタラクティブなWebアプリケーションの台頭を持つサイト。そうしない場合は、ユーザーがセッションを（ユーザーがログオンする必要がある場合、簡単に言えば？セッションで何を管理するために、あるオペレーティングされているシステムへログインしているレコードにある新しい問題につながり、それは、簡単な会話として理解することができますそれは単純な接続であり、ログインしてください。）、例えば、異なるユーザが異なる製品は、各ユーザ領域を分離する必要があるショッピングカートに追加しました。HTTPリクエストはステートレスなのでので、各ユーザーがセッション識別子（セッションID）に割り当てられていること方法を思いついた、簡単な話ではどちらも繰り返し、簡単に偽造する法律を見つけることではありませんサーバは区別することができるようになりますので、ランダムな文字列は、その各ユーザーが同じではありません識別子セッション、毎回受信するユーザーが開始は、クライアントからサーバへのHTTPリクエストは、一緒にこの文字列は、以上送信しますだった人は、どのように、クッキーを使用して、一般的なデフォルトの「アイデンティティ」を保存するために、クライアント（ブラウザ）として、セッション識別子（セッションID）は、クライアントのクッキーに存在しています。
これは、各ユーザ（クライアント）が唯一のセッション識別子（セッションID）を保持する必要があり、サーバは、すべてのユーザーのセッションIDを保存する必要があることをユーザーに区別の問題を解決するが、新たな問題につながっている間（セッションID）。ユーザーは、サーバーがより徐々になっアクセスする場合、我々はサーバー容認できないオーバーヘッドであると言われて、何百万、数十のでも、数千人を保存する必要があります。別の例として、サーバは、セッションIDは、ボブが要求たらどのように行うには、サーバBに転送されるという仮定の下で、サーバーA上に保存されていることを、サーバAシステムによる2台のサーバのクラスタ、および暁明ログがありますか？サーバーB暁明のセッションIDではないことがあります。
いくつかは、この問題を解決できないだろう、暁明ログ場合は、必ずサーバーA上（スティッキーセッション）をログに記録することを言うかもしれませんか？そのサーバーAがハングアップした場合はどのようにそれを行うには？またはボブは、サーバーBに要求を転送します
このように、それが唯一のクラスタの共有間のセッションレプリケーションを行うだろう、セッションIDは、以下に示すように、2台のマシン間で複製されますが、サーバーのパフォーマンスとメモリが巨大な挑戦を提示しています。
セッションのアイデンティティの進化を理解するためのセッションによってトークンの検証、クッキー、トークンは、
memcachedはメモリオブジェクトキャッシュシステムを分散しているのでそのため、すべてのユーザーの考えは、セッションがそれのストレージを集中場合は、キャッシングサービスのMemcached--を考えますセッションは、同期を達成するために使用することができます。それは避けるのコピーへの道があるので、セッションIDは、この場所では、中央サーバ上のデータにアクセスするすべてのサーバーに格納される可能性がありますが、メイク、この「でペットのセット数千人は、」単一障害点を再び現れました、サーバーがダウンしているのセッションを保存するための責任があること、すべてのユーザーが再びに戻ってログインする必要があり、ユーザーが受け入れることは困難です。
セッション、クッキーの進化を理解するために、セッショントークン認証によって、トークンは
、単に、信頼性を高めるために、単一障害点を回避するために、混乱のクラスタサーバのセッションを保存しますが、セッションは無限の問題を引き起こしたものを、どんなに。
サーバはこのセッションにそれを保存する必要がありますなぜ一部の人々はちょうどそれをしないで保存するには、各クライアントを聞かせて、だろうか？サーバがセッションIDを保存していない場合でも、どのクライアントから送信されたセッションIDが実際にそれを生成するためのサーバーであることを確認しますか？検証がなければ、サーバはそれがログオンし、正当な利用者であるかどうかを判断することはできませんが、ここでの問題は、検証することで、セッションが生じる検証問題を解決するための唯一の解決策は、他のオプションが、されているのですか？
トークン認証をベース
たとえば、暁明はすでにシステムにログインし、サーバは彼に送信トークンによってサーバこのトークンへのHTTPリクエストのアクセスを介して再び提案ユーザID暁明、後続の暁を含み（トークン）、HTTPヘッダーそれは付属していません。
サーバーは、認証トークンが偽造ではなく、自己生成されている必要があり。あなたは誰もが偽造できることを確認していない場合は、トークン（トークン）とセッションIDは、本質的な違いは、どのように他の人が偽のできないようにすることですか？そして、データが署名（サインオン）サーバーで、右、例えば、HMAC-SHA256暗号化アルゴリズムを作るために、プラスサーバはキーだけを知って、データが署名、署名およびトークンとして一緒にデータを作りますクライアントは、トークンが、このようなクッキーローカルストレージなどのストレージとして、それを保存することができますまたはキーがサーバーに加えて、他のユーザーを知らなかったので、あなたが偽のトークン（トークン）することはできません受信した後、クライアントへ。
セッション、クッキー、トークンのアイデンティティの進化を理解するためのセッションでトークンの検証
には、このようにトークン暁明は、サーバーを送信する際に、サーバは、トークンを保存する必要はありません、サーバーは同じアルゴリズムと同じHMAC-SHA256を使用しています同じ場合には鍵が、その後、署名後に計算されたデータ、および署名がトークンには、ボブは、認証が成功したこと以上ログインしたことを示す、比較を描きます。同じでない場合は、その要求が偽造されています。
セッション、クッキー、トークンの進化を理解するために、セッショントークン認証によって
その結果、サーバはまた、スペースのための時間（CPU計算時間を実現し、トークンの検証と同じように、トークンを保存する必要がなく、トークンを生成する必要があります交換セッション収納スペース）。制限なしのセッションIDたときに、ユーザーの訪問が増え、プラスダイレクトマシンは簡単に水平展開を行うことができます、だけでなく、大幅にスケーラビリティが向上します。
