JWT の概要
JWT を導入する前に、次の図に示すように、トークンを検証する従来の方法を見てみましょう。
問題:
従来の認可方法の問題は、ユーザーがリソース サービスを要求するたびに、リソース サービスがトークンを保持して認証サービスにアクセスし、トークンの正当性を検証し、トークンに基づいてユーザー関連情報を取得する必要があることです
。トークンが生成され、パフォーマンスが低下します。
解決策:
JWT を使用する考え方は、ユーザーが認証に合格した後に JWT トークンを取得するというものです。JWT トークンにはユーザー関連の情報が既に含まれています。クライアントはリソース サービスにアクセスするために JWT を運ぶだけでよく、
リソースカード認証サービスは、事前に合意されたアルゴリズムに従って自動的に注文を完了するため、毎回認証サービスにオーソリ処理を依頼する必要はありません。
JWT トークンの認証プロセスは次のとおりです。
JWT とは何ですか?
JSON Web Token（JWT）これはオープン業界標準 (RFC 7519) であり、通信中の 2 者間で JSON オブジェクトを送信するための簡潔な自己完結型プロトコル形式を定義しており
、送信された情報はデジタル署名後に検証および信頼できます。
JWT は、改ざんを防ぐために、HMAC アルゴリズムまたは RSA 公開キー/秘密キーのペアを使用して署名できます。
公式ウェブサイト:標準: https://tools.ietf.org/html/rfc7519
JWT トークンの利点:
1. JWT は json に基づいており、解析に非常に便利です。
2. トークン内で豊富なコンテンツをカスタマイズでき、拡張が容易です。
3. JWTは非対称暗号アルゴリズムと電子署名技術により改ざんを防止し、高いセキュリティを実現します。
4. リソース サービスは、JWT を使用して、認証サービスに依存せずに承認を完了できます。
欠点:
1. JWT トークンは長く、多くのストレージ スペースを占有します。
JWT トークンの構造
JWT トークンの構造を学習して、カスタム jwt トークンの基盤を構築します。
JWT トークンは 3 つの部分で構成され、各部分はドット (.) で区切られます。例: xxxxx.yyyyy.zzzzz
ヘッダ
ヘッダーには、トークンのタイプ (つまり、JWT) と使用されるハッシュ アルゴリズム (HMAC SHA256 または RSA など) が含まれます。
例は次のとおりです。
以下はヘッダーセクションの内容です
{
"alg": "HS256",
"typ": "JWT"
}
Base64Url を使用して上記のコンテンツをエンコードし、JWT トークンの最初の部分である文字列を取得します。
ペイロード
2 番目の部分はロードであり、コンテンツも json オブジェクトです。有効な情報を保存する場所です。iss (発行者)、exp (有効期限タイムスタンプ) など、jwt によって提供される既製のフィールドを保存できます。 、サブ（ユーザー指向）など。フィールドをカスタマイズすることもできます。
このセクションは元のコンテンツをデコードして復元する可能性があるため、このセクションに機密情報を保存することはお勧めできません。
最後に、ペイロードの 2 番目の部分を Base64Url でエンコードして、JWT トークンの 2 番目の部分である文字列を取得します。
一例:
{
"sub": "1234567890",
"name": "456",
"admin": true
}
サイン
3 番目の部分は署名で、jwt コンテンツの改ざんを防ぐために使用されます。
この部分は、base64url を使用して最初の 2 つの部分をエンコードし、エンコード後、ドット (.) を使用して接続して文字列を形成し、最後に
ヘッダーで宣言された署名アルゴリズムを使用して署名します。
一例:
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
base64UrlEncode(header): jwt トークンの最初の部分。
base64UrlEncode(payload): jwt トークンの 2 番目の部分。
Secret: 署名に使用される秘密鍵。