Session/Token(JWT)(2)

📙トークンとJWT

マーク

コインは多くの場所で使われている用語です.だから定義するのは難しいし、使う場所によって意味が違うので、データトークン(文字列)の説明を読んでみると役に立つはずです.5、リンクの画像は、トークンベースの認証システムを示す.

上の図に、ログイン時にサーバとクライアントの間でトークンを使用する認証プロセスを示します.トークンベースの認証の利点は、Session / Token(JWT)(1)においてセッションと比較される.これらのトークン認証システムで主に使用されるJWTについて正式に説明します.

JWT(Json Web Token)

jwt.ioに記載されたJWTは、各当事者間でJSONオブジェクトに安全に情報を送信するための簡潔で自己包含的な方法を定義するオープンスタンダード(RFC 7519)である.簡単に言えば、クライアントとサーバ、サービス、サービスとの間で通信する際に認証に使用されるトークンです.HTTPの任意の場所(URL、Header、...)に使用される安全な文字列で構成されています.を選択します.JWTはClaimベースのWeb Tokenです.Claimベースの詳細については、1を参照してください.リンクを読むと役に立ちます

構造と作成

こうぞう

Header.Payload.Signature

ヘッダー、ペイロード、署名ポイント(.)で区切られた構造です.

Header

JWTの検証に必要な情報を持つJSONオブジェクトは、Base 64 URL-Safeとして符号化された文字列である.見出しには、JWTの検証方法が含まれています.

{
	"alg": "HS256",
 	"kid": "key ID"
}

ここで、algは署名のためのアルゴリズムであり、kidは署名鍵(Public,Private Key)を識別するための値である.上記JSONオブジェクトを文字列化してUTF-8とBase 64 URL-Safeとして符号化することで、以下のタイトルを生成することができる.
HS256 :
HS 256はHMAC SHA 256の略であり、HAMCはハッシュベースのメッセージ認証コードである.
ハッシュの場合、入力値が同じであれば、ハッシュのハッシュ値は常に同じであるため、変更を検出することができるが、虚偽の行為を検出することは難しい.
メッセージ検証コード(private key<-推測)は、虚偽の行径を検出および阻止するためのSHA 256ハッシュメッセージである.暗号化(署名)送信を使用して、受信者は同じ秘密鍵を使用して復号と署名の方法を検証します.同様に、HMAC SHA 256アルゴリズムは対称鍵方式である.

Base64URLSafe(UTF-8('{"alg": "HS256","kid": "Key ID"}')) -> eyJhbGciOiJIUzI1NiIsImtpZCI6ImtleSBJRCJ9

Payload

PayloadまたはBodyはJWTのコンテンツです.ペイロード(Payload)のプロパティを「クレームセット」(Claim Set)と呼びます.クライアントセットは、JWTのコンテンツ(トークン作成者(クライアント)の情報、作成時間など)またはクライアントとサーバの間で交換される値で構成されます.

{
	"name": "seokjin.hong",
	"iat": "1516239022"
}

上記JSONオブジェクトを文字列化し、Base 64 URL-Safeとして符号化し、以下のペイロードを生成することができる.

Base64URLSafe('{"name": "seokjin.hong","iat": "1516239022"}') -> eyJuYW1lIjoic2Vva2ppbi5ob25nIiwiaWF0IjoxNTE2MjM5MDIyfQ

Signature

点(.)区切り記号として、署名ヘッダーとペイロードの文字列の値.「署名」(Signature)は、ヘッダalgで定義されたアルゴリズムおよび鍵を使用して生成され、Base 64 URL−Safeとして符号化される.
JWTデバッガの写真を使用します.

Encode部分にエンコードされたHeader.Payload.「シグナル」(JWT)が完了しました.
暗号化の詳細はJWTサブJWS(JSON Web署名)とJWE(JSON Web Encryption)にあります.私も6と書きました.リンクでは、JWTを生成および検証するための多くのAPIを含むJWTの実装について議論した.JWT認証の生成に関するコードgistを参照してください.アルゴリズムに関する知識は非常に豊富で、セキュリティと暗号化に関する知識も豊富です.JWTはAPIとWebサーバの両方で役に立つようです.これは古いセッション方式で、JWTの方が良いと思うかもしれませんが、信頼性の高いWeb上では、セッションがより安全で効率的になる可能性があります.具体的な状況に応じて適切な有用な技術を使うことは努力に値する開発方法だと思います.不便に耐えられないのは開発者の品格だと思います.私は多くの方法とアルゴリズムを学び、状況に応じて考える範囲を広げます.
コメントリンク
1. Claimベースは
2. データトークンの説明
3. JWTはいったい何なのか、なぜ使うのか。
4. JWTについて
5. トークンベースの認証VSサーバベースの認証
6. JWTの紹介
7. RS 256とHS 256の違い