JSON Web Tokenは、アプリケーションのアクセストークンを作成するために使用される標準です。サーバーはユーザー idを証明するトークンを生成し、それをクライアントに送信します。
クライアントは後続の要求ごとにトークンをサーバーに送り返すので、サーバーは要求が特定のidから来ていることを知っています。
このアーキテクチャは、ユーザーが認証された後、RESTまたはGraphQL APIへのAPI要求を実行する最新のWebアプリで非常に効果的であることが証明されています。JWTを使用するユーザーは誰ですか？, たとえば、Googleです。 Google Apiを使用する場合は、JWTを使用します。JWTは暗号的に署名されています（ただし、暗号化されていないため、JWTにユーザーデータを格納するときにHTTPSを使用することは必須です）ので、仲介者は無効に
とはいえ、Jwtは過度の使用、特に問題の少ない解決策を使用できる場合に使用されることで批判されることがよくあります。
あなたは主題の周りにあなたの意見を形成する必要があります。, 私はあなたがあなたの処分で持っているすべての機会とツールを提示するだけで、別のものよりも技術を提唱していません。
彼らは何のために良いのですか？ 主にAPI認証、およびサーバー間承認。
JWTトークンはどのように生成されますか?
ノードを使用します。,jsトークンの最初の部分を生成するには、次のコードを使用します。
const header = { "alg": "HS256", "typ": "JWT" }const encodedHeader = Buffer.from(JSON.stringify(header)).toString('base64')署名アルゴリズムをHMAC SHA256（JWTは複数のアルゴリズムをサポートしています）に設定し、このJSONエンコードされたオブジェクトからバッファを作成し、base64を使用してエンコードします。
部分的な結果はeyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9です。
次に、あらゆる種類のデータでカスタマイズできるペイロードを追加します。, トークンの発行者と有効期限を識別するissおよびexpを含む予約キーがあります。
オブジェクトを使用することで、独自のデータをトークンに追加できます。
const payload = { username: 'Flavio' }JSONエンコードされたこのオブジェクトをバッファに変換し、base64を使用して結果をエンコードします。
const encodedPayload = Buffer.from(JSON.stringify(payload)).toString('base64')この場合、部分的な結果はeyJ1c2VybmFtZSI6IkZsYXZpbyJ9です。,
次に、ヘッダーとペイロードコンテンツから署名を取得し、署名が無効になるため傍受されてもコンテンツを変更できないようにします。 これを行うには、cryptoノードモジュールを使用します。
secretKey秘密鍵を使用し、暗号化された署名のbase64エンコードされた表現,
この場合の署名の値は
MQWECYWUT7bayj8miVgsj8KdYI3ZRVS+WRRZjfZrGrw=
ほぼ完了しました、ヘッダー、ペイロード、署名の3つの部分をドットで区切って連結するだけです。
const jwt = `${encodedHeader}.${encodedPayload}.${signature}`2api認証
これはおそらくjwtを使用する唯一の賢明な方法です。
一般的なシナリオは、サービスにサインアップし、サービスダッシュボードからJWTをダウンロードすることです。 これは、サーバーへのすべての要求を認証するために今から使用するものです。,
逆の別のユースケースは、APIを管理し、クライアントが接続するときにJWTを送信し、ユーザーがトークンを渡すだけで後続の要求を送信することです。
この場合、クライアントはトークンをどこかに格納する必要があります。 最高の場所はどこですか？ HttpOnlyクッキーで。 他の方法はすべてXSS攻撃を受けやすいため、回避する必要があります。 HttpOnly cookieはJavaScriptからアクセスできず、リクエストごとに元のサーバーに自動的に送信されるため、ユースケースに完全に合っています。,
最適なJWTライブラリを選択します
使用する言語と環境に応じて、いくつかのライブラリから選択できます。 最も人気のあるものは次のとおりです。jwt.io ウェブサイト。
Jwtをセッショントークンとして使用しないでください
セッションにJwtを使用しないでください。 通常のサーバー側セッションメカニズムを使用すると、はるかに効率的で、データにさらされにくいためです。
