「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
以下の内容で最終確認済み。
https://tools.ietf.org/html/rfc7519
JWT : JSON Web Tokenは、jot（ジョット）と発音する、
JOSE : JSON Object Signing and Encryptionのサブセット仕様。
仕様 †
- URL中で使用可能な（、url-safeな）、JSONのアサーションを生成するための仕様
- Base64 URL Encodeしたヘッダ、ペイロード（クレームセット）等を「.」で連結
- このため、url-safeであり、Webでの取り扱いが楽。
- 言語毎のライブラリも整っており、自作も相互運用も容易。
用途 †
- 以下を主張する。
- メッセージ認証コード（MAC）やデジタル署名で完全性保護されていること（JWS）
- および/または暗号化されていること（JWE）
- 暗号化により、鍵でペイロード（クレームセット）の改ざんチェックが可能（＝信頼関係のセマンティクス）。
この特徴のため、仲介者を伴う（改竄・盗聴の危険性がある）情報のやり取りに利用される。
構造 †
構成要素 †
以下の要素から構成される。
ここの詳細は、RFCを参照。
個別に、
などを参照のこと。
ヘッダ †
- JOSE : JSON Object Signing and Encryptionヘッダ
- 署名・検証のために利用するもの。
- 電子署名、MAC に関する情報を保持する。
- Registered Header
- RFC 上で仕様化されているヘッダ内容。
- 署名に使うアルゴリズムを示す alg
- 公開鍵の在処を示す jku (JWK Set URL)
- Public Header
定義可能だが名前の衝突を避けるために IANA に登録するヘッダ内容。
- Private Header
衝突するかもしれないから注意が必要なヘッダ内容。
- ヘッダ・パラメタ
- typ（オプション）を設定するなら、
- "JWT"
- "JOSE" : JWSやJWEのCompact Serialization
- "JOSE+JSON" : JWSやJWEのJSON Serialization
- "application/"接頭辞を省略したMedia Types
- cty（オプション）は、構造情報を伝えるために使用される。
- "JWT" : ネストされたJWTのペイロード
- "application/"接頭辞を省略したMedia Types
- ヘッダ・パラメタとして複製されたクレーム
JWEのクレームの一部を復号化前に処理方法を決定する目的で使用する。
ペイロード（クレームセット） †
- 予約済みクレーム
以下すべて、使用は任意 (OPTIONAL)。
| # | キー | 説明 |
| 1 | "iss" | Issuer クレーム |
| 2 | "sub" | Subject クレーム |
| 3 | "aud" | Audience クレーム |
| 4 | "exp" | Expiration Time クレーム |
| 5 | "nbf" | Not Before クレーム |
| 6 | "iat" | Issued At クレーム |
| 7 | "jti" | JWT ID クレーム |
| 8 | "typ" | Type クレーム |
- パブリック・クレーム
- JWTの利用者によって自由に定義できる。
- 衝突を避けるために、
- IANA JSON Web Token Claim Registry に登録するか、
- 耐衝突性を持つ名前空間を含むパブリック名にすべき。
- プライベート・クレーム
- JWTの作成者と利用者の合意のものとで、
予約済みでもパブリック・クレーム名でもないプライベート・クレーム名を利用可能。
- ただし、衝突の可能性があるため、慎重に使用する必要がある。
その他 †
JWTの種類によって様々。
JWTの種類 †
ネストされたJWT †
- ペイロード（若しくは平文）として、JWSやJWEが使用される。
- 署名と暗号化の両方が必要なネストされたJWTの署名と暗号化の順序は、
プロデューサがメッセージに署名してから結果を暗号化する（従って、署名を暗号化する）。
無担保JWT †
- JWSでもJWEでもない、プレーンなJWT（無担保JWT）。
- ヘッダ内のalgはnone = {“alg”: “none”} 。
JWTの作成と検証手順 †
JWTの作成手順 †
- JWSやJWEの手順に従って作成
- 入れ子になったJWTの場合にはヘッダの”cty”の値に”JWT”を指定
JWTの検証（復号）手順 †
JWSやJWEの手順に従って検証（復号）
JWTのアルゴリズム †
利用される各アルゴリズムおよびそれらの識別子を定義している仕様
ユースケース †
認証用途 †
コチラを参照。
OAuth 2.0のアクセストークン †
コチラを参照。
シングルサインオン（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から確認する。
- 署名・暗号化は特定用途であれば、１パターン実装すればイイので自作も可能。
- 検証・復号化は網羅性を高めることが難しいので、ライブラリを使用する。
ライブラリ †
様々なライブラリ（相互運用） †
相性がある模様 †
Microsoft Open Technologiesによって開発された、BCL入りしている
JSON Web Token Handler For the Microsoft .NETというライブラリ。
下記が参考になる。
上記は、Resource Ownerであるユーザが介在することなく
ClientがResource ServerのAPIを利用するようなユースケースらしく、
以下の様な、grant_typeで、Access Tokenを取得して、WebAPIにアクセスする。
この時、Googleの秘密鍵のキー長は1024bitだが、
このライブラリは最低でも2048bitを要求しているため、
相互運用が不可だったらしい
（ちなみにVisual Studioが生成するpfxのキー長も1024bitだったりする）。
恐らく、色々なライブラリ間の実装差異で相互運用が難しくなるようなケースがあると思う。
また、マニュアルもほとんどなく、恐らくJWEやJWKに対応していないものと思われる。
以下の2メソッドのインターフェイスを確認すると、
引数・戻り値に、Microsoft.Owin.Security.AuthenticationTicket?が在ったり、
.NET技術と結合度が高く、相互運用には向かないように見える。
検索結果 †
- NuGetやWebを検索した所、以下の3ライブラリの利用者が多い。
Jwt.Net †
System.IdentityModel?.Tokens.Jwt †
上記の、BCL入りしているJwtSecurityTokenHandlerが含まれる名前空間より
一つ下の階層のJWT系の追加ライブラリを格納する名前空間であるもよう。
※ 名前空間的には、下の階層の方が、上位スタックになるんだなぁ。
必要に応じて、追加でNuGetから取得する必要がある。
自作のJWTライブラリ †
以下を考慮して開発可能。
用途 †
- 認証など、特定用途の署名・暗号化、検証・復号化レベルであればであれば自作ライブラリで良い。
- 正しく署名・暗号化できていれば、他のライブラリでも検証・復号化が可能。
相互運用（検証・復号化） †
他のライブラリでも検証・復号化が可能かどうかは、
JSON Web Tokens - jwt.ioなどの検証サイトを使用して確認すると良い。
Base64url Enc/Dec †
このライブラリも必要になる。
脆弱性 †
実装に脆弱性を作らないように注意する。
ざっくり、
- alg を "none"に改竄された場合、検証でtrueにするな。
- alg を "HMAC-SHA*"に改竄された場合、検証でtrueにするな。
ということらしい。
後者は、
- 公開鍵暗号方式 (RSA / ECDSA) から共通鍵暗号方式 (HMAC) に差し替え、
- 「公開鍵文字列を共通鍵として利用して」署名を生成することで、
検証でtrueになるJWTを生成できてしまう模様。
特定用途の自作ライブラリであれば、
署名と検証のalgは固定にしておくのも良いと考える。
参考 †
参考 †
- 以下の様な話もあるが、提案されているFernetは（今の所）メジャーではない。
内部 †
RFC †
OAuth WG †
JOSE WG †
jose : Javascript Object Signing and Encryption
OpenID ファウンデーション・ジャパン †
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :暗号化
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
