LASSIC Media らしくメディア

「アプリやAPIの認証方式を検討する打ち合わせで『JWTを使います』という説明を受けたが、それがどんなものなのか、従来のログインと何が違うのかがつかめない」——IT事業部で開発の提案や設計方針を確認する立場にいると、こうした場面に出会うことがあるのではないでしょうか。JWT（ジョット、ジェイダブリューティー）は、Webサービスやスマートフォンアプリの認証・認可でよく使われる仕組みで、近年の開発では見かける機会の多い用語です。とはいえ画面に現れるものではなく、システムの裏側で使われるため、発注者やPMにとっては実態のつかみにくい領域になりがちでしょう。その考え方を大まかにでも理解しておくと、なぜその方式が選ばれたのか、どんな利点と注意点があるのかを判断しやすくなります。本記事では、特定のライブラリの実装手順ではなく、JWTとはそもそも何を指すのか、どのような構造で、どう使われ、従来のセッション方式と何が違うのかを、発注・運用の視点から順に整理します。用語をすべて覚える必要はありませんが、「情報を守りながら持ち運ぶための、署名付きの引換券」という勘所をつかんでおくと、ベンダーとの会話の解像度が変わってくるはずです。

JWTとは何か

JWT（JSON Web Token）とは、利用者の情報や権限などのデータを、改ざんを検知できる形でひとまとまりにした「トークン（引換券）」の仕組みです。ログインに成功した利用者に対してサーバがこのトークンを発行し、以降のやり取りでは、利用者がそのトークンを提示することで「確かにログイン済みの本人である」と示せます。データそのものに署名が付いているため、途中で内容が書き換えられていないかを、受け取った側が確かめられる点が特徴です。

身近なたとえで言えば、イベント会場で受付を済ませたときに渡される「リストバンド」に近いものと考えると分かりやすいでしょう。一度受付で本人確認を済ませれば、あとはリストバンドを見せるだけで再入場でき、そのたびに身分証を提示し直す必要はありません。JWTも同じように、一度ログインすれば、以降はトークンを提示するだけでよく、毎回パスワードを送る必要がなくなります。しかも、そのリストバンドには偽造を見破るための仕掛け（署名）が施されている、というイメージです。

JWTがよく登場するのは、スマートフォンアプリとサーバのやり取り、複数のサービスをまたぐシングルサインオン、そして外部システムとのAPI連携といった場面です。いずれも、毎回のリクエストで手軽に本人確認をしたい、サーバ側に利用者ごとの状態を持ちたくない、という事情が共通しています。こうした現代的な構成と相性がよいことが、JWTの広まった背景にあります。

ここで押さえておきたいのは、JWTは「暗号化」ではなく「署名」を主眼にした仕組みだという点です。トークンの中身は、特別な鍵がなくても読み取れる形式になっており、秘密を隠すためのものではありません。あくまで「途中で書き換えられていないこと」を保証するのが署名の役割です。この違いは運用上の注意点に直結するため、後の章で改めて触れます。次の図は、JWTがどのような構造になっているかを単純化して示したものです。

JWTの構造 ― 3つの部分

JWTは、ピリオド（.）で区切られた3つの部分から成り立っています。それぞれが異なる役割を持ち、この構造を知っておくと、ベンダーの説明が具体的に理解しやすくなるでしょう。3つの部分を表に整理しました。

ここで重要なのは、ヘッダとペイロードは、特別な鍵がなくても元の内容へ復元できる形式でエンコードされているという点です。つまり、トークンを手にした人はその中身を読めてしまいます。読まれて困る情報、たとえばパスワードやクレジットカード番号のような機密は、ペイロードに入れてはいけない、という原則がここから導かれるのです。一方で署名は、秘密の鍵を持つサーバだけが正しく計算できるため、第三者が中身を書き換えても、署名の検証で食い違いが判明します。「中身は見えるが、書き換えは見抜ける」という性質を、この3部構成が支えているわけです。

実際のJWTは、これら3つの部分がピリオドでつながった、一見ランダムな英数字の長い文字列として現れます。ベンダーから示されるトークンの例が意味不明な文字列に見えても、それはヘッダ・ペイロード・署名がエンコードされて連結されたものだと分かっていれば、戸惑わずに読み解けるでしょう。

JWTはどのように使われるか

JWTを使った認証の流れは、大まかに次のように進みます。要点は、一度ログインした後は、サーバが利用者ごとの状態を覚えておかなくても本人確認ができる、という点にあります。

• 利用者がIDとパスワードでログインする。
• サーバは本人確認に成功すると、利用者の情報や有効期限を入れたJWTを署名付きで発行し、利用者へ渡す。
• 利用者は以降、サーバへリクエストを送るたびに、そのJWTを添えて送る。
• サーバは受け取ったJWTの署名を検証し、改ざんされていないことと有効期限内であることを確かめ、問題なければ処理を実行する。

