JSON Webトークン – ウィキペディア

before-content-x4

a JSON Webトークン jwt 、提案された発音:[ dʒɒt ])はJSONベースと後です RFC 7519 標準化されたアクセストークン。 JWTは、検証可能な請求の交換を可能にします。通常、サードパーティプロバイダーを持つシステム内のIDプロバイダーとサービスプロバイダーの間でユーザーの身元を交換するために使用されます。 JWTは、「ステートレスセッション」の実装に特に適しています。これは、すべての認証関連情報をトークンに送信できるため、セッションをサーバーに保存する必要がないためです。

after-content-x4

JWTは、ヘッダー、PayOad、署名の3つの部分で構成されています。

[ 編集 | ソーステキストを編集します ]

ヘッダ 記述するJSON要素であり、どのトークンタイプであり、どの署名メソッドが使用されていますか。

分野 名前 意味
タイプ タイプ トークンのIANAメディアタイプについて説明します。この値は常にです jwt、 メディアタイプに アプリケーション/JWT 記述するために。
会社 コンテンツタイプ JWTにPAYOADよりも別のJWTが含まれている場合、このフィールドが必要です。この場合、起きます jwt 設定。それ以外の場合、このフィールドは除外する必要があります。
アルグ アルゴリズム どの署名メソッドが使用されるかについて説明します。署名方法として、HMACには通常SHA-256が付属しています( HS256 )またはsha-256のRSA( RS256 )使用する。署名を使用しない可能性があります( なし )、これは推奨されません。考えられる値は、JSON Web暗号化(JWE)の後です RFC 7516 標準化。

たとえば、ヘッダーは次のようになります。

{   「アルグ」  「HS256」   "タイプ"  「JWT」  }  

ペイロード [ 編集 | ソーステキストを編集します ]

ペイロード 主張を説明するのはJSON要素です。

{   "サブ"  「1234567890」   "名前"  "ジョン・ドウ"   「管理者」  真実  }  

いくつかの主張は予約されています:

分野 名前 意味
ISS 発行者 トークンの出展者
サブ 主題 請求が適用される対象について定義されています。 サブ したがって、フィールドは、誰またはどのようなクレームがなされているかを定義します。
aud 観客 トークンが展示されたターゲットドメイン。
exp 有効期限 UNIX期間のトークンの有効期限、つまり秒数以降 1970-01-01T00:00:00Z
NBF 前ではありません トークンが有効なUNIX時間。
IAT で発行された トークンが展示されたUNIX時間。
jti jwt id トークンを明確に識別する明確なケースに敏感な文字列。これは、複製されるのを防ぐことができます。これは、カウントされた数、GUID、またはハッシュ値です。トークンレシーバーがいくつかの出展者からトークンを受け取った場合、JWT IDが明確でない可能性があります。出展者(ISS)とJWT ID(JTI)の組み合わせが再び明らかになる可能性があります。 [初め]

さらに、まだです 公的請求 IANAによって定義されています。 [2] さらに、JWTの出展者も1つできます 民間の主張 標準化されていない定義されたURIを使用します。たとえば、ここでは、ダブリンコアやFOAFなどのオントロジーを使用できます。

after-content-x4

サイン [ 編集 | ソーステキストを編集します ]

署名の構造は次のとおりです JSON Web署名 JWS )、その後 RFC 7515 標準化された標準、定義されています。

署名は、Base64のヘッダーとPAYOADがコード化されており、指定されたHashMethodを使用してポイント別々の形式で切断されるという事実によって生成されます。

だった  エンコードストリング  =  base64urlencode ヘッダ ))  +  「。」  +  base64urlencode ペイロード );  だった  ハッシュ  =  HMACSHA256 エンコードストリング  ひみつ );  

コーディング [ 編集 | ソーステキストを編集します ]

ヘッダー、PAYOAD、および署名はそれぞれBase64-URLでエンコードされ、1ポイントで互いに分離されます。 JWTトークンは次のように見えます:

だった  jwt  =  base64urlencode ヘッダ ))  +  「。」  +  base64urlencode ペイロード ))  +  「。」  +  base64urlencode ハッシュ ))  
Eyjhbgcioijiuzi1niisinr5cCi6ikpxvcj9​​.eyjpc3mioijzy290yy2Guaaw8ilcjlehaiiojezmda4mtkzodasim5hbwuyjdahjpcybtzxzpbgxlamelcjgggg1pbii6dhj 1Zx0.03f329983B86f7f9a9f5fef8530580101D502AFAFA W20154D094B229F75773

JWTは、URLまたはHTTPヘッダーで送信できます。

http://example.com/path?jwt_token=eyjhbgciiziziziziziisinr5cci6ikpxvcj9 ...

HTTPヘッダーには、承認フィールドまたはCookieフィールドの送信には2つのオプションがあります。

  • ベアラートークンとしての承認分野で: 承認:BEARER EYJHBGCIOIJIUZI1NIISINR5CCI6IKPXVCJ9 ...
  • クッキーフィールドで: Cookie:token = eyjhbgcioijiuzi1niisinr5cci6ikpxvcj9​​ ...

2つの方法には、異なる利点と短所があります。

ベアラートークン クッキー
ヘッダ

承認:ベアラー

Cookie:token =

cors CORSで動作しますが、JavaScriptの実装が必要です。 Cookieは、現在のドメインのブラウザによってのみ送信されます。 CORSは不可能です。
保管所 JavaScriptによって応答できるWebストレージやCookieストアなどのすべてのストレージ方法が可能です。 クッキーはクッキーストアに保管されています。
MITに対する保護 TLSの存在は、JavaScriptで確認する必要があります。 旗のとき 安全 Cookieに設定されており、TLSは強制されます。
XSSに対する保護 JavaScriptに実装する必要があります。 暗黙的にフラグがあります httponly JavaScriptを使用したアクセスを防ぐために、Cookieに配置されます。
CSRFに対する保護 ありえない。ここでは他の措置が必要です。 JavaScriptに実装する必要があります。

JWTの道具は、さまざまなプラットフォームで利用できます。現在のリストはjwt.ioにあります。 [3]

a セキュリティイベントトークン 設定 )JWT標準をに拡張します イベント セキュリティに関連するイベントのリストを記録するクレーム。 [4] これらのトークンには、タイムラインと無制限の有効性があります。セットプレイロードは次のように見えます。

{   「ISS」  「https://server.example.com」   "サブ"  「248289761001」   「aud」  「s6bhdrkqt3」   「IAT」  1471566154   「JTI」  「bwjq」    "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
  "events": {
    "http://schemas.openid.net/event/backchannel-logout": {}
  }
}

セットは監査に使用されます。セットがあります RFC 8417 指定。

  1. Prabath Siriwardena: 高度なAPIセキュリティ:OAUTH 2.0以降 。 Apress、ニューヨーク2020、ISBN 978-1-4842-2049-8、 S. 163
  2. JSON Webトークンの主張。 2017年2月23日 2017年5月14日にアクセス (JWTの公的請求のリスト)。
  3. jwt。 Auth0 2017年5月14日にアクセス (英語)。
  4. セキュリティイベントトークン(セット)仕様とIETFセキュリティイベントワーキンググループ。 2017年5月14日にアクセス (英語)。

after-content-x4