JSON Web Token概要

概要

認証は、ほとんどのアプリケーション(Web、モバイルなど)の中で最も重要な部分の一つです.認証には、周知のCookie、セッション、およびトークンベースの認証があるべきである.
コインを重点的に紹介したいです.脇役としても会話が出てくる.😀

今回のキャンペーン中です。

セッションベースの認証とトークンベースの認証(なぜJWTが現れるのか)

JWTの動作原理

JWTのコンポーネントおよび作成プロセス

アプリケーションを保護する方法、JWTの有効性認証

理解してみましょう.
Web、モバイルなどのアプリケーションを使用している場合は、アプリケーションの機能にアクセスするアカウントが必要です.この一連のプロセスを認証(Authentication)と呼ぶ.
では、どのようにして自分の口座を認証しますか?
まず、過去にウェブサイトでよく使われていた簡単な方法をご紹介します.
セッションベースの認証と名前を付けます.

上記の図に示すように、ユーザーがWebサイトにログインすると、サーバはメモリ/データベースにユーザーとのセッションを作成して保存します.また、サーバはクライアントからブラウザCookieを提供する🍪セッションIDを返して保存します.
サーバ上のセッションに有効期間があります.しばらくすると、セッションが期限切れになり、ユーザーは別のセッションを作成するために再ログインする必要があります.
ユーザーがログインし、セッションが期限切れになっていない場合、セッションIDを含むCookieは、サーバ上のすべてのHTTPリクエストとともに移動します.これは、すべてのHTTPリクエストにCookieがあることを意味します.
サーバは、このセッションIDを保存したセッションと比較して、対応する応答を検証して返します.
では、なぜセッション認証ではなくトークン認証が要求されるのでしょうか.
この質問には、Webサイトだけでなく、他のプラットフォームも必要です.
会話とともに.🍜 うまく動いているサイトがあると仮定します.
ある日、現在のWebアプリケーションと同じデータベースを使用して、モバイル(ネイティブアプリケーション)用のシステムを実現したいと考えています.何をしますか?
セッションベースの認証を使用するネイティブアプリケーションにはCookieがないため、ユーザーの認証はできません.
ネイティブ・アプリケーションをサポートする別のプロジェクトを作成する必要はありません.また、ネイティブ・アプリケーション・ユーザーの認証モジュールを有効にする必要はありません.
トークンベースの認証が発生した理由です.
この方法により、符号化されたユーザ情報は、サーバによってJSON Web Token(JWT)の一部としてクライアントに送信される.現在、多くのRESTful APIでは、この方法が使用されています.

JWTがどのように動作するか

上の図に示すように、サーバはセッションを作成するのではなく、ユーザがログインしたデータからJWTを作成し、JWTをクライアントに送信します.クライアントは受信時からJWTの保存を開始し、各クライアントの要求にはヘッダー(通常はヘッダー)が必要です.
サーバはJWTを検証し、チェック結果に基づいて応答を返します.
クライアント側のストレージの場所は、使用するプラットフォームによって異なります.

ブラウザには、Local Storage2

が含まれています.

iOSはKeychain2

をサポート

Android提供SharedPreferences2

に格納されます.

JWTのコンポーネント

まず、JWT

Header

Payload

Signature

この3つからなる

Header(ブラウザのタイトルとは異なるタイトル)

ヘッダーは、どのアルゴリズムを使用して署名を生成するかを決定します.
JWTはどう計算しますか?この問題の答えは

{
  "alg" : "HS256",
  "typ" : "JWT"
}

上記のコードでは、algは「アルゴリズム」を表し、トークン署名を生成するためのハッシュアルゴリズムを表す.
HS 256は、このトークンが、Secret鍵を用いたHMAC−SHA 256という暗号化アルゴリズムを用いて署名されたことを示す.

Payload

ペイロードには、一連のクレーム(要件)が含まれます.JWT仕様は、7つの登録クレーム名を定義し、通常、タグに含まれる標準フィールドを定義します.

{
  "userId" : "bruce han",
  "username" : "Bruce Han",
  "email" : "[email protected]",
  // standard fields
  "iss" : "Bruce Han",
  "iat" : 1570238918,
  "exp" : 1570238992
}

デフォルトではJSONはコメント処理ができません.
このように、上記の3つのフィールドは自分で指定したフィールドで、次の3つは標準フィールドです.必ずいくつかの基準を用いなければならない問題はなく、自分が解決しなければならない問題だけを選べばいい.(たとえば、ログイン時にユーザー名は保持されますが、パスワードは計算されませんなど)
次の3つの基準は、

