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

ひよこ

ログインしたあとに「トークン」ってもらうらしいけど、あれって何なの？

ペンギン先生

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

ひよこ

文字列の中に情報が入ってるの？見た目はランダムな文字の羅列に見えるけど…

ペンギン先生

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

ひよこ

えっ、ユーザー情報がそのまま入ってるの？それって危なくないの？

ペンギン先生

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

ひよこ

じゃあ署名（Signature）のほうは何をしてるの？

ペンギン先生

署名は「このトークンは改ざんされていません」を保証する部分だよ。たとえばHS256なら、サーバーだけが知っている秘密鍵（Secret）を使って、HeaderとPayloadからHMAC-SHA256という署名を計算するんだ。もし誰かがPayloadの中身を書き換えたら、署名と一致しなくなるから「これは偽物だ」とすぐバレる仕組みだね。RS256のように、秘密鍵で署名して公開鍵で検証する方式もあるよ。

ひよこ

なるほど！でも、昔ながらのセッションIDとは何が違うの？

ペンギン先生

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

ひよこ

トークンに有効期限があるって言ってたけど、期限が切れたらどうなるの？

ペンギン先生

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

ひよこ

セキュリティで気をつけることって他にもあるの？

ペンギン先生

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

ひよこ

OAuth2っていうのとJWTは関係あるの？

ペンギン先生

OAuth2は「認可の仕組み」で、JWTは「トークンのフォーマット」だよ。OAuth 2.0自体はアクセストークンの形式を決めていなくて、JWT形式にする実装もあれば、意味のないランダムな文字列にして、サーバー側で照合する実装もあるんだ。JWT形式のアクセストークンの書き方はRFC 9068で標準化されているよ。「〇〇でサインイン」のようなログインでは、OAuth 2.0を土台にしたOpenID Connectが使われていて、本人確認の結果を伝える「IDトークン」がJWTと決められているんだ。つまり、OAuth2が「どうやって権限を委譲するか」を決めて、JWTが「その証明書をどういう形で渡すか」の選択肢の1つになっている関係だね。

ひよこ

JWTって万能に見えるけど、デメリットもあるのかな？

ペンギン先生

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

補足

この記事の図は、最もよく見かける署名付きJWT（JWS）とHS256の例です。ライブラリを選ぶときは、検証するアルゴリズムを固定し、有効期限（exp）だけでなく、発行者（iss）や宛先（aud）の確認が必要かも仕様とライブラリの説明で確認してください。

参考資料

確認日：2026年9月21日。

• RFC 7519：JSON Web Token (JWT) — ドット区切りのbase64url構造、署名（JWS）または暗号化（JWE）、expの扱い、alg noneのUnsecured JWT。
• RFC 8725：JSON Web Token Best Current Practices — アルゴリズムの許可リスト、noneの扱い、HMACに人間が覚えるパスワードを直接使わないこと、iss・audの検証。
• RFC 9068：JWT Profile for OAuth 2.0 Access Tokens — OAuth 2.0がアクセストークンの形式を定めていないこと、JWT形式の標準プロファイル。
• OpenID Connect Core 1.0 — IDトークンはJWT、アクセストークンの形式は規定しないこと。