5分で従来のトークンとJWTを取得できます

前に書いてあるの

は「Boiled Sheep Sheep_」です。ニックネームは私の名前の略称fyyから来ています。以前頑張っていたブログがハンディキャップのために誤ってキャンセルされ、現在このアカウントを運営しています。
私は小皿料理で、フルスタックエンジニアの方向に一生懸命取り組んでいます。記事はあまり生産的で基本的ではないかもしれませんが、書く記事はすべて注意深く要約されているため、スプレーしないでください。
プログラミングに興味がある場合は、私のダイナミクスに従って、一緒に勉強してください。
読者のみなさん、ありがとうございました！

従来のセッション認証

セッション

httpプロトコル自体はステートレスプロトコルです。つまり、ユーザーがユーザー認証のためにユーザー名とパスワードをアプリケーションに提供した場合、ユーザーは次のリクエストでユーザー認証を再度実行する必要があります。 httpプロトコルによると、どのユーザーがリクエストを行ったかを知ることができないため、アプリケーションがどのユーザーがリクエストを行ったかを認識するために、サーバーにユーザーのログイン情報のコピーのみを保存でき、このログイン情報は応答します時間がブラウザに渡されると、次のリクエストが行われたときにアプリケーションに送信できるようにCookieとして保存するように指示されます。これにより、アプリケーションはリクエストの送信元のユーザーを識別できます。これは、従来のセッションベースの認証です。

セッション認証に基づいて公開された問題

1.大きなメモリオーバーヘッド

各ユーザーがアプリケーションによって認証された後、アプリケーションはユーザーの次の要求の識別を容易にするためにサーバーに記録を作成する必要があります。一般的に、セッションはメモリに保存され、認証されたユーザーの数が増えると、サーバーのオーバーヘッドが大幅に増加します。

2.スケーラビリティが強くない

ユーザーが認証された後、サーバーは認証レコードを作成します。認証されたレコードがメモリに保存されている場合、ユーザーの次のリクエストもこのサーバーでリクエストされる必要があるため、承認されたリソースを取得できます。アプリケーションでは、ロードバランサーの容量はそれに応じて制限されます。これは、アプリケーションのスケーラビリティが制限されることも意味します。

3、CSRF

クロスサイトリクエストフォージェリ。ユーザーIDはCookieに基づいているため、Cookieが傍受されると、ユーザーはクロスサイトリクエストフォージェリ攻撃に対して脆弱になります。

トークン

トークン検証プロセス

ユーザーが初めてログインすると、サーバーはトークンを生成してクライアントに返します。これはクライアントのlocalStorageに保存されています
将来訪問するときは、トークンを携帯し、携帯したトークンをサーバーに保存されているトークン情報と比較する必要があります。

トークンの欠陥

クライアントがログインするたびに、クエリのためにデータベースにアクセスする必要がありますが、データベースへの負荷は軽減されません。

JWTとは

JWT（Json Web Token）はオープンスタンダード（RFC 7519）であり、パーティ間で情報をJSONオブジェクトとして安全に送信するためのコンパクトで自己完結型の方法を定義しています。この情報はデジタル署名されているため、検証および信頼できます。

JWTの使用シナリオ

シーン1

許可：これは、JWTを使用するための最も一般的なシナリオです。ユーザーがログインすると、後続の各リクエストにはJWTが含まれ、ユーザーはトークンで許可されたルート、サービス、リソースにアクセスできます。シングルサインオンは、オーバーヘッドが小さく、ドメイン間で簡単に使用できるため、現在広く使用されているJWTの機能です。

シーン2

情報交換：JSON Web Tokenは間違いなく、当事者間で情報を安全に転送するための優れた方法です。たとえば、公開鍵と秘密鍵のペアを使用してJWTに署名できるため、送信者が本人であることを確認できます。また、署名はヘッダーとペイロードを使用して計算されるため、コンテンツが改ざんされていないことも確認できます。

JWT実装プロセス

ここに画像の説明を挿入

トークンの構造

3つのセクションによるトークン文字列、および。が接続されています。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

最初の段落：アルゴリズム（トークンタイプ）を含むヘッダー（ヘッダー）
- { "alg": "HS256", "typ": "JWT" } このjsonを文字列に変換してから、base64url暗号化を実行します
段落2：ペイロード、カスタム値
- { "sub": "1234567890", "name": "John Doe", "iat": 1516239022 #超时时间 } jsonを文字列に変換し、base64url暗号化を実行します
段落3：署名（ビザ）
- 段落1と2の暗号文を結合する
- HS256暗号化+スプライスされた暗号文のソルティング
- HS256暗号化された暗号文に対してbase64url暗号化を実行します

トークン配信プロセス

ユーザーが初めて正常にログインした後、jwtを使用してトークンを作成し、ユーザーに返して、クライアントのlocalStorageに保存します。
ユーザーが将来再びアクセスする場合は、トークンを携帯する必要があります。サーバーがトークンを取得した後、トークンの検証が実行されます（サーバーはトークンを保存しません）

トークン検証プロセス

サーバーはトークンを取得した後、トークンを3つの部分にカットします
2番目の暗号文でbase64url復号化を平文に実行し、ペイロード情報を取得して、トークンがタイムアウトしたかどうかを確認しますか？
1番目と2番目の暗号文を接合し、HS256暗号化を再度実行し、暗号化された暗号文をbase64urlによって復号化された3番目の暗号文と比較します。両者が等しい場合、トークンは変更されていません（認証は成功）

JWTの利点は？

JWTはクロスランゲージ、JAVA、JS、NodeJS、PHPをサポートでき、他の多くの言語を使用できます
ペイロード部分があるため、JWTは他のビジネスロジック自体に必要な機密ではない情報を保存できます。
JWTは送信に便利で、構造が単純でバイト占有が小さいため、送信に非常に便利です。
サーバー側でセッション情報を保存する必要がないため、拡張が簡単