[Back-end] JWT


JWT(JSON Web Token)


JWTはJSON Web Tokenの略で、電子署名のURL-SafeのJSONです.
JWTは、JSONデータ構造で属性情報を表すタグであり、RFC 7519規格である.
JWTがサーバとクライアントとの間で情報を交換する場合、Http要求ヘッダにJSONトークンを追加し、サーバはヘッダに含まれるJWT情報を検証し、認証を必要としない
JWTは、HMACアルゴリズムを使用して、秘密鍵またはRSAの公開鍵/秘密鍵ペアに署名することができる.

JWT構造


リンク
内容
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJ2ZWxvcGVydC5jb20iLCJleHAiOiIxNDg1MjcwMDAwMDAwIiwiaHR0cHM6Ly92ZWxvcGVydC5jb20vand0X2NsYWltcy9pc19hZG1pbiI6dHJ1ZSwidXNlcklkIjoiMTEwMjgzNzM3MjcxMDIiLCJ1c2VybmFtZSI6InZlbG9wZXJ0In0.WE5fMufM0NDSVGJ8cAolXGkyB5RmYwCto1pQwDIqo2w

JWTは、Header、Payload、およびSignatureの詳細から構成される.
JSON形式の各部はBase 64符号化で表される.
それぞれの部分をつなぐために区切り記号で区切ります.
また、Base 64は暗号化文字列ではなく、同じ文字列に対して常に同じ符号化文字列を返す.

見出し(見出し)


トークンヘッダはtypeとalgの2つの情報からなる.
algは暗号化ヘッダ(Header)ではなく、信号を復号するためのアルゴリズムを指定する.
  • 型:トークンのタイプを指定します.(JWTと同様)
  • alg:アルゴリズム方式は、指定、署名、およびトークン検証に使用される.(HS 256(SHA 256)またはRSA)
  • Payload(ペイロード)


    トークンペイロードには、トークンで使用される情報フラグメントクレームが含まれています.
    クレームは3種類に分けられ、JSON形式で複数の情報を入れることができます.

    登録済みクレーム


    登録されたクレームは、決定されたすべてのタイプのデータを選択的に使用して最大の情報を表現することを推奨します.
    JWTを簡潔にするために、Keyは長さ3のStringです.ここでsubjectは唯一の値を使用し,主にユーザ電子メールを使用する.
    iss:トークン発行者(発行者)
    sub:タグタイトル(subject)
    aud:トークンターゲット(観客)
    exp:タグの有効期限(expiration)は、NumericDate形式で表示する必要があります.ex) 1480849147370
    nbf:トークンのアクティブ化日(not before)で、この日までのトークンはアクティブ化されません.
    iat:トークン発行時間(at発行)、トークン発行後の経過時間がわかります.
    jti:JWTトークン識別子(JWTID)は、重複を防止するために用いられ、1回限りトークン(Access Token)などに用いられる.

    公開クレーム


    公開クレームは、情報を公開するためのカスタムクレームです.
    衝突を防ぐためにURI形式を使用します.
    예시
    
    { 
    "https://velog.io/@ragi": true 
    }

    専用クレーム


    専用クレームは、サーバとクライアントの間に指定した情報を格納するカスタムクレームです.
    예시
    
    { 
    "token_type": access 
    }
    

    に署名


    署名は、トークンを符号化または検証する際に使用される唯一のパスワードです.
    署名は、上記で作成したヘッダとペイロードの値をそれぞれBASE 64に符号化する.
    秘密鍵を使用して、エンコードされた値をタイトルに定義されたアルゴリズムにハッシュします.
    この値をBASE 64生成に再符号化します.

    JWTトークンの例



    このようにして生成されたトークンは、HTTP通信時に認証鍵の値として用いられる.
    通常、valueの前にBeareを付けます.
    { 
    "Authorization": "Bearer {생성된 토큰 값}", 
    }

    JWTの注意事項


    JWTの欠点

  • Self-contained:トークン自体に情報が含まれており、両刃の剣になることができます.
    トークン長:トークンのペイロード(Payload)に3種類のクレームが格納されているため、情報が多ければ多いほどトークンの長さが長くなり、ネットワークに負荷がかかる可能性があります.
  • Payload符号化:Payload自体は暗号化ではなくBASE 64で符号化されている.中间にPayloadを取って復号してデータを见ることができて、JWEを使って暗号化してあるいはPayloadの中で重要なデータを入れるべきでありません.
  • Stateless:JWTはステータスを保存せず、作成すると制御できません.つまり、トークンを勝手に削除することはできないので、トークンの有効期限を付けなければなりません.
  • Tore Token:Tokenはクライアントによって管理される必要があるため、Tokenを保存する必要がある.
  • JWTの使用状況


  • 会員認証
    これはJWTを使用する最も一般的なケースです.
    ユーザーがログインすると、サーバはユーザー情報に基づくトークンを発行します.
    ユーザーがログインしているかどうかを気にする必要はありません.ユーザーがリクエストを発行したときにトークンをチェックするだけで、セッションを管理する必要はありません.サーバのリソースとコストを節約できます.

  • 情報交換
    JWTは2つのオブジェクト間で安定して情報を交換する良い方法である.
    情報は署名されているので,送信者が変更したか,途中で改ざんされていないかを検証することができる.
  • 参考資料


    https://velopert.com/2389
    http://www.opennaru.com/opennaru-blog/jwt-json-web-token/
    https://mangkyu.tistory.com/56