マイクロソフト系技術情報 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のアサーションを生成するための仕様
  • JWTには、JWSJWEがある(JWKは違う)。

用途

  • 以下を主張する。
    • メッセージ認証コード(MAC)やデジタル署名で完全性保護されていること(JWS
    • および/または暗号化されていること(JWE
  • 暗号化により、鍵でペイロード(クレームセット)の改ざんチェックが可能(=信頼関係のセマンティクス)。
    この特徴のため、仲介者を伴う(改竄・盗聴の危険性がある)情報のやり取りに利用される。
    • 主に、認証サーバから返されるトークンに使われる。
    • 実際、OAuth 2.0 拡張やOpenID Connectなどで使われている。

構造

構成要素

以下の要素から構成される。

ここの詳細は、RFCを参照。

個別に、

などを参照のこと。

ヘッダ

  • JOSE : JSON Object Signing and Encryptionヘッダ
    • 署名・検証のために利用するもの。
    • 電子署名、MAC に関する情報を保持する。
  • ヘッダの内容は、3 種に分けられている。
  • Registered Header
    • RFC 上で仕様化されているヘッダ内容。
    • 署名に使うアルゴリズムを示す alg
    • 公開鍵の在処を示す jku (JWK Set URL)
  • Public Header
    定義可能だが名前の衝突を避けるために IANA に登録するヘッダ内容。
  • Private Header
    衝突するかもしれないから注意が必要なヘッダ内容。
  • ヘッダ・パラメタ
    • typ(オプション)を設定するなら、
      • "JWT"
      • "JOSE" : JWSJWEのCompact Serialization
      • "JOSE+JSON" : JWSJWEのJSON Serialization
      • "application/"接頭辞を省略したMedia Types
  • cty(オプション)は、構造情報を伝えるために使用される。
  • ヘッダ・パラメタとして複製されたクレーム
    JWEのクレームの一部を復号化前に処理方法を決定する目的で使用する。
  • ヘッダ・パラメタは、JWSJWEで異なる。
  • JWSの場合、alg, typなど。
    { "alg": "HS256", "typ": "JWT"}
  • JWEの場合、alg, encなど。
    {"alg":"RSA-OAEP","enc":"A256GCM"}

ペイロード(クレームセット)

  • 予約済みクレーム
    以下すべて、使用は任意 (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の作成者と利用者の合意のものとで、
      予約済みでもパブリック・クレーム名でもないプライベート・クレーム名を利用可能。
    • ただし、衝突の可能性があるため、慎重に使用する必要がある。
  • サンプル
    {
      "sub": "1234567890",
      "name": "John Doe",
      "admin": true
    }

その他

JWTの種類によって様々。

JWTの種類

JWS

JWE

ネストされたJWT

  • ペイロード(若しくは平文)として、JWSJWEが使用される。
  • 署名と暗号化の両方が必要なネストされたJWTの署名と暗号化の順序は、
    プロデューサがメッセージに署名してから結果を暗号化する(従って、署名を暗号化する)。

無担保JWT

  • JWSでもJWEでもない、プレーンなJWT(無担保JWT)。
  • ヘッダ内のalgはnone = {“alg”: “none”} 。

JWTの作成と検証手順

JWTの作成手順

  • JWSやJWEの手順に従って作成
  • 入れ子になったJWTの場合にはヘッダの”cty”の値に”JWT”を指定

JWS

JWE

JWTの検証(復号)手順

JWSやJWEの手順に従って検証(復号)

JWS

JWE

JWTのアルゴリズム

利用される各アルゴリズムおよびそれらの識別子を定義している仕様

JWS

JWE

ユースケース

認証用途

OpenID ConnectのIDトークン

コチラを参照。

OAuth 2.0のアクセストークン

コチラを参照。

シングルサインオン(SSO)

  • 近年は、SAMLアサーションやJWTアサーション(OpenID ConnectIDトークン
    によって、クレデンシャル伝えて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から確認する。
  • 署名・暗号化は特定用途であれば、1パターン実装すればイイので自作も可能。

ライブラリ

様々なライブラリ(相互運用)

相性がある模様

System.IdentityModel.Tokens.JwtSecurityTokenHandler

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だったりする)。

恐らく、色々なライブラリ間の実装差異で相互運用が難しくなるようなケースがあると思う。
また、マニュアルもほとんどなく、恐らくJWEJWKに対応していないものと思われる。

Microsoft.Owin.Security.Jwt.JwtFormat

以下の2メソッドのインターフェイスを確認すると、
引数・戻り値に、Microsoft.Owin.Security.AuthenticationTicket?が在ったり、
.NET技術と結合度が高く、相互運用には向かないように見える。

検索結果

  • NuGetやWebを検索した所、以下の3ライブラリの利用者が多い。

jose-jwt

Jwt.Net

System.IdentityModel?.Tokens.Jwt

上記の、BCL入りしているJwtSecurityTokenHandlerが含まれる名前空間より
一つ下の階層のJWT系の追加ライブラリを格納する名前空間であるもよう。
※ 名前空間的には、下の階層の方が、上位スタックになるんだなぁ。

必要に応じて、追加でNuGetから取得する必要がある。

自作のJWTライブラリ

以下を考慮して開発可能。

用途

  • 認証など、特定用途の署名・暗号化、検証・復号化レベルであればであれば自作ライブラリで良い。
  • 正しく署名・暗号化できていれば、他のライブラリでも検証・復号化が可能。

相互運用(検証・復号化)

他のライブラリでも検証・復号化が可能かどうかは、
JSON Web Tokens - jwt.ioなどの検証サイトを使用して確認すると良い。

Base64url Enc/Dec

このライブラリも必要になる。

  • 【C#】Base64urlエンコード・デコード - Qiita
    http://qiita.com/hukatama024e/items/b1352cabcd85948511c3

    RFC4648に条件付きでパディング外すなどの難しい処理が
    あるようなので、ライブラリを使用するほうが良いかもしれない
    (Microsoft.Owin.Securityのicrosoft.Owin.Security.DataHandler?.Encoderにライブラリがある)。

脆弱性

実装に脆弱性を作らないように注意する。

ざっくり、

  • alg を "none"に改竄された場合、検証でtrueにするな。
  • alg を "HMAC-SHA*"に改竄された場合、検証でtrueにするな。

ということらしい。

後者は、

  • 公開鍵暗号方式 (RSA / ECDSA) から共通鍵暗号方式 (HMAC) に差し替え、
  • 「公開鍵文字列を共通鍵として利用して」署名を生成することで、

検証でtrueになるJWTを生成できてしまう模様。

特定用途の自作ライブラリであれば、
署名と検証のalgは固定にしておくのも良いと考える。

参考

参考

内部

JWS

JWE

JWK

JWA

RFC

OAuth WG

JOSE WG

jose : Javascript Object Signing and Encryption

OpenID ファウンデーション・ジャパン


Tags: :IT国際標準, :認証基盤, :クレームベース認証, :暗号化


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-11-05 (月) 11:36:57 (42d)