まず JWT の読み方は、無理矢理感が半端ないですが「ジョット」と読むらしいです。
七五三を「しめ」と読むぐらいの無理矢理感。。
まぁ、読み方はさておき、JWTとは「JSON Web Token」の略で、簡単に言うと JSON の値に署名をして改ざんを検出できるようにしたフォーマットのことです。
従来の認証で使っている Token の代わりに使われるようです。
今までの Token じゃダメなの？
今までの Token だと、例えばユーザが Token を使ってサーバにアクセスして来た際に、Token を元に DB から情報を探して、ユーザが何者かを調べていました。
この場合、毎回DBへのアクセスが発生し（もちろんキャッシュなどの負荷軽減方法もありますが）サーバのリソースを消費してしまいます。
この Token を JWT に切り替えることによって、サーバでの処理が軽減されるようになります。
なぜなら、JWT の場合はデータの中にユーザが何者かが書いてあるのですから DB の情報をいちいち引くこともありません。
JWTの中に「私のユーザIDは 123456 です」とか、「このJWTの有効期限は XX です」とか、情報が入っているので、サーバではそれを見て処理をすれば良いのです。
悪い人がJWTを勝手に作ったらサーバはだまされる？
JWTの中に「私のユーザIDは XXXXXX です」って書いてあるなら、悪意のある人が「私のユーザIDは 654321 です」と他の人のユーザIDを書き JWT を作ってサーバに送信したら、他の人になりすますことができるのでは？
と思いますが、そうはいきません。署名の登場です。
JWT は JSON に署名を施したデータです。
署名というのは、紙の契約書に人が署名するのと同じで、確かにその人が作成したものですよ、と証明するためのデータです。
署名データを検証することによって、確かに JWT がサーバ側で作られたものだと知ることができます。
第三者が適当に JWT を作成したとしても、サーバ側で署名データを検証することにより「偽物」と判断することができます。
JWT は暗号化ではない
電子署名は暗号化アルゴリズムを利用したものですが、署名を付ける＝データが暗号化される、ということではありません。
通常、署名をつけただけではデータの内容は暗号化されません。
紙の契約書に人がサインしたとしても、その契約書を誰かに渡せば契約書の中身は読めてしまうのと似ています。
署名はデータの中身を隠すためのものではなく、データが改ざんされていない（＝サーバで作られたものである）ことを証明するためのものなのです。
ですので、JWT の中にユーザに見せてはいけない情報は含めないようにしましょう。
JWTデコーダー
作成された JWT は Base64 でエンコードされているので、JWTの文字列を見ただけではどんな JSON なのかわかりません。
手軽にデコードして見たいシーンがあるかと思ったのでデコーダを作ってみました。
JWT デコーダー
https://lab.conocode.com/jwt
