転送：https://blog.csdn.net/daimengs/article/details/81088172
トークンとは何ですか
「トークン」トークンの手段は、クライアントの識別要求として、サーバが生成し、一連の文字列です。
ときにユーザーが最初にログインすると、サーバーは、トークンを生成し、クライアントの要求がもう一度ユーザー名とパスワードを持参する必要がなく、このトークンのデータを取りに来た後、このトークンはクライアントに返されます。
単純な組成のトークン、UID（ユーザの一意のID）、時刻（現在時刻のタイムスタンプ）、サイン（署名、一定の長さに圧縮するためにハッシュアルゴリズムの最初のいくつかのトークン進文字列です。 ）漏れトークンを防ぎます。
認証の概要
HTTPはステートレスなプロトコルであるので、それは私たちのアプリケーションを訪れた人を知りません。ここでは、クライアントとして、ユーザは、クライアントは、ユーザー名やパスワード認証を使用していますが、次回は、その後検証する必要がある場合、クライアントは要求を再送信します。
一般的なソリューションは、ユーザがログインを要求した場合、問題はないならば、あなたはユーザのログインで、この状態で記録し、その後、クライアントクライアントに送信するレコードIDを置くことができ、サーバー上のレコードを生成し、ありますクッキーに保存されているこのIDを受信した後、次の時間は、ユーザは、サーバがクッキー内の情報を確認しますので、私はここに、対応するサーバ側を見つけることができれば、あなたが見る、このクッキーをもたらすことができ、再びサーバに要求を送信します記録、可能な場合、ユーザが認証されたことを示す、ユーザーがクライアントに返され、要求されたデータを置きます。
上述のプロセスは、セッションの使用で、id値がセッションIDです。私たちは、ユーザーセッションがサーバー上で生成される格納する必要があり、セッションは、メモリ、ディスク、またはデータベースに保存されます。
トークンベースの認証メカニズム
認証方法のトークンメカニズムを使用して、サーバ側に記録ログオンは、ユーザーのを保存する必要はありません。プロセスについて：
クライアントが要求をログに記録するためのユーザー名とパスワードを使用しています。サーバーは、ユーザー名とパスワードを確認し、要求を受信します。認証が成功すると、サーバーは、トークンを生成し、クライアントにこのトークンを送信します。それはトークンストアを受け取った後、クライアントは、中にクッキーやローカルストレージ（ローカルストレージ）に配置することができます。クライアントがサーバにリクエストを送信するたびに、トークン発行したサーバを持参する必要があります。サーバーは要求を受信し、検証が成功した場合、トークンと内部のクライアント要求は、クライアントが要求されたデータを返すことを確認します。
ログイン認証トークンメカニズムを使用して、次の方法を持つことができます。
トークン機器など。MACアドレス
クライアント：ログインすると、クライアント取得装置のMACアドレスは、それがサーバーにパラメータとして渡されます
サーバ：サーバは、このパラメータを受け取り、それをトークンとしてデータベースに格納され、トークンが、セッションに設けられているが、それは、変数によって受信されます。クライアントの要求が傍受を統一する必要がありますたびに、クライアントはトークン比較してトークンとサーバ側のセッションを渡し、ログインと同じが成功し、異なったが拒否されます。
この方法では、クライアントとサーバは、一意のIDを統合し、各デバイスは、一意の識別子を持っていることを確認してください。再度ログインすることなく、クライアントの利点は、単にタイムアウトの問題のために後で使用することができていたら、ログインサーバーで処理され、不利な点は、サーバーがMACアドレスを保存する必要があるということです。
B。トークンセッションIDを使用します
クライアント：クライアントは、ユーザー名とパスワードを運びます
受信したユーザ名とパスワードを確認し、セッションIDが正しくクライアントにローカルトークン背面にデータとして取得し、クライアントのみ帯域要求の後：サーバー。
このアプローチの利点は便利ですが、データを格納しない、欠点は、セッションの有効期限が切れたとき、クライアントは再び要求データにログインしなければならないということです。
もちろん、一部の高セキュリティアプリケーションのために、それは、ユーザー名とパスワード認証トークンと同時に二つの方法、デバイスのMACアドレスの組み合わせの形をとることができます。
APPは、トークン認証メカニズムを使用します
ユーザーは、APPを記録、APP側がサーバに暗号化されたユーザ名とパスワードを送信し、検証が成功した場合、ユーザー名とパスワードの検証は、トークンなどの文字サーバー容量に格納されたビットの対応する番号を生成し、トークンに戻りますAPPの終わり。
APPは、後で再び要求した場合、我々は、このトークンは、サーバー側の検証トークンを持参しなければならないところ、必要とする人が確認するために、成功したユーザーが再度ログインすることができ、リターンエラーメッセージに所望の結果、エラーを返しました。その中でも、サーバは、APPは、すべての検証トークンと有効期限を要求するたびに、有効なトークンを設定します。
トークンストレージ
トークンは、データベースに保存することができますが、問合せトークンが長すぎる時間の喪失につながることが可能であるトークン（実際には再認証が似ている失われたトークンが、ユーザーはすべての権利の認定を手放すていない、あまりにも頻繁に投げないでください）。
長すぎるクエリを避けるためにメモリにトークンすることができます。だから、クエリの速度は絶対に問題はないことを、トークンはまた、多くのメモリを占有していない32の文字列、百万または千万でのユーザアプリケーションの量、であっても、あまりにも多くの占有メモリを心配しないでください。
トークンの暗号化
トークンは、暗号化されていない場合は、簡単にコピーして、悪意のあるログインするために使用することができます漏れることは容易です。持っているために、暗号化の方法：
対称暗号化、復号化のためのトークンストアに格納されているときに再び使用する場合。署名が言及した資料の冒頭に署名：リクエストURL、タイムスタンプ、すべての3つのトークンを組み合わせて、アルゴリズムによって暗号化されています。
好ましくは2を組み合わせるために使用されます。
もう一つのポイントは、ネットワークレベルでのトークンの使用クリアテキストの送信は、それは非常に危険ですので、HTTPSプロトコルを使用するようにしてください。