JWTとは？トークン認証の仕組みとSAMLとの違いをわかりやすく解説

普段私たちが利用しているWebサービスの多くは、ログイン後のやり取りにJWTというトークンの仕組みを使っています。SNSへのログイン、ソーシャルログイン、シングルサインオンなど、意識していなくても裏側でJWTが動いている場面は少なくありません。

この記事では、JWTの基本ルールから署名の仕組み、トークンの構造、アクセス制御での活用方法、SAMLとの比較までを解説します。

この記事で学べること：

• JWTの定義と基本ルール
• JOSE・JWSなど署名・暗号化に関する規格の役割
• ヘッダー・ペイロード・シグネチャーの構造
• 認証・認可におけるJWTの活用例
• SAMLとの違いと使い分け

JWTの仕組みを理解しておくと、「このトークンには何が入っているのか」「なぜ署名が必要なのか」といった疑問に自分で答えられるようになります。認証まわりの設計やトラブル対応の場面で、根拠を持って判断できる力が身につきます。

JWTとは

JWT（JSON Web Token）とは、当事者間でデータをJSON形式で安全に送信するための規格です。コンパクトでURLに含めやすい構造を持ち、主にWebアプリケーションの認証・認可の場面で広く使われています。

たとえば、ユーザーがログインした際に、サーバーがJWTを発行してクライアントに渡し、以降のリクエストではそのトークンを使って本人確認を行う、という流れが代表的です。

https://jwt.io/

JWTの特徴

JWTは、少ない文字数でエンコードされた文字列を送信する際に重宝されています。それを実現しているのが以下の2つです。

• コンパクト

  よく使うデータ項目のキー名を省略形にすることで、データサイズをコンパクトにしています。

• URLセーフ

  JSONデータをBASE64URLエンコードすることで、URLに直接記載できる(URLセーフな)エンコード方式を採用しています。

JWTの主な利用用途

一般的なJWTの利用用途は以下のようなものがあります。

• OAuth 2.0、OpenID Connectなどの認証プロトコルにおけるトークン
• Cookieを使うのが難しいマイクロサービスやモバイルアプリでのセッション管理
• シングルサインオン(SSO)での認証
• RESTful APIの認証
• ステートレス認証

ここで疑問に思うのは、なぜエンコードされただけのJWTが認証に使われるのでしょうか？その理由は、セキュアなデータ転送を実現するJWTのルールにあります。

JWTの構成ルール

JWTには、トークンとして成立するために満たすべき仕様が定められています。

• クレームをJSON形式で表現した文字列
• JOSEに従った署名または暗号化
• Base64URLによるエンコード
• 複数ブロック間の .（ピリオド）区切り

ここからは、各ルールの意味を順に見ていきます。

クレームとは

クレームとは、JWTに含まれるJSONのキーと値のペアのことです。キーをクレーム名、値をクレーム値と呼び、その集合体をクレームセットと呼びます。クレームには、ユーザーIDや権限情報など、認証・認可に必要なデータが記載されます。

以下は、クレームセットの例です。

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

このJSONをBase64URLでエンコードすると、次のような文字列になります。

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

ただし、エンコードしただけでは誰でもデコードして内容を読み取れてしまいます。そこで必要になるのが、署名や暗号化のルールを定めたJOSEです。

JOSEとは

JOSE（JSON Object Signing and Encryption）とは、JWTの署名と暗号化に関するルールを定めた規格です。署名に関するルールをJWS、暗号化に関するルールをJWEと呼びます。 JWTが安全に機能するかどうかは、このJOSEによる署名・暗号化の仕組みに支えられています。実務で特に多く使われるのはJWS（署名）のほうです。

JWSとは

JWS（JSON Web Signature）とは、JWTにデジタル署名を付与する際のルールを定めた規格です。署名を付与することで、トークンの内容が途中で書き換えられていないかを検知できるようになります。

JWTの改ざんとは

JWTの改ざんとは、トークンの内容を不正に書き換える行為のことです。JWT単体はBase64URLでエンコードされただけの文字列なので、デコード→内容の変更→再エンコードという手順で、攻撃者が権限情報を書き換えられるリスクがあります。

このリスクに対処するために、改ざんの検知が必要な場面ではJWSによる署名が使われています。トークンの有効期限を短く設定したり、クレームを適切に設定することも、改ざんリスクの軽減につながります。

JWSのルール

JWSのルールは、ヘッダー・ペイロード・シグネチャーの3つから構成されます。それぞれをBASE64URLエンコーディングした後、ピリオドで結合します。

ヘッダー

JWTの署名に必要な以下の2つの情報を記載する部分です。

• 使用されている署名アルゴリズム (HMAC SHA256 や RSA など)
• トークンの種類 (通常はJWTを指定)

ペイロード

実際のデータ（クレーム）を記載する部分です。主にユーザー情報や有効期限、発行者などを記載します。

シグネチャー

署名を記載する部分です。署名とは、 ヘッダーと ペイロードを結合したあと、暗号化して生成したトークンのことです。

この暗号化された署名と、実際のデータを照らし合わせることで、改ざんが行われたかどうかを検知することができます。

JWSの書き方例

JWSの書き方例をエンコード前後、ピリオドで結合した例です。

JWS準拠のJWTの例（エンコード前）

{
  "alg": "HS256",
  "typ": "JWT"
}

