1
1
import { MdxAnchorComponent } from " @/features/common/components/markdown/mdx-anchor.component" ;
2
2
import { MarkdownImage } from " @/features/common/components/markdown/markdown-image" ;
3
3
4
- ## JSON Web Tokenとは?
4
+ < h2 id = { props . headings [ 0 ]. id } > { props . headings [ 0 ]. title } </ h2 >
5
5
6
6
JSON Web Token (JWT) は標準規格(<MdxAnchorComponent type = " external" href = " https://tools.ietf.org/html/rfc7519" >RFC 7519</MdxAnchorComponent >)で定義されています。この仕様は認証、認可の情報をJSON形式でシステム間で安全にやりとりする際に使用できる、コンパクトで自己完結型のフォーマットを定義しています。デジタル署名を付与することもできるため、検証可能で信頼がおけます。JWTへの署名には共通鍵を使用するHMACアルゴリズムあるいは、公開鍵/秘密鍵ペアを使用するRSAまたはECDSAアルゴリズムを使用できます。
7
7
8
8
JWTは機密性を保つために暗号化することもできますが、ここでは 署名されたJWT に焦点を当てます。署名されたJWTは完全性を検証でき、暗号化されたトークンは内容を他者から隠すことができます。JWTが秘密鍵を用いて署名された場合、その署名は公開鍵を使うことで、秘密鍵を持つ当事者だけがそのJWTに署名した者であることが確認できます。
9
9
10
- ## JSON Web Tokenはいつ使用すべきか?
10
+ < h2 id = { props . headings [ 1 ]. id } > { props . headings [ 1 ]. title } </ h2 >
11
11
JSON Web Tokenが役立つシナリオをいくつかご紹介します。
12
12
13
13
- ** 認証および認可** : JWTを使用する最も一般的な利用用途です。ユーザーがログインすると、その後の各リクエストにはJWTが含まれ、ユーザーはそのJWTで許可されたエンドポイント、リソースにアクセスできます。オーバーヘッドが小さく、異なるドメインのシステム間で簡単に使用できるため、シングルサインオンやSPAやモバイルアプリケーション、APIの呼び出しなどでJWTが使用されています。
14
14
- ** 情報交換** : JSON Web Tokenは、システム間で認証や認可の情報を安全にやりとりする際に優れた形式です。JWTには署名できるため、例えば公開鍵/秘密鍵のペアを使用して、送信者が本人であることを確認できます。さらに、署名はヘッダーとペイロードを使って計算して作成されるため、コンテンツが改ざんされていないことも確認できます。
15
15
16
- ## JSON Web Tokenの構成は?
16
+ < h2 id = { props . headings [ 2 ]. id } > { props . headings [ 2 ]. title } </ h2 >
17
17
JSON Web Tokenはコンパクトな形態で、ドット(.)で区切られた以下の3つの部分で構成されます。
18
18
19
19
- ヘッダー
@@ -93,7 +93,7 @@ JWTを操作してこれらの概念を実際に試したい場合は、<MdxAnch
93
93
94
94
<MarkdownImage src = " https://cdn.auth0.com/website/jwt/introduction/debugger.png" alt = " jwt.ioデバッガー" />
95
95
96
- ## JSON Web Tokenの仕組みとは?
96
+ < h2 id = { props . headings [ 3 ]. id } > { props . headings [ 3 ]. title } </ h2 >
97
97
認証では、ユーザーが資格情報を使用して正常にログインすると、JSON Web Token (JWT)が返されます。トークンは資格情報であるため、セキュリティの問題が起きないように細心の注意を払う必要があります。一般的に、トークンは必要以上に長く保持するべきではありません。
98
98
99
99
保護されたエンドポイントにユーザーがアクセスしたい場合、ブラウザなどのクライアントはJWTを送信する必要があります。通常は、Bearerスキーマを使用してAuthorizationヘッダーで送信します。したがって、ヘッダーの内容は次のようになります。
@@ -116,7 +116,7 @@ JWTトークンをHTTPヘッダーで送信する場合は、トークンのサ
116
116
117
117
署名付きトークンの場合、トークンに含まれるすべての情報は、ユーザーやアクセスを許可をしているサードパーティーに公開されます。その情報が変更されることはありませんが、トークンの中にユーザやサードパーティに知られたくないような機密情報を入れないようにご注意して下さい。
118
118
119
- ## JSON Web Tokenを使用すべき理由とは?
119
+ < h2 id = { props . headings [ 4 ]. id } > { props . headings [ 4 ]. title } </ h2 >
120
120
121
121
** JSON Web Token (JWT)** の利点について、** Simple Web Token (SWT)** および XML を使用する ** Security Assertion Markup Language Token (SAML)** と比較してみましょう。
122
122
@@ -134,7 +134,7 @@ _エンコードされたJWTとエンコードされたSAMLの長さの比較_
134
134
135
135
JSON Web Tokenの詳細や、JSON Web Tokenを使用したアプリケーションの認証については、Auth0の<MdxAnchorComponent type = " external" href = " http://auth0.com/learn/json-web-tokens" >JSON Web Tokenランディングページ</MdxAnchorComponent >をご覧ください。
136
136
137
- ## JWTのバリデーション(妥当性確認)とベリフィケーション(検証)の違い
137
+ < h2 id = { props . headings [ 5 ]. id } > { props . headings [ 5 ]. title } </ h2 >
138
138
139
139
JSON Web Token(JWT)のバリデーション(妥当性確認)とベリフィケーション(検証)はセキュリティ上非常に重要ですが、JWTセキュリティの異なる側面に対応しています。バリデーションはトークンが適切に構成され、強制可能なクレームを含んでいることを確認します。ベリフィケーションはトークンが真正で、変更されていないことを確認します。
140
140
@@ -161,7 +161,7 @@ JSON Web Token(JWT)のバリデーション(妥当性確認)とベリフ
161
161
多くのシステムでは、これらの手順は、包括的なセキュリティチェックにおける妥当性の確認と検証の両方を包含する「JWT検証」と呼ばれるものにまとめられることが多々ありますが、両者の区別は存在します。
162
162
163
163
164
- ## JWTのデコーディングとエンコーディングの違い
164
+ < h2 id = { props . headings [ 6 ]. id } > { props . headings [ 6 ]. title } </ h2 >
165
165
166
166
JWTのエンコーディングでは、ヘッダーとペイロードをコンパクトでURLに適した形式に変換します。署名アルゴリズムとトークンタイプを記載するヘッダーと、サブジェクト、有効期限、発行時間などのクレームを含むペイロードの両方をJSONに変換しBase64URLエンコードします。これらのエンコードされた部分は、ドット(.)で連結され、その後、ヘッダーで指定されたアルゴリズムを使用して、シークレットキーまたはプライベートキーで署名が生成されます。この署名もBase64URLエンコードされ、送信や保存に適した形式でトークンを表す最終的なJWT文字列が生成されます。
167
167
0 commit comments