A、セッション状態を維持し、欠点
（1）と、ユーザー初めて認証のためのブラウザ、サーバー、ユーザー名とパスワードを使用してサーバーにアクセスするためのユーザー名とパスワードを使用して。
（2）認証に成功すると、サーバが生成し、セッションデータの保存、セッションIDクッキーによるブラウザへの復帰、クッキー、ブラウザセッションIDレコード。
（3）は、ブラウザのアクセスが再び、ときにデフォルトが運ぶあなたは、再度ログインし、必要なデータブラウザを返却する必要はありません、クッキーセッションIDを、有効なサーバーがあるか、現在のセッションを維持することがある場合は、セッションIDを確認してください。
利点：
セッションの主な成果は次のとおりです。再度ログインするために別のページを開く必要はありませんユーザーログインセッション情報を保持します。
（メモリ内のセッションのプレゼンスサービスがあれば）、再度ログインするようにユーザーに依頼し、セッションがタイムアウトするか、サーバーが再起動されると、起源はそのうちそれが自動ログインです。
短所：
1は、通常、メモリ内のセッション、あまりにも多くのユーザーで、圧力はストレージサーバが増加します。
2、セキュリティ上の問題、CSRF、クロスサイトリクエストフォージェリ攻撃があります。
セッションはクッキーが傍受された場合、ユーザーは、クロスサイトリクエストフォージェリ攻撃の影響を受ける可能性があり、クッキーベースのユーザIDです。
図3は、拡張が強くない、直接分散サービスの展開をサポートすることはできません。
二、トークン（トークン）認証機構
クライアントに戻って、しかし：（1）クライアントのログインに成功したユーザのID、ユーザーIDと対応するユーザ情報が暗号化され、サーバは、文字はレスポンスボディ{「文字列」トークン}で暗号化されますトークンは保存されません。
（2）クライアントトークンは、クッキーまたはのsessionStorageのlocalStorageまたはを通じて格納することができます。
（3）クライアントの要求が再びときはキャリーにデフォルト設定はありません、あなたが情報を解読するために、トークン、トークンサーバを運ぶリクエストヘッダフィールド認可と認証情報に追加する必要があり、それが照会された場合に復号化が完了した後、クエリのユーザーデータ、認証実装することにより、状態を維持します。
だから、インスタント複数のサーバと、サーバは単にクエリトークン復号化し、ユーザデータをやった、それがトークン認証メカニズムをベースにしたアプリケーションではないことをどの手段、利用者の認証情報やセッション情報を保持するために、サービス側を必要としません。あなたは、スケーラビリティセッションの欠点を解決するための拡張機能の適用を促進しており、ユーザーがログインしているサーバーを検討する必要があります。
