Open棟梁Project - マイクロソフト系技術情報 Wiki
目次 †
概要 †
- JWTとはJSON Web Tokenの略でjot（ジョット）と発音する。
- JSON (の Base64 URL Encode) 形式で Assertion を生成するための仕様
- JSONを使ったurl-safeなペイロード（クレームセット）の表現方法
- ペイロード（クレームセット）が改ざんされていないかをチェック可能
- この特徴のため、
仲介者を伴う（改竄・盗聴の危険性がある）情報のやり取りに利用される。
- 主に、認証サーバから返されるトークンに使われる。
- 実際、OAuth拡張やOpenID Connectなどで使われている。
- JWTを作る方法としてJWSとJWE、もしくは両方を使った方法がある。
構造 †
構成要素 †
以下の要素から構成される。
ヘッダ †
署名検証のために利用するもの。
ペイロード（クレームセット） †
- 予約済みクレーム
- パブリッククレーム
- プライベートクレーム
署名 †
JWTの種類 †
JWS †
署名されたJWT
- 署名付きのデータを JSON (の Base64 URL Encode) 形式で表現するための仕様
- 多くの場合は JSON Payload に対して署名するケースで利用される。
- OpenID Connect の ID Tokenなどで利用されている。
BASE64URL (UTF-8 (Header))
.
BASE64URL (UTF-8 (Claim Set))
.
Base64url (UTF-8 ( Signature))
JWE †
暗号化されたJWT
- 暗号化されたデータを JSON (の Base64 URL Encode) 形式で表現するための仕様
- 暗号化されたSAML Assertionを Connect に移行するユースケースなどが想定される。
ヘッダー.キー.初期ベクター.暗号文.認証タグ
BASE64URL (UTF-8 (JWE Protected Header))
.
BASE64URL(JWE Encrypted Key)
.
BASE64URL(JWEInitialization Vector)
.
BASE64URL(JWE Ciphertext)
.
BASE64URL(JWE Authentication Tag)
プレーンJWT †
ヘッダ内のalgはnone = {“alg”: “none”} 。
ヘッダー.ペイロード.
BASE64URL (UTF-8 (Header))
.
BASE64URL (UTF-8 (Claim Set))
.
その他 †
- JWK
- JWS や JWE などで利用する「鍵」を JSON 形式で表現するための仕様
- OpenID Connect Discovery をサポートしている IdP は公開鍵を JWK Set 形式で公開していることが多い。
- JWA
- JWS や JWE で利用される各アルゴリズムおよびそれらの識別子を定義している仕様
JWTの作成と検証手順 †
難しいのでライブラリを使用する。.NETならNugetからメジャーな奴を入れる。
JWTの作成手順 †
概要 †
- JWSまたはJWEの手順に従って生成
- 入れ子になったJWTの場合にはヘッダの”cty”の値に”JWT”を指定
手順（JWS） †
- ヘッダを生成し、UTF-8のバイト文字列に変換し、BASE64urlエンコード。
- クレームセットを生成し、UTF-8のバイト文字列に変換し、BASE64urlエンコード。
- BASE64urlエンコード済みのヘッダとクレームセットを
ピリオドで連結する、UTF-8バイト文字列に変換し、BASE64urlエンコード。
- 上記をヘッダで指定した暗号化プロバイダで暗号化（ハッシュ or 暗号化）
JWTの検証手順 †
- JWTをヘッダ、クレームセット、署名に分割しBASE64urlでデコード
- ヘッダから種類（JWT、JWS、JWE）、暗号化プロバイダを確認
- 種類、暗号化プロバイダを考慮してJWTの検証を行なう。
- JWTの検証が完了した後、クレームセット内の有効期限の検証も行なう。
ユースケース †
認証用途 †
コチラを参照。
OAuth 2.0のアクセストークン †
- Implicitグラント種別のアクセストークンで、認証用途に利用する。
アクセストークンに、OpenID ConnectのIDトークンを参考にして、改竄、置換、CSRF（XSRF）等に
耐える為のクレームを追加し、これを検証すれば、Implicitグラント種別でも安全性が高くなる。
シングルサインオン（SSO） †
- ショップ（Webアプリ）とカート（WebAPI＋SPA）を分離し、
tempストアをサイト間で共有しないで、認証情報を共有するSSOを実現したい。
- JWTにより、以下を跨いだ認証が可能に。
- サーバー（Webアプリ・WebAPI）間
- クライアント（ブラウザ）・サーバー（Webアプリ・WebAPI）間
- マイクロサービス化にも対応可能になる。
サービスの多様化、フロントエンドの多極化
- 認証情報以外の共有したい情報にも利用することができる。
この場合、JWEを使用する可能性がある（HTTPSなら不要だが）。
メール着信確認トークン †
以下でメール着信確認トークンを使用するようなケースで利用する事で、
トークンをtempストアに格納して、後に比較するような実装が不要になる。
- アカウント確認（E-mail confirmation）
- パスワード・リセット
共有用URL †
- OneDrive?のファイル・フォルダ共有にも利用されている。
- URLにオブジェクトに対するACL・ACE的なモノをJWTアサーションに同梱。
- サービスが認証したユーザがオブジェクトに対するアクセス許可を持っているか、ACL・ACEから確認する。
RFC †
Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants †
https://tools.ietf.org/html/rfc7521
- OAuth 2.0 を拡張するアサーションの仕様
- Client Authentication で Client Credentials として使うアサーションの仕様
- Authorization Codeグラント種別のAccess Token と交換するアサーションの仕様
- 単体では利用できず、後の2つのサブ仕様
（RFC7522（SAMLアサーション）、7523（JWTアサーション））
の共通部分を抽象化した仕様になっている。
JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants †
https://tools.ietf.org/html/rfc7523
JWT を RFC 7521（上記） の アサーション として利用するための仕様
参考 †
参考 †
RFC †
JOSE WG †
jose : Javascript Object Signing and Encryption
OAuth WG †
Tags: :認証基盤, :クレームベース認証
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
