JWTの仕組みを完全理解｜Cognito・STS・公開鍵検証まで図解で解説

WebアプリやモバイルアプリにおけるJWT（JSON Web Token）は、現代の認証基盤を支えるコア技術です。

この記事では、JWTの3パート構造から始まり、OpenID Connect・Amazon Cognito・AWS STSとの関係、公開鍵暗号方式による署名検証の仕組み、そしてサーバーが公開鍵を取得するタイミングまでを体系的に解説します。「なんとなく使っているJWTをちゃんと理解したい」エンジニアの方に最適な内容です。

なぜJWTが必要なのか？

WebアプリやモバイルアプリではユーザーがOKかを確かめる認証が欠かせません。しかしユーザー数が増えるにつれて「毎回データベースを検索して確認する」方式では処理が重くなっていきます。

JWTを使えば、サーバーはデータベースに問い合わせることなく、トークン自体を検証するだけでユーザーを識別できます。これがJWTが広く普及している最大の理由です。

JWTの構造

JWT（JSON Web Token）は3つのパートがドット（.）で区切られた文字列です。RFC 7519として国際標準化されています。

OpenID ConnectとOAuth 2.0

JWTの発行に深く関わる2つのプロトコルを整理します。

つまり OpenID Connect ＝ OAuth 2.0 ＋ 認証 です。Amazon CognitoはこのOIDCに準拠しており、認証後にJWT形式のIDトークンを発行します。

Amazon CognitoとJWT発行の仕組み

Amazon Cognitoはユーザー認証を管理するAWSのサービスです。ログインが成功するとOIDCの仕様に従い、以下の3種類のトークンを発行します。

1. IDトークン（JWT）：「このユーザーは誰か」という身元情報。ユーザーID・メールアドレス・有効期限などが含まれる。
2. アクセストークン：APIを呼び出すための権限証明。
3. リフレッシュトークン：IDトークン・アクセストークンの有効期限が切れた際に再発行するために使う。

CognitoがJWTの署名を作る仕組みは以下のとおりです。

// JWT ヘッダー（デコード後）
{
  "alg": "RS256",   // 署名アルゴリズム（RSA + SHA-256）
  "kid": "abc123"   // この署名に使った秘密鍵のID
}

// 署名の生成イメージ
署名 = RSA秘密鍵で暗号化(
  SHA256( Base64URL(ヘッダー) + "." + Base64URL(ペイロード) )
)

公開鍵暗号方式による署名検証

JWTの署名検証には公開鍵暗号方式が使われます。秘密鍵と公開鍵の役割を理解することが署名検証の核心です。

秘密鍵で作成した署名は、対応する公開鍵でしか検証できません。これにより「この署名はCognitoが作ったもの」と誰でも確認できます。

CognitoはOIDCの標準仕様に従い、公開鍵の一覧を以下のURLで公開しています。

https://cognito-idp.{region}.amazonaws.com/{userPoolId}/.well-known/jwks.json

// レスポンス例（公開鍵の一覧）
{
  "keys": [
    {
      "kid": "abc123",      // JWTヘッダーのkidと照合する
      "kty": "RSA",
      "alg": "RS256",
      "n":   "uBp47VGURf...", // 公開鍵の値
      "e":   "AQAB"
    }
  ]
}

署名検証の仕組みを深掘りする

ヘッダーとペイロードはBase64URLエンコードされているだけで、中身は誰でも読めます（暗号化ではありません）。署名だけが秘密鍵で暗号化されています。署名検証は以下の2経路で行われます。

受け取ったJWT
┌───────────────────────────────────────┐
│ヘッダー  │  ペイロード  │  署名         │
└───────────────────────────────────────┘
      │              │         │
      └──────┬────────┘         │
             ↓                  ↓
  SHA-256でハッシュ化      公開鍵で復号（kidで特定した公開鍵を使用）
             ↓                  ↓
       ハッシュ値B         ハッシュ値A
             │                  │
             └────── 比較 ───────┘
                      ↓
           A === B → ✅ 検証成功（本物＆改ざんなし）
           A ≠ B   → ❌ 改ざんあり or 偽造トークン

