jwtを使用してノードによって生成されたトークンをどこに保存するかについての簡単な説明

A: 通常はクライアントに保存されます。

jwt または JSON Web Token は、リクエストの ID 情報と ID 権限を確認するために一般的に使用される認証プロトコルです。

今朝、あるウェブサイトを閲覧していたとき、この質問をしているクラスメイトに会いました。彼は、jwt の保存場所について非常に興味を持っていました。私はたまたま少し前にこのテーマを勉強していたので、招待されなくてもこの質問に答えることに躊躇しません。
最初は、このトークンをどのように保存するかについても興味があり、このトークンを保存するために redis を使用することを考えていました。

その後、調査の結果、サーバーはこのトークンを保存する必要がないことがわかりました。クライアントは保存するだけでよく、どのような方法を使用するかは関係ありません。ユーザーにメモを書いてポケットに入れるように依頼することもできます。

それで、このトークンはどのように機能するのでしょうか?

まず、従来のセッション アプローチである、サーバー側のストレージを必要とする操作について説明します。

まず、ユーザーをログインさせるには、サーバー上でログイン テーブルを維持する必要があります。このログイン テーブルは、キャッシュまたはデータベースに配置できます。
ユーザーがログインすると、ユーザー情報がログイン テーブルに書き込まれ、ログイン ID (セッションとも呼ばれる) が生成されます。このセッションはクライアントに返され、クライアントは次回の要求時にこの情報を表示できます。

フロントエンドの担当者にとって、このプロセスは通常は気付かれません。バックエンドの担当者は、set-cookie と呼ばれる HTTP ヘッダー フィールドを使用して、データをブラウザの Cookie に書き込みます。その後、リクエストを行う際に、ブラウザはリクエスト ヘッダー自体に Cookie を書き込みます。

クライアントがサーバーへのログインを要求すると、サーバーは Cookie 内のセッションを取得し、ログイン テーブルでユーザー情報を検索し、ユーザーの権限を確認して、通常のビジネス インタラクションを完了します。

さて、さまざまな理由から、ログイン テーブルを維持したくありません。どうすればよいでしょうか?
簡単です。ユーザー情報をクライアントに送信し、クライアントが毎回ユーザー情報を取得できるようにします。このようにすると、リクエストが来たときにテーブルを確認する必要すらなく、どのユーザーがリクエストを行っているかを直接知ることができます。

しかし、この方法では、ユーザーの情報が露出してしまいます。仲介業者は、このような直接的な要求を最も好みます。仲介業者は、数日間、あなたのサーバー ポートに腰掛けて座り、データベース内のすべての関連情報が他の人に明らかに露出することになります。

これは絶対にうまくいかないので、どうすればいいでしょうか?

パスワードを追加して混乱させるだけです。こうすることで、あなたのトークンを入手した人たちはしばらく混乱し、おそらく不注意に立ち去るでしょう。そして、十分に準備された少数の人たち (KPI) だけが、それを解読するのに苦労することになります。

サーバーで復号すると、ユーザー情報が取得されます。同様に、暗号文に有効期限も書き込みます。有効期限が切れると、401 エラーでログイン ページにジャンプします。このようにして、ログイン資格情報のバックエンドストレージを必要としないソリューションが開発されます。

これは、jwt の最も基本的な動作原理です。つまり、ID 情報は安全に保管するためにクライアントに引き渡されます。

jwt によって生成されるトークンは、ヘッダー、ペイロード、署名の 3 つの部分で構成され、小数点「.」で区切られます。

ヘッダー、つまりヘッダー情報はトークンの基本情報を記述し、JSON 形式です。

{
    "アルゴリズム":"HS256",
    "タイプ":"JWT"
}

alg は署名部分を生成するために使用される暗号化アルゴリズムを表し、typ はトークンが jwt タイプであることを示します。

ペイロードはユーザーデータであり、これも json 形式です。ただし、JWT では、仕様上、ペイロードはヘッダーと同じであり、base64 で一度だけエンコードされてトークンに表示されるため、機密データを入れることは推奨されていません。

署名は、このトークンの署名です。通常は、前のヘッダーとペイロードを、自分で定義した秘密鍵文字列とともに暗号化して生成される文字列です。

前述のように、jwt はペイロードの内容を base64 でエンコードするだけなので、攻撃者がコンテンツを変更するのは非常に簡単です。ただし、攻撃者は秘密鍵を知らないため、変更後に正しい署名を生成することはできません。暗号化を使用してリクエストの header.payload を再度検証し、署名と一致しないことを発見します。この時点で、誰かが問題を引き起こしていることを明確に知ることができ、サーバーがダウンしているふりをするために直接 500 を返すことができます。
より安全にしたい場合は、プロセス全体を通じてリクエスト通信に https プロトコルを使用することをお勧めします。

もちろん、これがどのように機能するかを理解した今、ペイロードを再度暗号化してから gzip 圧縮するなど、独自の不快な仕様を思いつくことは不可能ではありません。

では、jwt を使用する利点は何でしょうか?

最初のポイントは、サーバーがログイン テーブルを維持する必要がないため、特にユーザー数が多い場合にスペースを節約できることです。
2 つ目のポイントは、トラブルを起こさず、コンテンツを表現するために JSON 形式を忠実に守れば、拡張は簡単だということです。
3 つ目のポイントは、ステートレスであることです。サーバーがパースをサポートしていれば、業務を遂行できます。セッションを共有したりマシンを追加したりするために特別な仕組みを設ける必要はありません。
4つ目に、さまざまなクライアントをサポートしており、Cookieをサポートしていなくてもプレイできます。
欠点は、リクエストが行われるたびにこれらのデータをやり取りする必要があり、リクエストの内容が確実に増加することです。さらに、リクエストが届くたびに、それを検証し、ヘッダーとペイロードを暗号化し、署名を検証する必要があり、これによってもリクエストの処理時間が長くなります。従来の操作と比較すると、これは実際には時間とスペースのトレードオフです。最終的には、選択次第です。

jwt を使ってノードが生成したトークンをどこに保存するかについてはこれで終わりです。jwt で生成したトークンをどこに保存するかについての詳細は、123WORDPRESS.COM の過去の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。