![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
JWTとはJSON Web Tokenの略でjot（ジョット）と発音する。
以下の要素から構成される。
ここの詳細は、RFCを参照。
個別に、
などを参照のこと。
署名検証のために利用するもの。
基本的なもので、
{
"alg": "HS256",
"typ": "JWT"
}{
"alg": "RS256",
"typ": "JWT"
}とか。
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}JWTを作る方法としてJWSとJWE、もしくは両方を使った方法がある。
http://openid-foundation-japan.github.io/draft-ietf-jose-json-web-signature-14.ja.html
ヘッダー.クレームセット.署名
BASE64URL (UTF-8 (Header)) . BASE64URL (UTF-8 (Claim Set)) . BASE64URL (UTF-8 (Signature))
JWEは、暗号化のオプション（暗号化されたJWT）。
ヘッダー.キー.初期ベクター.暗号文.認証タグ
BASE64URL (UTF-8 (JWE Protected Header)) . BASE64URL(JWE Encrypted Key) . BASE64URL(JWEInitialization Vector) . BASE64URL(JWE Ciphertext) . BASE64URL(JWE Authentication Tag)
ヘッダ内のalgはnone = {“alg”: “none”} 。
ヘッダー.ペイロード.
BASE64URL (UTF-8 (Header)) . BASE64URL (UTF-8 (Claim Set)) .
| 項番 | 言語 | ライブラリのURL |
| 0 | JavaScript | https://www.w3.org/TR/WebCryptoAPI/ |
| 1 | Ruby | https://github.com/nov/json-jwt |
| 2 | Python | https://github.com/rohe/pyjwkest |
| 3 | Java | https://bitbucket.org/nimbusds/nimbus-jose-jwt/wiki/Home |
| 4 | PHP | https://github.com/ritou/php-Akita_JOSE |
| 5 | Perl | https://github.com/xaicron/p5-JSON-WebToken |
| 6 | Objective-C | https://github.com/yourkarma/JWT |
| 7 | .NETなら | Nugetからメジャーな奴を入れる。 |
JWS や JWE などで利用する公開鍵(JWK : JSON Web Key)を JSON 形式で表現するための仕様
{
"alg": "RS256",
"e": "AQAB",
"ext": false,
"kty": "RSA",
"n": "・・・"
}JWS や JWE で利用される各アルゴリズムおよびそれらの識別子を定義している仕様
コチラを参照。
コチラを参照。
以下でメール着信確認トークンを使用するようなケースで利用する事で、
トークンをtempストアに格納して、後に比較するような実装が不要になる。
https://tools.ietf.org/html/rfc7521
https://tools.ietf.org/html/rfc7523
JWT を RFC 7521（上記） の アサーション として利用するための仕様
Microsoft Open Technologiesによって開発された、
JSON Web Token Handler For the Microsoft .Netというライブラリ。
下記が参考になる。
上記は、Resource Ownerであるユーザが介在することなく
ClientがResource ServerのAPIを利用するようなユースケースらしく、
以下の様な、grant_typeで、Access Tokenを取得して、WebAPIにアクセスする。
この時、Googleの秘密鍵のキー長は1024bitだが、
このライブラリは最低でも2048bitを要求しているため、
相互運用が不可だったらしい。
恐らく、色々なライブラリ間の実装差異で
相互運用が難しくなるようなケースがあると思う。
以下の2メソッドのインターフェイスを確認すると、
引数・戻り値に、Microsoft.Owin.Security.AuthenticationTicket?が在ったり、
.NET技術と結合度が高く、相互運用には向かないように見える。
Version Historyを参照。
以前は、JSON Web Token Handler For the Microsoft .Netという表示名だったようだが、
version 05-00からは、パッケージ名（＝名前空間）と同じ表示名になっている。
ライセンスはMITだが、ソースコードをGithubやCodePlex?上に確認できない・・・。
上記の、BCL入りしているJwtSecurityTokenHandler?が含まれる名前空間より
一つ下の階層のJWT系の追加ライブラリを格納する名前空間であるもよう。
必要に応じて、追加でNugetから取得する必要がある。
詳しくは、Version Historyを参照。
以下を考慮して開発可能。
他のライブラリでも検証・復号化が可能かどうかは、
JSON Web Tokens - jwt.ioなどの検証サイトを使用して確認すると良い。
このライブラリも必要になる。
RFC4648に条件付きでパディング外すなどの難しい処理が
あるようなので、ライブラリを使用するほうが良いかもしれない
（Microsoft.Owin.Securityのicrosoft.Owin.Security.DataHandler?.Encoderにライブラリがある）。
特定用途であれば、上記サイトにも、.NETにも実装されている
署名・暗号化アルゴリズムを使用すると良い。
認証であれば公開鍵暗号化方式のRS256（RSA using SHA-256 hash）が良い。
実装に脆弱性を作らないように注意する。
ざっくり、
ということらしい。
後者は、
検証でtrueになるJWTを生成できてしまう模様。
特定用途の自作ライブラリであれば、
署名と検証のalgは固定にしておくのも良いと考える。
ちなみに、
は、
が記載されていない。
また、
は、いくつか誤りがあるようで、RS256は、HMACSHA256ではない。
故に、（実際にGoogle側での検証ができているので）こちらのほうが参考になる。
ココを見ると、
これで、実際にGoogle側での検証ができている。
秘密鍵・公開鍵のキーペアを、
検討（検証）する必要が出てくる。
上記のように、RFCを正確に理解していないとJWTライブラリ作成は難しいが、
JSON Web Tokens - jwt.ioなどの検証サイトを使用して検証できれば、及第点に達していると言える。
以下のように検証できる。
- 左ペイン（Encoded）にJWTの文字列を貼り付ける。
- すると、入力したJWTから、ペイン（Dencoded）のHeader、Payloadに自動的に表示がなされる。
- 次に、上部 ALGORITHM selectbox から、Headerに表示された"alg"と同じアルゴリズムを選択する。
- 最後に、VERIFY SIGNATUREに、署名の検証に使用するキーを入力する。。
となる。
#ref(): File not found: "HS256.png" at page "JWT"
ポイントは、
- 「-----BEGIN PUBLIC KEY-----」
- 「公開鍵」
- 「-----END PUBLIC KEY-----」
と、ヘッダ・フッタ部分も貼り付ける必要がある所だろうか。
#ref(): File not found: "RS256.png" at page "JWT"
jose : Javascript Object Signing and Encryption
Tags: :認証基盤, :クレームベース認証, :暗号化