iss(発行者):JWTの発行者

iat(発行時間):JWT発行時間

exp(展開時間):JWT有効期限

標準フィールドの詳細については、ここです。を参照してください.

Signature

これはハッシュアルゴリズムを用いた部分です.この署名セクションでは、タグのセキュリティを確保します.署名はBase 64 url符号化を用いてヘッダとペイロードを符号化し、その点(.)区切り記号を使用して接続することで計算されます.
次のコードは、次の信号を入力します.

const data = Base64UrlEncode(header) + '.' + Base64UrlEncode(payload);
const hashedData = Hash(data, secret);
const signature = Base64UrlEncode(hashedData);

このようにして署名をインポートします.
上記で説明しましたが、まずヘッドとPayloadをポイントに接続します.

data = '[encodedHeader].[encodedPayload]'

次に、ハッシュは、タイトルに秘密鍵で定義されたハッシュアルゴリズムを使用して作成される.
最後に、ハッシュ結果を符号化して署名を取得する.

結合

Header、Payload、Signatureを取得し、JWTの標準構造であるHeaderにマージします.payload.サインはこうです
コードにマージする方法を説明します.

const encodedHeader = base64urlEncode(header);
/* Result */ 
"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9"

const encodedPayload = base64urlEncode(payload);
/* Result */
"eyJzdWIiOiIwOTg3NjU0MzIxIiwibmFtZSI6IkJydWNlIEhhbiIsImlhdCI6MTUxNjIzOTAyMn0"

const data = encodedHeader + "." + encodedPayload;
const hashedData = Hash(data, secret);
const signature = base64urlEncode(hashedData);
/* Result */
"ID18A39H8vUWb8sBYC2LyvbuKfshSwPQaMAbwJvr1Ac"

// header.payload.signature
const JWT = encodedHeader + "." + encodedPayload + "." + signature;
/* Result */
"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIwOTg3NjU0MzIxIiwibmFtZSI6IkJydWNlIEhhbiIsImlhdCI6MTUxNjIzOTAyMn0.ID18A39H8vUWb8sBYC2LyvbuKfshSwPQaMAbwJvr1Ac"

JWTを使用してデータを保護する方法

ソース:https://namu.wiki/w/%EA%B7%B8%EB%9F%B0%20%EA%B1%B0%20%EC%97%86%EB%8B%A4
JWTはデータを非表示、ぼかし、保護しません.全然ありません.
ヘッダー、Payload、署名(JWT)を作成するプロセスは、データを暗号化せず、暗号化およびハッシュデータのみを生成します.
JWTの目的は、データが信頼できるソースによって作成されたことを証明することだけです.
だから、
もしあなたが仲介者攻撃でJWTを得ることができたら、ユーザー情報を復号する必要がありますか?
はい.
したがって、アプリケーションにHTTPS暗号化が常に存在することを確認する必要があります.

サーバはクライアントからのJWTの有効性をどのように決定しますか?

サインを作るために秘密の鍵を使ったと書いてありますこの鍵は、すべてのアプリケーションで一意であり、サーバ側に安全に格納されている必要があります.
クライアントからJWTを受信すると、サーバは署名を取得し、署名がハッシュアルゴリズムおよび鍵によって正常に復号されるかどうかを決定する.サーバ上の署名と一致する場合、JWTは有効とみなされます.

では。

サーバにJWTを送信する場合、ペイロード情報を追加または編集したい場合はどうすればいいですか?
また、クライアントに送信する前にタグを保存することもできます.これにより、クライアントによって送信されたJWTが有効であるかどうかを判断することができる.
また、トークンをサーバに保存すると、強制的にログアウトすることもできます.

の最後の部分

実際には最高の認証方法はありません.本人が直面している問題に対して、使う時適当な(a.k.a.携帯ケース)が無敵拳を使うことがあります!この方法はないと思います.
しかし、多くのユーザが使用する大規模なアプリケーションにとって、JWT認証はクライアントストレージトークンに非常に適している可能性があります.

글을 봐주신 분들께 압도적 감사.
지적을 해주시는 분들께 압도적 감사.
하트 눌러주시면 압도적 감사.

リファレンス

Bezkoder(この記事は実際には本稿で説明しています.情報ありがとうございます)
https://www.bezkoder.com/jwt-json-web-token/?unapproved=18843&moderation-hash=275e5d7e324cf71c37350497008ef1c1#comment-18843

ウィキペディア
https://ko.wikipedia.org/wiki/JSON_%EC%9B%B9_%ED%86%A0%ED%81%B0

https://datatracker.ietf.org/doc/html/rfc7519