JWTとは｜JSON Web Tokenの仕組み・構造・署名と検証をやさしく解説

Webサービスにログインしたあと、開発者ツールで「eyJ...」から始まる長い文字列を見かけたことはないでしょうか。あるいは、APIを叩くときに「Authorization: Bearer eyJ...」というヘッダーを付ける、という説明を読んだことがあるかもしれません。この「eyJ」で始まる文字列の正体が、本記事のテーマであるJWT（JSON Web Token）です。JWTとは何か、どんな構造を持ち、なぜ安全に使えるのか、そして欠かせない注意点までを順を追って解説します。

JWTとは何か

JWT（ジョットと読みます）は「JSON Web Token」の略で、当事者間で情報を安全にやり取りするための、コンパクトで自己完結したトークンの標準形式です。RFC 7519という仕様で定義されています。「自己完結している」とは、トークンそのものの中に「誰が」「いつまで有効か」といった必要な情報が含まれている、という意味です。

もっとも代表的な用途は認証・認可です。利用者がログインに成功すると、サーバーはそのユーザーを表すJWTを発行します。以降、利用者（ブラウザやアプリ）はリクエストのたびにこのJWTを送り、サーバーは受け取ったJWTを検証することで「このリクエストは確かにログイン済みのユーザーからのものだ」と判断できます。毎回データベースに問い合わせなくても本人性を確認できる点が特徴です。

JWTは意味不明な文字列に見えますが、暗号で内容を隠しているわけではなく、「発行者が作り、改ざんされていない」ことを保証する仕組みです。

JWTの3部構造：header.payload.signature

JWTは、ピリオド（.）で区切られた3つの部分から成り立っています。実際のトークンは「xxxxx.yyyyy.zzzzz」のような形をしており、それぞれ次の役割を持ちます。

• ヘッダー（Header）：トークンの「種類」と「署名に使うアルゴリズム」を示します。たとえば「typはJWT」「algはHS256」といった情報がJSONで書かれています。
• ペイロード（Payload）：実際に伝えたいデータ本体です。ユーザーIDや権限、有効期限などが「クレーム」と呼ばれる名前と値のペアでJSONとして格納されます。
• 署名（Signature）：ヘッダーとペイロードが改ざんされていないことを保証するための値で、発行者だけが作れる仕組みになっています。

つまりJWTは、「メタ情報（ヘッダー）」「中身（ペイロード）」「改ざん防止の封印（署名）」の3点セットだと考えると分かりやすいでしょう。

Base64URLエンコードと「中身が読める」こと

ヘッダーとペイロードは元はJSONですが、そのままではURLやHTTPヘッダーに含めにくい文字が混じる可能性があります。そこで、これらをBase64URLという方式で文字列に変換してからピリオドで連結します。「eyJ」という共通の出だしは、JSONが必ず波括弧で始まり、それをBase64URLにすると「eyJ」になることに由来します。

ここで非常に重要なのは、Base64URLは暗号ではなく、ただのエンコード（表現方法の変換）にすぎないという点です。鍵がなくても誰でも元のJSONに戻せます。つまり、JWTのヘッダーとペイロードの中身は、トークンを手に入れた人なら誰でも読めてしまうのです。手元のJWTの内容は、JWTデコーダーに貼り付けるとヘッダーとペイロードが整形されて表示されます。Base64URLそのものの変換はBase64変換ツールで文字列をエンコード・デコードして体感できます。

では、読めてしまうのになぜ安全なのか。その答えが、次に説明する署名です。

署名と検証の仕組み

3つ目の署名こそが、JWTの安全性を支える心臓部です。署名は、ヘッダーとペイロード（Base64URLにしたもの）をまとめ、発行者だけが知っている秘密の鍵を使って計算した値です。代表的な方式に、共通鍵で計算するHMAC（HS256など）や、秘密鍵と公開鍵のペアを使うRSA・ECDSA（RS256など）があります。

受け取ったサーバーは、同じヘッダーとペイロードから自分でも署名を計算し直し、トークンに付いてきた署名と一致するかを確かめます。一致すれば、「正しい鍵を持つ発行者が作ったもので、ヘッダーもペイロードも改ざんされていない」と判断できます。誰かがペイロードのユーザーIDや権限を勝手に書き換えれば署名が合わなくなり、すぐに不正だと分かります。

ここで大切なのは、署名は「中身を隠す」ためではなく「改ざんを検知する」ためのものだということです。中身は誰でも読めますが、鍵を持たない第三者は正しい署名を作れないため、内容を書き換えて辻褄を合わせることができません。これが「読めるのに安全」というJWTの本質です。

署名＝改ざん検知のための封印。秘密にするのは「中身」ではなく「鍵」。

有効期限（exp）とよく使うクレーム

ペイロードに格納される名前と値のペアをクレーム（claim）と呼びます。仕様であらかじめ意味が決められている代表的なクレームには、次のようなものがあります。

とくに重要なのがexp（有効期限）です。JWTは一度発行すると内容だけで検証が完結します。裏を返せば、流出したトークンも有効期限内なら悪用されうるということです。そこで有効期限を短め（数分〜数時間）に設定し、切れたら再発行する運用が一般的です。これらの時刻はUNIX時刻（1970年1月1日からの経過秒数）で表されることが多く、デコードして人が読める日時に直すと確認しやすくなります。

クレームには、これら標準のものに加えて、アプリが独自に決めた情報（役割や表示名など）を自由に含められます。ただし何を入れるかには、次に述べる注意が必要です。

用途と注意点：機密情報を入れない

JWTは便利ですが、性質を誤解すると思わぬ事故につながります。安全に使うために、次の点を押さえておきましょう。

• ペイロードに機密情報を入れない：ペイロードは鍵がなくても誰でもデコードして読めます。パスワードやクレジットカード番号などの秘匿すべき情報を入れてはいけません。署名は改ざんを防ぐだけで、内容を隠してはくれません。
• 必ず署名を検証する：受け取ったJWTは、サーバー側で署名を検証してから信頼します。とくに、ヘッダーのalgを「none（署名なし）」に書き換える古典的な攻撃や、想定外のアルゴリズムを受け入れる実装ミスに注意が必要です。
• 有効期限を適切に設定する：expを設定し、トークンが漏れても被害を時間で限定します。長期のログイン維持には、別途リフレッシュトークンなどを併用します。
• 必ずHTTPSで送受信する：トークンが盗聴されればなりすましが可能になります。通信は必ず暗号化しましょう。

まとめると、JWTは「ヘッダー・ペイロード・署名」の3部構造を持ち、Base64URLで表された中身は誰でも読めるものの、鍵による署名で改ざんを検知できるのが本質です。だからこそ「中身は秘密にできない」「鍵と有効期限の管理が要」という前提を理解して使うことが大切です。実際のトークンのクレームはJWTデコーダーで確認し、エンコードの仕組みはBase64変換ツールで試すと、より深く理解できるでしょう。

なお本記事は一般的な情報の提供を目的としたものです。認証・認可の実装は安全性に直結するため、実際に採用する際は、最新の公式仕様（RFC 7519など）や信頼できるライブラリのドキュメント、専門家の情報を確認し、用途に適した方法を選択してください。