- 追加された行はこの色です。
- 削除された行はこの色です。
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-戻る
--[[JSON]]
--[[クレームベース認証]]
* 目次 [#ld8342fd]
#contents
*概要 [#yfb13271]
-http://openid-foundation-japan.github.io/draft-ietf-oauth-json-web-token-11.ja.html
JWTとはJSON Web Tokenの略でjot（ジョット）と発音する。
**仕様 [#u3914621]
-JSONのアサーションを生成するための仕様
-Base64 URL Encodeした[[ヘッダ>#m9c6f99a]]、[[ペイロード（クレームセット）>#m5b94cda]]等を「.」で連結
--このため、url-safeであり、Webでの取り扱いが楽。
--言語毎のライブラリも整っており、相互運用が容易。
**用途 [#s26d45ab]
-暗号化により、鍵で[[ペイロード（クレームセット）>#m5b94cda]]の改ざんチェック可能（＝信頼関係のセマンティクス）。
-この特徴のため、仲介者を伴う（改竄・盗聴の危険性がある）情報のやり取りに利用される。
--主に、認証サーバから返されるトークンに使われる。
--実際、[[OAuth]] 2.0 拡張や[[OpenID Connect]]などで使われている。
*構造 [#ad27d98c]
**構成要素 [#q01f4062]
以下の要素から構成される。
ここの詳細は、[[RFC>#t002076b]]を参照。
個別に、
-[[OpenID Connect]]の[[IDトークン（クレーム）>OpenID Connect#ofb73c59]]
-[[JWT生成プログラムの作成方法の参考サイト>JWT#e11d0494]]
などを参照のこと。
***ヘッダ [#m9c6f99a]
-JSONオブジェクト（JOSE）ヘッダ
--署名・検証のために利用するもの。
--電子署名、MAC に関する情報を保持する。
--このヘッダは、[[JWS>#md583102]]でも[[JWE>#y75c2692]]でも共通
-ヘッダの内容は、3 種に分けられている。
--Registered Header
---RFC 上で仕様化されているヘッダ内容。
---署名に使うアルゴリズムを示す alg
---公開鍵の在処を示す jku (JWK Set URL)
--Public Header~
定義していいけど名前の衝突を避けるために IANA に登録したヘッダ内容。
--Private Header
衝突するかもしれないから注意が必要なヘッダ内容。
-[[JWS>#md583102]]の基本的なヘッダの場合、
--秘密鍵で検証可能なHS256（HMAC using SHA-256 hash）のJWT([[JWS>#md583102]])
{
"alg": "HS256",
"typ": "JWT"
}
--公開鍵で検証可能なRS256（RSA using SHA-256 hash）のJWT([[JWS>#md583102]])
{
"alg": "RS256",
"typ": "JWT"
}
>などがある。
***ペイロード（クレームセット） [#m5b94cda]
-[[予約済みクレーム>https://openid-foundation-japan.github.io/draft-ietf-oauth-json-web-token-11.ja.html#ReservedClaimName]]~
以下すべて、使用は任意 (OPTIONAL)。
--"iss" : Issuer クレーム
--"sub" : (Subject) クレーム
--"aud" : (Audience) クレーム
--"exp" : (Expiration Time) クレーム
--"nbf" : (Not Before) クレーム
--"iat" : (Issued At) クレーム
--"jti" : (JWT ID) クレーム
--"typ" : (Type) クレーム
-パブリック・クレーム
--JWTの利用者によって自由に定義できる。
--衝突を避けるために、
---IANA JSON Web Token Claim Registry に登録するか、
---耐衝突性を持つ名前空間を含むパブリック名にすべき。
-プライベート・クレーム
--JWTの作成者と利用者の合意のものとで、~
予約済みでもパブリック・クレーム名でもないプライベート・クレーム名を利用可能。
--ただし、衝突の可能性があるため、慎重に使用する必要がある。
-サンプル
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
***署名 [#f7edb04c]
-色々な暗号化アルゴリズムを使用して作成した署名
-署名の検証キーの共有方法には以下の方法が有る。
--検証用エンドポイントを使用する。
--[[JWK>#t3bd8497]]を使用する。
--[[X.509証明書>証明書]]を使用する。
-参考 : OpenID Connect の署名検証 - Carpe Diem~
http://christina04.hatenablog.com/entry/2015/01/27/131259
--検証方法①：Googleの検証用エンドポイントを利用する
--検証方法②：IdP（Google）の提供している公開鍵を使って自分で検証する
---公開鍵①：[[JWK>#t3bd8497]]（JSON Web Key）を使う
---公開鍵①：[[X.509証明書>証明書]]を使う
**JWTの種類 [#j5dabc60]
http://openid-foundation-japan.github.io/draft-ietf-jose-json-web-signature-14.ja.html
***JWS [#md583102]
-ざっくり言って「[[署名>#f7edb04c]]付きの JWT = JWS」
-JWT と言えば、だいたい、JWSの事を言う。
-JWSは、暗号化ではなく[[署名>#f7edb04c]]なので、JSON の中身は誰でも見られる。
-通常、発行者だけが秘密鍵で検証できるが、
--秘密鍵を使用すれば発行者だけが検証可能。
--公開鍵を使用すれば誰でも検証可能。
-OpenID Connect の ID Tokenなどで利用されている。
-[[JWSの詳細についてはコチラ。>#u6d67bd4]]
***JWE [#y75c2692]
-JWEは、暗号化のオプション（暗号化されたJWT）。
--暗号化されたデータを JSON (の Base64 URL Encode) 形式で表現するための仕様
--暗号化された[[SAML]] アサーションを Connect に移行するユースケースなどが想定される。
-フォーマット
-フォーマット（[[JWS Compact Serialization>#xe1c18e7]]）
--[[ヘッダ>#m9c6f99a]].キー.初期ベクター.暗号文.認証タグ
--
BASE64URL (UTF-8 (JWE Protected Header))
.
BASE64URL(JWE Encrypted Key)
.
BASE64URL(JWEInitialization Vector)
.
BASE64URL(JWE Ciphertext)
.
BASE64URL(JWE Authentication Tag)
***プレーンJWT [#d5575bd7]
-[[JWS>#md583102]]でも[[JWE>#y75c2692]]でもない、プレーンなJWT。
-[[ヘッダ>#m9c6f99a]]内のalgはnone = {“alg”: “none”} 。
-フォーマット
-フォーマット（[[JWS Compact Serialization>#xe1c18e7]]）
--[[ヘッダ>#m9c6f99a]].[[ペイロード（クレームセット）>#m5b94cda]].
--
BASE64URL (UTF-8 (Header))
.
BASE64URL (UTF-8 (Claim Set))
.
***JWK [#t3bd8497]
[[JWS>#md583102]]や[[JWE>#y75c2692]]などで利用する公開鍵(JWK : JSON Web Key)を JSON 形式で表現するための仕様
-OpenID Connect Discovery をサポートしている IdP は公開鍵を JWK Set 形式で公開していることが多い。
-[[FIDO]]2.0 の [[Web Authentication API]] が生成する公開鍵なども、JWK で表現されている。
{
"alg": "RS256",
"e": "AQAB",
"ext": false,
"kty": "RSA",
"n": "・・・"
}
***JWA [#y4a514dc]
[[JWS>#md583102]]や[[JWE>#y75c2692]]で利用される各アルゴリズムおよびそれらの識別子を定義している仕様
*JWSの詳細 [#u6d67bd4]
[[ヘッダ>#m9c6f99a]]、[[ペイロード（クレームセット）>#m5b94cda]]、[[署名>#f7edb04c]]を以下のように[[表現(エンコード)>#xd09f92e]]したもの。
**表現(エンコード) [#xd09f92e]
以下の２つの表現(エンコード)方法がある。
***JWS Compact Serialization [#xe1c18e7]
-[[署名>#f7edb04c]]付きのデータを JSON (の Base64 URL Encode) 形式で表現する。
-「Base64」ではなく「Base64 &color(red){URL};」なので「=」は含まれない。
***JWS JSON Serialization [#t41a19b3]
-pure な JSON として表現されるフォーマット
-[[署名>#f7edb04c]]を複数持てるといった違いがある。
-URL-Safe でもなければコンパクトでもない。
-あまり市民権を獲得しているようには思えない。
-[[署名>#f7edb04c]]を複数持てるといった違いがある。
**アルゴリズム [#f133bbd2]
***RS256 [#xe033b54]
alg=RS256(RSA-SHA256)による署名を行う。
-フォーマット
-フォーマット（[[JWS Compact Serialization>#xe1c18e7]]）
--[[ヘッダ>#m9c6f99a]].[[ペイロード（クレームセット）>#m5b94cda]].[[署名>#f7edb04c]]
--
BASE64URL (UTF-8 (Header))
.
BASE64URL (UTF-8 (Claim Set))
.
BASE64URL (UTF-8 (Signature))
***HS256 [#b8d0ee68]
alg=HS256(HMAC-SHA256 x JWS Compact Serialization)によるMessage Authentication Codes (MACs)付与
alg=HS256(HMAC-SHA256)によるMAC付与
-フォーマット
-フォーマット（[[JWS Compact Serialization>#xe1c18e7]]）
*JWTの作成と検証手順 [#dd514c38]
-JWT を扱えるライブラリは沢山ある。
-署名・暗号化は特定用途であれば、１パターン実装すればイイので自作も可能。
-検証・復号化は網羅性を高めることが難しいので、ライブラリを使用する。
--OpenID Connect の JWT の署名を自力で検証してみると見えてきた公開鍵暗号の実装の話 - Qiita~
http://qiita.com/bobunderson/items/d48f89e2b3e6ad9f9c4c
**ライブラリ [#n981cbc3]
-JSON Web Token の効用 - Qiita~
http://qiita.com/kaiinui/items/21ec7cc8a1130a1a103a
-WebCrypto APIでJSON Web Tokenの検証を試してみる - Qiita~
http://qiita.com/tomoyukilabs/items/faa66805a440f4b30cfb
|項番|言語|ライブラリのURL|h
|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からメジャーな奴を入れる。|
**JWTの作成手順 [#pfa9f0dd]
***概要 [#wbf0fb96]
-[[JWS>#md583102]]や[[JWE>#y75c2692]]の手順に従って生成
-入れ子になったJWTの場合には[[ヘッダ>#m9c6f99a]]の”cty”の値に”JWT”を指定
***手順（JWS） [#p744be69]
-[[ヘッダ>#m9c6f99a]]を生成し、UTF-8のバイト文字列に変換し、BASE64urlエンコード。
-[[ペイロード（クレームセット）>#m5b94cda]]を生成し、UTF-8のバイト文字列に変換し、BASE64urlエンコード。
-BASE64urlエンコード済みの[[ヘッダ>#m9c6f99a]]と[[ペイロード（クレームセット）>#m5b94cda]]を~
ピリオドで連結する、UTF-8バイト文字列に変換し、BASE64urlエンコード。
-上記をヘッダで指定した暗号化プロバイダで暗号化（ハッシュ or 暗号化）
**JWTの検証手順 [#r8923712]
***手順 [#ib69bb72]
-JWTを[[ヘッダ>#m9c6f99a]]、[[ペイロード（クレームセット）>#m5b94cda]]、[[署名>#f7edb04c]]に分割しBASE64urlでデコード。
-[[ヘッダ>#m9c6f99a]]から種類（[[JWS>#md583102]]、[[JWE>#y75c2692]]）、暗号化プロバイダを確認する。
-[[署名方法>#f7edb04c]]（暗号化プロバイダ、キー）を考慮してJWTの検証を行なう。
-検証完了後、[[ペイロード（クレームセット）>#m5b94cda]]内の有効期限の検証も行なう。
***検証サイト [#s7ab5c53]
[[下記参照>#ma412b10]]
*ユースケース [#neb31e45]
-http://openid-foundation-japan.github.io/draft-ietf-jose-use-cases-03.ja.html
-JSON Web Token の効用 - Qiita~
http://qiita.com/kaiinui/items/21ec7cc8a1130a1a103a
-JWTによるJSONに対する電子署名と、そのユースケース ｜ Developers.IO~
http://dev.classmethod.jp/server-side/json-signing-jws-jwt-usecase/
**認証用途 [#yd304024]
-JWT(JSON Web Token)を使った認証を試みる | 69log~
https://blog.kazu69.net/2016/07/30/authenticate_with_json_web_token/
-JWTを認証用トークンに使う時に調べたこと - Carpe Diem~
http://christina04.hatenablog.com/entry/2016/06/07/123000
-JWT(Json Web Token)を利用したWebAPIでのCredentialの受け渡しについて | I am mitsuruog~
http://blog.mitsuruog.info/2014/08/jwtjson-web-tokenwebapicredential.html
-カスタム・アプリケーションによる認証フローとプログラミング - Build Insider~
http://www.buildinsider.net/web/msidentitydev/03
***[[OpenID Connect]]のIDトークン [#o5f70766]
[[コチラ>OpenID Connect#ofb73c59]]を参照。
***[[OAuth]] 2.0のアクセストークン [#f9d1b3ca]
[[コチラ>OAuthによる外部ログイン（認証）の研究#yf9cec19]]を参照。
***シングルサインオン（SSO） [#qc19ebd8]
-シングルサインオン - Wikipedia~
https://ja.wikipedia.org/wiki/%E3%82%B7%E3%83%B3%E3%82%B0%E3%83%AB%E3%82%B5%E3%82%A4%E3%83%B3%E3%82%AA%E3%83%B3
--近年は、SAMLアサーションやJWTアサーション（[[OpenID Connect]]の[[IDトークン>OpenID Connect#ofb73c59]]）~
によって、クレデンシャル伝えてSSOを実現する方式が一般的になってきている。
-JWTを使った簡易SSOで徐々にシステムをリニューアルしている話~
http://www.slideshare.net/TsuchiKazu/jwt-ssopepabotech
--ショップ（Webアプリ）とカート（WebAPI＋SPA）を分離し、~
tempストアをサイト間で共有しないで、認証情報を共有するSSOを実現したい。
--JWTにより、以下を跨いだ認証が可能に。
---サーバー（Webアプリ・WebAPI）間
---クライアント（ブラウザ）・サーバー（Webアプリ・WebAPI）間
--また、その後の、
---マイクロサービス化にも対応可能になる。~
サービスの多様化、フロントエンドの多極化
---認証情報以外の共有したい情報にも利用することができる。~
この場合、[[JWE>#y75c2692]]を使用する可能性がある（HTTPSなら不要だが）。
-JWT(JSON Webトークン)を使用したシングルサインオンの設定 – Zendesk Support~
https://support.zendesk.com/hc/ja/articles/203663816-JWT-JSON-Web%E3%83%88%E3%83%BC%E3%82%AF%E3%83%B3-%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9F%E3%82%B7%E3%83%B3%E3%82%B0%E3%83%AB%E3%82%B5%E3%82%A4%E3%83%B3%E3%82%AA%E3%83%B3%E3%81%AE%E8%A8%AD%E5%AE%9A
**メール着信確認トークン [#uc4b4ccb]
以下でメール着信確認トークンを使用するようなケースで利用する事で、~
トークンをtempストアに格納して、後に比較するような実装が不要になる。
-アカウント確認（E-mail confirmation）
-パスワード・リセット
**共有用URL [#w567a950]
-OneDriveのファイル・フォルダ共有にも利用されている。
-URLにオブジェクトに対する[[ACL・ACE]]的なモノをJWTアサーションに同梱。
-サービスが認証したユーザがオブジェクトに対するアクセス許可を持っているか、[[ACL・ACE]]から確認する。
*.NETのJWTライブラリ [#c4fe6111]
**相性がある模様 [#l9bea68e]
***[[System.IdentityModel.Tokens.JwtSecurityTokenHandler>https://msdn.microsoft.com/ja-jp/library/system.identitymodel.tokens.jwtsecuritytokenhandler.aspx]] [#y171da32]
Microsoft Open Technologiesによって開発された、~
JSON Web Token Handler For the Microsoft .Netというライブラリ。
下記が参考になる。
-IdM実験室~
http://idmlab.eidentity.jp
-- [JWT/OAuth]Service Accountを使ってGoogle APIを利用する①, ②~
---http://idmlab.eidentity.jp/2015/01/jwtoauthservice-accountgoogle-api.html
---http://idmlab.eidentity.jp/2015/01/jwtoauthservice-accountgoogle-api_5.html
上記は、Resource Ownerであるユーザが介在することなく~
ClientがResource ServerのAPIを利用するようなユースケースらしく、~
以下の様な、grant_typeで、Access Tokenを取得して、WebAPIにアクセスする。
-grant_type:~
http://oauth.net/grant_type/jwt/1.0/bearer
--TenantContextID、AppPrincipalId、SymmetricKey を使用して、
--JWTを投げると、Access Tokenが返ってくるflowのgrant_typeらしい。
この時、Googleの秘密鍵のキー長は1024bitだが、~
このライブラリは最低でも2048bitを要求しているため、
>相互運用が不可だったらしい。
恐らく、色々なライブラリ間の実装差異で~
相互運用が難しくなるようなケースがあると思う。
***[[Microsoft.Owin.Security.Jwt.JwtFormat>https://msdn.microsoft.com/ja-jp/library/microsoft.owin.security.jwt.jwtformat.aspx]] [#ib881924]
以下の2メソッドのインターフェイスを確認すると、~
引数・戻り値に、Microsoft.Owin.Security.AuthenticationTicketが在ったり、~
.NET技術と結合度が高く、相互運用には向かないように見える。
-[[JwtFormat.Protect メソッド>https://msdn.microsoft.com/ja-jp/library/dn450167.aspx]]
-[[JwtFormat.Unprotect メソッド>https://msdn.microsoft.com/ja-jp/library/dn450160.aspx]]
**検索結果 [#r4ac23c8]
-NugetやWebを検索した所、以下の2ライブラリの利用者が多い。
-ダウンロード数を確認した所、System.IdentityModel.Tokens.Jwtが優勢。
***JSON Web Token (JWT) implementation for .NET [#o8ee7ae2]
-NuGet Gallery | JWT 1.3.4~
https://www.nuget.org/packages/JWT/
Version Historyを参照。
***System.IdentityModel.Tokens.Jwt [#f8161509]
以前は、JSON Web Token Handler For the Microsoft .Netという表示名だったようだが、~
version 05-00からは、パッケージ名（＝名前空間）と同じ表示名になっている。~
ライセンスはMITだが、ソースコードをGithubやCodePlex上に確認できない・・・。
上記の、BCL入りしているJwtSecurityTokenHandlerが含まれる名前空間より~
一つ下の階層のJWT系の追加ライブラリを格納する名前空間であるもよう。
必要に応じて、追加でNugetから取得する必要がある。
-NuGet Gallery | System.IdentityModel.Tokens.Jwt~
https://www.nuget.org/packages/System.IdentityModel.Tokens.Jwt/
詳しくは、Version Historyを参照。
**自作ライブラリについて [#v028206c]
以下を考慮して開発可能。
***用途 [#b90af93a]
-認証など、特定用途の署名・暗号化、検証・復号化レベルであればであれば自作ライブラリで良い。
-正しく署名・暗号化できていれば、他のライブラリでも検証・復号化が可能。
***相互運用（検証・復号化） [#dfbab710]
他のライブラリでも検証・復号化が可能かどうかは、~
[[JSON Web Tokens - jwt.io>https://jwt.io/]]などの検証サイトを使用して確認すると良い。
***Base64urlエンコード・デコード [#n0909b67]
このライブラリも必要になる。
-【C#】Base64urlエンコード・デコード - Qiita~
http://qiita.com/hukatama024e/items/b1352cabcd85948511c3
>RFC4648に条件付きでパディング外すなどの難しい処理が~
あるようなので、ライブラリを使用するほうが良いかもしれない~
（Microsoft.Owin.Securityのicrosoft.Owin.Security.DataHandler.Encoderにライブラリがある）。
***[[署名・暗号化アルゴリズム>.NETの署名・暗号化アルゴリズム]] [#p4042a8b]
特定用途であれば、上記サイトにも、.NETにも実装されている
-KeyedHashAlgorithm
--RS256（HMAC using SHA-256 hash）
---HMACSHA256 クラス (System.Security.Cryptography)~
https://msdn.microsoft.com/ja-jp/library/system.security.cryptography.hmacsha256.aspx
-AsymmetricAlgorithm
--RS256（RSA using SHA-256 hash）
---RSACryptoServiceProvider クラス (System.Security.Cryptography)~
https://msdn.microsoft.com/ja-jp/library/system.security.cryptography.rsacryptoserviceprovider.aspx
---Using RSACryptoServiceProvider for RSA-SHA256 signatures – .NET Security Blog~
https://blogs.msdn.microsoft.com/shawnfa/2008/08/25/using-rsacryptoserviceprovider-for-rsa-sha256-signatures/
[[署名・暗号化アルゴリズム>.NETの署名・暗号化アルゴリズム]]を使用すると良い。
認証であれば公開鍵暗号化方式のRS256（RSA using SHA-256 hash）が良い。
***脆弱性 [#j8e0d191]
実装に脆弱性を作らないように注意する。
-JWS 実装時に作りがちな脆弱性パターン - OAuth.jp~
http://oauth.jp/blog/2015/03/16/common-jws-implementation-vulnerability/
ざっくり、
-alg を "none"に改竄された場合、検証でtrueにするな。
-alg を "HMAC-SHA*"に改竄された場合、検証でtrueにするな。
ということらしい。
後者は、
-公開鍵暗号方式 (RSA / ECDSA) から共通鍵暗号方式 (HMAC) に差し替え、
-「公開鍵文字列を共通鍵として利用して」署名を生成することで、
検証でtrueになるJWTを生成できてしまう模様。
特定用途の自作ライブラリであれば、~
署名と検証のalgは固定にしておくのも良いと考える。
***参考サイト [#e11d0494]
ちなみに、
-C#と.NETを使ってJsonWebTokenをRS256で署名して作成する方法 - ぺぷしのーげん~
http://www.pepsinogen.blog/entry/2016/06/19/C%23%E3%81%A8_NET%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6JsonWebToken%E3%82%92RS256%E3%81%A7%E7%BD%B2%E5%90%8D%E3%81%97%E3%81%A6%E4%BD%9C%E6%88%90%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95
は、
-ToXmlString、FromXmlStringのXML文字列を使用できるか？
-この署名の方法と、ヘッダの表記はあっているか？
が記載されていない。
また、
-oauth - Is there a JSON Web Token (JWT) example in C#? - Stack Overflow~
http://stackoverflow.com/questions/10055158/is-there-a-json-web-token-jwt-example-in-c
は、いくつか誤りがあるようで、RS256は、HMACSHA256ではない。
故に、（実際にGoogle側での検証ができているので）こちらのほうが参考になる。
-IdM実験室: [JWT/OAuth]Service Accountを使ってGoogle APIを利用する②~
http://idmlab.eidentity.jp/2015/01/jwtoauthservice-accountgoogle-api_5.html
ココを見ると、
-{ alg = "RS256", typ = "JWT" }と言うヘッダで、
-RSACryptoServiceProvider + X509Certificate2の署名を行っており、
これで、実際にGoogle側での検証ができている。
秘密鍵・公開鍵のキーペアを、
-ToXmlStringmethod()メソッドによって生成するか？
--一応、[[RFC 3275 - XML-Signature Syntax and Processing - 4.4 The KeyInfo Element>https://www.ietf.org/rfc/rfc3275.txt]]で標準規格化されているもよう。
--そもそも、「KeyInfo Element(DSAKeyValue, RSAKeyValue Elementなど)」サポートされているか？
-X509Certificate2 クラスを使用してX.509 証明書から取得するか？
検討（検証）する必要が出てくる。
***検証サイト [#ma412b10]
上記のように、RFCを正確に理解していないとJWTライブラリ作成は難しいが、~
[[JSON Web Tokens - jwt.io>https://jwt.io/]]などの検証サイトを使用して検証できれば、及第点に達していると言える。
以下のように検証できる。
-手順は、
>
+左ペイン（Encoded）にJWTの文字列を貼り付ける。
+すると、入力したJWTから、ペイン（Dencoded）のHeader、Payloadに自動的に表示がなされる。
+次に、上部 ALGORITHM selectbox から、Headerに表示された"alg"と同じアルゴリズムを選択する。
+最後に、VERIFY SIGNATUREに、署名の検証に使用するキーを入力する。。
>となる。
-HS256の場合~
HS256は非常に単純で、署名に使用したキーのBase64（Base64Url）表現を指定する。
#ref(HS256.png,left,nowrap,HS256,50%)
-RS256の場合~
RS256は署名に使用した秘密鍵に対応する公開鍵を指定する。~
私は、[[X.509証明書>証明書]]を利用したので、[[OpenSSLで公開鍵を取得して>証明書#tb47e80e]]、それを貼り付けた所、検証ができた。~
>ポイントは、
-「-----BEGIN PUBLIC KEY-----」
- 「公開鍵」
-「-----END PUBLIC KEY-----」
>と、ヘッダ・フッタ部分も貼り付ける必要がある所だろうか。
#ref(RS256.png,left,nowrap,RS256,50%)
**Open棟梁 [#c4289f7f]
-JWTの生成と検証 - Open 棟梁 Wiki~
https://opentouryo.osscons.jp/index.php?JWT%E3%81%AE%E7%94%9F%E6%88%90%E3%81%A8%E6%A4%9C%E8%A8%BC
*参考 [#p90217f2]
-JWT Translation #technight~
http://www.slideshare.net/matake/jwt-trans
-JWTについて簡単にまとめてみた - hiyosi's blog~
https://hiyosi.tumblr.com/post/70073770678/jwt%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E7%B0%A1%E5%8D%98%E3%81%AB%E3%81%BE%E3%81%A8%E3%82%81%E3%81%A6%E3%81%BF%E3%81%9F
**JWS [#u904c09f]
-複雑に関係しあうJWTまわりの仕様を見る: JWS (JSON Web Signature) - 理系学生日記~
http://kiririmode.hatenablog.jp/entry/20170225/1488020088
**JWK [#jb58be37]
-WebCrypto APIでJSON Web Tokenの検証を試してみる - Qiita~
http://qiita.com/tomoyukilabs/items/faa66805a440f4b30cfb
--Google OpenID Connectの場合、署名を検証するために必要となるJWKがWebサイト上で公開されている。
--一定時間ごとに更新されるため、署名の検証時にはその都度JWKの内容をWebサイトから取得する。~
https://www.googleapis.com/oauth2/v2/certs
-OAuth Revocation と JWK を翻訳しました - OAuth.jp~
http://oauth.jp/blog/2016/07/01/jwk-and-oauth-revocation-translated/
--JSON Web Key (JWK) Thumbprint~
http://openid-foundation-japan.github.io/rfc7638.ja.html
**RFC [#t002076b]
-IETF JOSE WG と OAuth WG から一気に9本の RFC が！ - OAuth.jp~
http://oauth.jp/blog/2015/05/20/jose-and-oauth-assertion-rfcs/
***JOSE WG [#z5dc6cf2]
jose : Javascript Object Signing and Encryption
-RFC 7515 - JSON Web Signature (JWS)~
https://tools.ietf.org/html/rfc7515
-RFC 7516 - JSON Web Encryption (JWE)~
https://tools.ietf.org/html/rfc7516
-RFC 7517 - JSON Web Key (JWK)~
https://tools.ietf.org/html/rfc7517
-RFC 7518 - JSON Web Algorithms (JWA)~
https://tools.ietf.org/html/rfc7518
-RFC 7520 - Examples of Protecting Content~
Using JSON Object Signing and Encryption (JOSE)~
https://tools.ietf.org/html/rfc7520
***OAuth WG [#vdd1ecf0]
-RFC 7519 - JSON Web Token (JWT)~
https://tools.ietf.org/html/rfc7519
-RFC 7521 - 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アサーション））の共通部分を抽象化した仕様。
-[[RFC 7521, 7522, 7523>JWT bearer token authorizationグラント種別#c65d5829]]
-RFC 7522 - Security Assertion Markup Language (SAML) 2.0 Profile~
for OAuth 2.0 Client Authentication and Authorization Grants~
https://tools.ietf.org/html/rfc7522
>JWT を [[RFC 7521（上記）>#e7d6a65b]] の アサーション として利用するための仕様
-RFC 7523 - JSON Web Token (JWT) Profile~
for OAuth 2.0 Client Authentication and Authorization Grants~
https://tools.ietf.org/html/rfc7523
>JWT を [[RFC 7521（上記）>#e7d6a65b]] の アサーション として利用するための仕様
***公開資料 | OpenID ファウンデーション・ジャパン [#n96a7959]
-JSON Web Token (JWT)~
https://openid-foundation-japan.github.io/draft-ietf-oauth-json-web-token-11.ja.html
----
Tags: [[:認証基盤]], [[:クレームベース認証]], [[:暗号化]]
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