この検証で証明できることは以下の2点です。

• Cognitoが発行した本物のJWT：秘密鍵を持つCognitoだけが正しい署名を作れるため
• ヘッダー・ペイロードが改ざんされていない：改ざんするとハッシュ値Bが変わりAと一致しなくなるため

なお、JWTには「一度発行したトークンは有効期限が来るまで無効化できない」という弱点があります。主な対策は以下のとおりです。

• 有効期限を短くする（15分〜1時間程度）← 推奨
• リフレッシュトークンで再発行する仕組みを用意する ← 推奨
• ブラックリスト管理（DBに登録して弾く）← DBアクセスが復活するためトレードオフあり

AWS STSと一時クレデンシャル

AWS STS（Security Token Service）は、AWSリソースへのアクセスに必要な一時的な認証情報（クレデンシャル）を発行するサービスです。

CognitoのJWTからSTSクレデンシャルを得るまでの流れは以下のとおりです。

1. ユーザーがCognitoでログイン → CognitoがJWT（IDトークン）を発行してアプリに返す
2. アプリがSTSのAPI（AssumeRoleWithWebIdentity）を呼び出す
3. STSがCognitoのJWKSエンドポイントから公開鍵を取得してJWTを検証する（Cognitoへの直接問い合わせは不要）
4. STSが一時クレデンシャルを返す
5. アプリが一時クレデンシャルでAWSリソースにアクセス（有効期限が切れたら②から再実行）

aws sts assume-role-with-web-identity 
  --role-arn arn:aws:iam::123456789:role/MyAppRole 
  --web-identity-token <CognitoのIDトークン> 
  --role-session-name MySession

// STSから返される一時クレデンシャル
{
  "AccessKeyId":     "ASIAIOSFODNN7EXAMPLE",
  "SecretAccessKey": "wJalrXUtnFEMI/...",
  "SessionToken":    "AQoDYXdzE...",
  "Expiration":      "2026-04-17T13:00:00Z"  // 有効期限（例：1時間）
}

WebアプリでのJWT送受信と検証

通常のWebアプリでも同じ公開鍵検証の仕組みが使われます。クライアントは一般的にHTTPの Authorizationヘッダーにトークンを含めて送信します。

GET /api/profile HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
               ↑ "Bearer"＝「このトークンを持参した人に権限を与えてください」

サーバー側でのJWT検証は以下のステップで行います。

1. AuthorizationヘッダーからJWTを取り出す
2. JWTをヘッダー・ペイロード・署名に分割する
3. ヘッダーのkidで対応する公開鍵を特定する
4. 公開鍵で署名を検証する（改ざん検出）
5. ペイロードのクレームを検証する
6. すべてOKならリクエストを処理する

ステップ5で確認すべきクレームは以下のとおりです。

サーバーはいつ公開鍵を取得するのか

JWTが届くたびにJWKSエンドポイントへアクセスしていたらネットワーク通信が大量に発生します。実際には3つのパターンがあります。

鍵ローテーションとは、Cognitoが使用する秘密鍵を定期的に切り替えることです。kidが変わるため、キャッシュに存在しない場合は再取得が必要になります。

// 鍵の更新前
Cognito: kid="abc" の秘密鍵でJWTに署名 → アプリに発行

// 鍵の更新後（ローテーション）
Cognito: kid="xyz" の秘密鍵でJWTに署名 → アプリに発行
         ↑ kidが変わる！キャッシュに"xyz"がなければ再取得が必要

JWKSエンドポイントのレスポンスには通常 Cache-Control ヘッダーが含まれます。

Cache-Control: public, max-age=3600
                            ↑ 1時間キャッシュを推奨（例）

まとめ

参考リソース

• RFC 7519 — JSON Web Token (JWT) — JWTの公式標準仕様
• OpenID Connect Core 1.0 — OpenID Connectの公式仕様
• Amazon Cognito 公式ドキュメント — JWTの検証
• AWS STS 公式ドキュメント — AssumeRoleWithWebIdentity
• JWT.IO — JSON Web Token入門