JWT(JSON Web Token)

• 特徴
  • コンパクト
    • token という形で URL のクエリパラメーターや POST のパラメーター、HTTP Headerに含む事ができる等、非常に小さいサイズで情報をやり取り可
  • 自己完結
    • 必要な情報を全て、token という形で含めることができる

要素

• Header

  • alg

    • Signature を hash 化する際に利用するアルゴリズムを指定

  • typ

    • token のタイプを指定
    • 通常はJWTで問題ない

  • 例

    {
      "alg": "HS256",
      "typ": "JWT"
    }
    

    • 上記を Base64UrlEncode したものが Header

• Payload

  • サーバサイドとクライアントサイドで共有したい情報

  • Header と同様に key と value で表す

    • 通常このセットをclaimsと呼ぶ
    • claims には既に定義されているものや、独自に claims を設定することができる
    • 既に定義されているものとしては iss, exp 等がある

  • 例

    {
    "iss": "Hoge Publisher",
    "sub": "Hoge User"
    }
    

    • Base64UrlEncode される

• Signature

  • 下記の形式で Header と Playload を Hash 化したものが Signature

    <ハッシュアルゴリズム>(
      base64UrlEncode(header) + "." +
      base64UrlEncode(payload),
      secret)
    

  • サーバサイド側でしか知らない secret key でハッシュ化する為、Header と Payload が例え推測できたとしても、Signature を第三者が生成することが不可能になる

  • サーバサイド側ではクライアントから送られてきた token について Signature を検証することで、その token が正しいものかどうかを判定することができる

• この要素を.で繋ぐことで 1 つの token として扱う

  xxxx[header].yyyy[Payload].zzzz[Signature]
  

  • 最終的に生成される token サンプル

    eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJIb2dlIFB1Ymxpc2hlciIsInN1YiI6IkhvZ2UgVXNlciJ9.zs2WOqs2M-Aah5417-YfoCg6MdUaCsz5qTLCdbO7aEc
    

• 一般的にセッション ID と Cookie を利用した認証のフローイメージ

  • 

• JSON の形で表した情報を URLEncode し、token としてクライアントサイドに送り、認証が完了したクライアントは次回のリクエストからその token を HTTP Header 等に含めてサーバサイドに送る

  • サーバサイド側ではその token について検証し、正しいものであるかを判定
  •