{
  "sub": "1234567890",
  "exp": 1634710708
}

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secretKey
)

JWS準拠のJWTの例（エンコード後）

それぞれをエンコードした後、さらに .(ピリオド) で結合します。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwiZXhwIjoxNjM0NzEwNzA4fQ.
v40uDSCoa14j59CVD0bH-ZqnwYA_XF4aS7QEM_FZ8HM

JWTを利用したアクセス制御

JWSを用いたJWTは、改ざんを検知できるうえに、ユーザー情報やアクセス権限を含むこともできるという利点があります。

これを活かして、アクセス制御を簡素化するためにJWTを使用することが多いようです。

Webサイトでの使用例

Webサイトで認証・認可にJWTを使用した場合、以下のようになります。

1. クライアントがID・パスワードなどの認証情報をサーバーに送信
2. サーバーがDBの情報と照合し、認証に成功すればJWT形式のアクセストークンを発行してレスポンスで返す（認証）
3. クライアントがリソースにアクセスするときは、発行されたアクセストークンを付けてリクエストを送信
4. サーバーがアクセストークン(JWT)を検証し、トークンに含まれる権限に基づいてリソースへのアクセスを許可/拒否する（認可）

このように、JWTのアクセストークンを使用することで、リソースへのアクセス制御が簡単かつ安全に実現できます。

認証プロトコルでの使用例

OpenID ConnectやOAuth 2.0という認証プロトコルでは、トークンの記述方法にJWTを採用しています。

• 例 : OAuth 2.0 Authorization Grants (認可)

    POST /token.oauth2 HTTP/1.1
    Host: as.example.com
    Content-Type: application/x-www-form-urlencoded
  
    grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&
  　assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJpc3Mi[...omitted for brevity...].J9l-ZhwP[...omitted for brevity...]

他にもOAuth 2.0の認証や、OpenID ConnectのIDトークンにも使用されています。

アクセス制御にJWTを使用するメリット

JWTをアクセス制御に使うメリットは、主に認可処理の簡素化にあります。

• ステートレスな認可処理 JWT内にユーザー情報やスコープが含まれているので、サーバー側でセッション管理を実装する必要がなくなる
• 整合性の確保 JWSでデータが改ざんを検知することができる
• 発行者の証明 JWSで署名に発行者の秘密鍵が使用されるので、発行者によるリクエストであると証明できる
• 機密性の確保 JWEと組み合わせることで暗号化もできる

認証処理自体へのメリットは少ないですが、一度認証が済めば、JWTによってユーザー情報やアクセストークンなどを安全にやり取りできるので、それ以降の認可処理が簡素化されるのです。

他の規格との比較

ここで、よく比較対象としてあがるSAMLについても少しだけ理解しておきましょう。

どちらも認証・認可に使用される規格です。

SAML (Security Assertion Markup Language)

• XMLベースのトークンの規格 (※)
• IDプロバイダ(IdP)がトークンを発行するので、セキュリティ面で安心できる
• 有効期限や発行者など必須項目が多く、複数のサービス間で連携しやすい（相互運用性）という点でシングルサインオン(SSO)に特化した設計
• 認証コンテキスト（ユーザーがどんな認証方式で認証されたかという情報）を記載できる

※JSONベースの形式(SAML2.0のJSONプロファイル)もある

JWTとSAMLの比較表

JWTとSAMLのどちらを使うべきか

どちらも認証・認可に使う規格ですが、用途が異なるため適切な規格を選ばなければなりません。

それでもどちらを使用すべきか悩む場合は、以下の項目を参考にしてみてください。

【JWTを使うべきケース】

• アクセストークンの発行を目的とする場合
• ステートレスなアーキテクチャが求められる場合
• モバイルアプリなどクライアント側でトークンを保持する必要がある場合
• データペイロードをコンパクトに保ちたい場合
• 柔軟性が求められ、独自の属性をクレームに含める場合
• シンプルかつ簡単に認証を実装したい場合

【SAMLを使うべきケース】

• シングルサインオン(SSO)の実現を主な目的とする場合
• 統合された認証基盤が必要な場合(IDプロバイダからのトークン発行)
• 認証コンテキストの伝達や、厳密な属性要件がある場合
• XML形式での運用が前提の既存システムとの連携が必要な場合

まとめ

この記事では、JWTの基本的な仕組みから実際の活用場面までを解説しました。

学んだ内容：

この記事の要点は以下の通りです。

• JWTは当事者間でデータをJSON形式で安全に送信するための規格
• クレーム・JOSE・Base64URLエンコードなどのルールで構成
• JWSによるデジタル署名で改ざん検知が可能
• トークンはヘッダー・ペイロード・シグネチャーの3要素で構成
• Webサイトの認証やOAuth/OpenID Connectなどで広く活用
• SAMLと比較してコンパクトで、Web・モバイル環境との相性が良い

なお、JWTは「ジョット」と発音するのが一般的です。文脈によっては「ジェイ・ダブリュー・ティー」や「ジェイソン・ウェブ・トークン」とも呼ばれます。

JWTの全体像を掴んだことで、認証まわりのドキュメントやライブラリのコードを読んだときに「何をしているのか」が見えるようになっているはずです。この理解を土台に、実際にトークンを発行・検証する実装に進んでみてください。手を動かすほど、認証設計への理解がさらに深まっていきます。