この流れのポイントは、サーバがトークンの署名を検証するだけで本人確認を完結できるところにあります。誰がログイン中かという情報をサーバ側に保管しておく必要がないため、サーバを複数台に増やしても、どの台がリクエストを受けても同じように検証できるのです。利用者やアクセスが増えてサーバを増強する場面で扱いやすい、という利点につながります。近年、Webサービスやスマートフォンアプリ、システム間の連携でJWTがよく使われるのは、こうした扱いやすさが背景にあると考えられます。

補足すると、JWTは「誰か」を示す認証だけでなく、「何ができるか」という権限（認可）の情報を持たせる用途にも使われます。ペイロードに利用者の役割やアクセス範囲を含めておけば、受け取ったサーバは、その利用者がどの操作を許されているかをトークンだけで判断できます。認証基盤やAPI連携でJWTがよく採用されるのは、本人確認と権限の受け渡しを一つのトークンでまとめられる点も理由の一つです。

セッション方式との違い

JWTと比較されることが多いのが、従来からある「セッション方式」です。両者はどちらもログイン状態を保つための仕組みですが、状態をどこに持つかという点で考え方が異なります。代表的な違いを表に整理しました。

大まかに言えば、セッション方式はサーバが状態を握るぶん、無効化や取り消しを細かく制御しやすい一方、サーバ増設時に保管場所の共有といった手当てが必要になりがちです。JWT方式はサーバが状態を持たないぶん増設に強い反面、いったん発行したトークンを期限前に取り消すのが難しい、という弱点があります。どちらが優れているという関係ではなく、システムの規模や求める制御の細かさに応じて選ぶもので、両者を組み合わせて使う設計も見られます。

なお、JWTの弱点である「取り消しにくさ」を補うために、実務では有効期限の短いアクセス用トークンと、それを再発行するための長めのトークンを使い分ける構成が広く採られます。この組み合わせにより、短い期限で漏えい時のリスクを抑えつつ、利用者が頻繁にログインし直す手間も避けられます。方式の選択は二者択一ではなく、こうした補完策まで含めて設計するものだと捉えておくとよいでしょう。

発注・運用で意識したい観点

JWTは扱いやすい仕組みですが、性質を踏まえずに使うと、思わぬ弱点を抱えることになります。発注や設計方針の会話で押さえておきたい観点を挙げておきます。

第一に、機密情報をペイロードに入れないことです。前述のとおり、ペイロードの中身は読み取れてしまうため、パスワードや個人を特定しうる重要な情報を格納するのは避けるべきです。トークンに入れてよいのは、利用者IDや権限、有効期限といった、読まれても直ちに問題にならない範囲にとどめる、という考え方が基本になります。第二に、有効期限の設計です。JWTは発行後に即座に無効化しにくいため、有効期限を長くしすぎると、万一トークンが漏れたときに悪用され続ける余地が広がります。有効期限は短めに設定し、切れたら再発行する「リフレッシュトークン」という別の仕組みと組み合わせる設計が、よく採られます。

第三に、失効の手立てをあらかじめ用意しておくことです。退職者のアクセスを止めたい、トークンの漏えいが疑われるといった場面に備え、特定のトークンを無効にする仕組み（無効化リストの管理など）を設計に含めておくと、いざというときに対応できます。第四に、通信経路の保護です。トークンは提示するだけで本人として扱われるため、盗まれると成りすましにつながります。通信をHTTPSで暗号化し、トークンの保存場所にも配慮するといった、経路と保管の両面での対策が欠かせません。これらはいずれも、JWTの「便利さ」と表裏の関係にある注意点です。提案を受けた際は、有効期限や失効の扱い、機密を入れない設計になっているかを確認しておくと、方式の妥当性を判断しやすくなります。なお本記事は特定ライブラリの実装手順ではなく、JWTという仕組みの考え方と運用で押さえたい観点に焦点を当てているものです。個別の実装を詰める段階では、採用するフレームワークの公式ドキュメントや、実績のあるベンダーへの確認が別途必要になります。

まとめ

• JWTとは、利用者の情報を署名付きでまとめた「引換券」の仕組みで、ログイン後はトークンの提示で本人確認を行えます。
• ヘッダ・ペイロード・署名の3部構成で、中身は読み取れる一方、署名により改ざんを検知できます。
• ログイン後はサーバが状態を持たずに検証でき、サーバ増設に強いという利点があります。
• サーバに状態を持つセッション方式とは、無効化のしやすさと増設への強さでトレードオフの関係にあります。
• 運用では、機密をペイロードに入れない・有効期限を短くしリフレッシュと併用・失効の手立て・HTTPSでの保護が要点になります。
• 本記事は特定ライブラリの実装手順ではなく、JWTという仕組みの考え方と運用の観点の整理を狙いとしています。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

出典

• IETF「RFC 7519 JSON Web Token (JWT)」
• MDN Web Docs「HTTP 認証」
• OpenID Foundation「How OpenID Connect Works」

Tweet