【仕組み解説】JWTはどうやってユーザー認証を実現しているのか — トークンの中身を図解

それがまさにJWT（JSON Web Token）だよ。ログインに成功すると、サーバーが「この人は本人確認済みです」という情報をギュッと詰め込んだ文字列を発行するんだ。次回以降のリクエストでは、このトークンを提示するだけで「あ、さっきログインした人だね」と分かる仕組みだよ。

実はJWTは3つのパートがドット（.）で区切られた構造になっているんだ。「Header.Payload.Signature」の3つだね。Headerにはアルゴリズムとトークンのタイプ、Payloadにはユーザー情報や有効期限、Signatureには改ざん検知用の署名が入っているよ。

いい質問だね。HeaderとPayloadはBase64エンコードされているだけで、暗号化はされていないんだ。つまりデコードすれば中身は誰でも読める。だからパスワードやクレジットカード番号のような機密情報は絶対に入れちゃダメだよ。入れるのはユーザーIDや権限レベルなど、読まれても致命的でない情報に限るんだ。

署名は「このトークンは改ざんされていません」を保証する部分だよ。サーバーだけが知っている秘密鍵（Secret）を使って、HeaderとPayloadをハッシュ化して作るんだ。もし誰かがPayloadの中身を書き換えたら、署名と一致しなくなるから「これは偽物だ」とすぐバレる仕組みだね。

一番大きな違いは「ステートレス」かどうかだよ。セッション方式だとサーバー側にセッション情報を保存する必要がある。でもJWTはトークン自体に情報が入っているから、サーバーは何も覚えておかなくていい。だから複数サーバーに分散しやすくて、マイクロサービスやAPI認証でよく使われるんだ。

有効期限（exp）が切れたトークンは拒否されるよ。でも毎回ログインし直すのは面倒だよね。そこで「リフレッシュトークン」という仕組みを併用するんだ。アクセストークンは15分〜1時間くらいの短い有効期限にして、リフレッシュトークンで新しいアクセストークンを発行してもらう。こうすることで、万が一トークンが漏れても被害を最小限にできるよ。

有名な攻撃に「alg none攻撃」というのがあるよ。Headerのアルゴリズムを「none」に書き換えて、署名なしのトークンを受け入れさせるという手口だ。古いライブラリだとこれが通ってしまうことがあったんだ。対策としては、サーバー側で許可するアルゴリズムをホワイトリストで厳格に指定すること。あとは秘密鍵（Secret）の管理も超重要で、漏洩したらすべてのトークンが偽造可能になるから、環境変数で管理してリポジトリには絶対にコミットしないことだね。

OAuth2は「認可の仕組み」で、JWTは「トークンのフォーマット」だよ。OAuth2のアクセストークンとしてJWTが使われることが多いんだ。GoogleやGitHubのログインで「〇〇でサインイン」ってやるとき、裏側ではOAuth2のフローが走って、最終的にJWT形式のトークンが発行されることが多いよ。つまり、OAuth2が「どうやって権限を委譲するか」を決めて、JWTが「その証明書をどういう形で渡すか」を決めている関係だね。

もちろんあるよ。一番のデメリットは「発行済みトークンを無効化しにくい」ことだね。セッション方式ならサーバー側でセッションを消せばログアウトできるけど、JWTは有効期限が来るまで有効なままなんだ。強制ログアウトしたい場合はブラックリスト方式やトークンバージョニングといった追加の仕組みが必要になる。結局、完全にステートレスではなくなってしまうんだね。用途に応じてセッション方式とJWTを使い分けるのがベテランエンジニアの判断力だよ。