無料JWTデコーダー

JSON Web Token の簡単な歴史

JSON Web Token（JWT）は 2015年5月に Michael B. Jones（Microsoft）、John Bradley（Ping Identity）、Nat Sakimura（NRI）によって IETF の JOSE ワーキンググループのもとで RFC 7519 として標準化されました。これは半世代の作業の集大成でした：最初の JWT インターネットドラフトは 2010年12月に登場し、SAML 2.0（2005）の重い XML ベースのアサーション形式と、ブラウザがネイティブに解析できるもっと軽量なものへの感じられたニーズから生まれました。突破口は XML より JSON を、PEM より base64url を選んだことでした：JWT は URL クエリ文字列や Authorization: Bearer ヘッダーに収まりました。JOSE ファミリー全体は調整されたセットとして出荷されました：署名のための RFC 7515（JWS）、暗号化のための RFC 7516（JWE）、鍵フォーマットのための RFC 7517（JWK）、アルゴリズム識別子のための RFC 7518（JWA）、クレーム層のための RFC 7519（JWT）、すべて 2015 年 5 月の同じ日に。採用は瞬時でした。OAuth 2.0（RFC 6749、2012）はアクセストークンを標準化していましたが、その形式を不透明のままにしていました；業界は JWT を選びました。OpenID Connect（2014年12月、OpenID Foundation）は ID トークンに JWT を必須としました。2017 年までに、すべての主要なアイデンティティプロバイダー（Auth0、Okta、Azure AD、AWS Cognito、Google Identity、Firebase Auth）はネイティブのセッション形式として JWT を発行していました。JWT.io、Auth0 が 2014 年にローンチしたデコーダーウェブサイトは、事実上の JWT デバッグツールとなり、開発者のマインドシェアにおいてフォーマットを定着させるのに役立ちました。2 つのセキュリティインシデントが現代の脅威モデルを形作りました：Tim McLean の 2015 年の開示による alg: none バイパスと HS/RS アルゴリズム混乱攻撃、そして CVE-2022-21449（2022年4月）、Neil Madden による Java 15-18 の ECDSA 検証ツールの「Psychic Signatures」バグ。両方ともライブラリのデフォルトの強化につながりました：ほとんどの現代のライブラリは現在、alg: none を即座に拒否し、トークンのヘッダーから読み取るのではなく期待されるアルゴリズムをピン留めします。

JWT の構造

• 3 つの base64url エンコードされたセグメント。JWT は文字列 header.payload.signature：ドットで区切られた 3 つのセグメント、それぞれ base64url エンコードされています。RFC 7519 はこれを JWT Compact Serialization と呼びます。全体が URL や HTTP ヘッダーに収まります；そのコンパクトさが JWT を SAML のような XML ベースの先駆者から区別した設計目標でした。
• ヘッダー。通常 2 つのフィールドを含む小さな JSON オブジェクト：alg（署名アルゴリズム、例：HS256、RS256、ES256）と typ（ほぼ常に「JWT」）。オプションのフィールドには kid（鍵のローテーションに使用される鍵識別子）と cty（ネストされたトークンのコンテンツタイプ）が含まれます。ヘッダーは検証者に署名を検証する方法を伝えます；それを単独で信頼しないでください、常にサーバー側で期待されるアルゴリズムをピン留めしてください。
• ペイロード。クレームの JSON オブジェクト、サブジェクトに関するキー値アサーション。RFC 7519 §4.1 は 7 つの標準クレームを予約しています：iss（発行者）、sub（サブジェクト）、aud（オーディエンス）、exp（有効期限）、nbf（以前ではない）、iat（発行時刻）、jti（一意の JWT ID）。発行者は自由にカスタムクレームを追加します。ペイロードは署名されていますが暗号化されていません：トークンを持っている人は誰でもそれを読むことができます。
• 署名。ヘッダーとペイロードが改ざんされていないという暗号学的証明。署名入力はリテラル文字列 base64url(header) + "." + base64url(payload)；署名自体は次に第 3 セグメントとして base64url エンコードされます。検証には対称シークレット（HS*）または非対称公開鍵（RS*、ES*、PS*、EdDSA）が必要で、常に信頼できるサーバー上で発生する必要があります。
• base64url、base64 ではない。JWT セグメントは RFC 4648 §5 からの URL セーフな base64 バリアントを使用します：文字 62 は + ではなく -、文字 63 は / ではなく _、末尾の = パディングは削除されます。JavaScript の組み込み atob() は標準 base64 のみを処理するので、JWT デコーダーは復号する前にアルファベットを翻訳し、再パッドします。
• NumericDate：秒、ミリ秒ではない。RFC 7519 は exp、nbf、iat を「1970-01-01T00:00:00Z UTC からの秒数」として定義します。JavaScript の Date.now() はミリ秒を返すので、一般的なバグは 3 桁大きすぎる exp で、53,000 年頃に「期限切れ」になるトークンを生成します。トークンを発行するときは常に Math.floor(Date.now() / 1000) を使用してください。

実際の JWT の使用場所

• OAuth 2.0 アクセストークン。RFC 6749 はアクセストークン形式を不透明のままにしましたが、実際には業界は JWT で標準化しました。Auth0、Okta、Azure AD、AWS Cognito、Google Identity はすべてデフォルトで JWT アクセストークンを発行します。Authorization ヘッダーの Bearer トークンはほぼ常に JWT です。
• OpenID Connect ID トークン。OIDC（2014年12月）は id_token に対して JWT を義務付けています。id_token は認証されたユーザーに関するアイデンティティクレーム（sub、email、name、picture）を運び、転送されるのではなくリライアントパーティによって消費されます。これは「Google でサインイン」、「Apple でサインイン」、および同等のフローの背後にある主要なメカニズムです。
• API 認証。ステートレスな REST API は JWT を採用します。なぜなら、これはサーバー側のセッションストアの必要性を取り除くからです：API は署名が検証するものを信頼します。Stripe スタイルの API キーはサーバー間トラフィックでは一般的なままですが、ユーザースコープの API では、Authorization: Bearer <jwt> パターンが現在のデフォルトです。
• マイクロサービス間認証。API エッジで発行されたユーザースコープの JWT は、内部のサービス間呼び出しを通じて転送され、各サービスが再認証なしで元の認証を信頼できるようになります。このパターンは時々「トークン翻訳」と呼ばれます：エッジゲートウェイは不透明なセッションをダウンストリーム呼び出しにスコープされた短命の JWT と交換します。
• シングルページアプリケーションセッション。SPA（React、Vue、Angular）は歴史的に便宜上アクセストークンを localStorage に保存していました。現代のガイダンス（OWASP、Auth0）は、アクセストークンをメモリに、リフレッシュトークンを HttpOnly + Secure + SameSite=Strict クッキーに保持することです。なぜなら、localStorage はページに着陸する任意の XSS によって読み取り可能だからです。
• モバイルアプリセッション。iOS と Android アプリはアクセストークンをプラットフォーム Keychain または Keystore に保存します。トークンは各バックエンド呼び出しで Authorization: Bearer として送信されます。リフレッシュトークンは使用ごとにローテーションされ、アクセストークンの短い exp（通常 5-15 分）は盗まれたデバイスのリプレイに対する主要な防御です。

標準とセキュリティのマイルストーン

• RFC 7519（JWT、2015年5月）。基本仕様。JWT Compact Serialization、7 つの標準登録クレーム（iss、sub、aud、exp、nbf、iat、jti）、NumericDate 形式を定義します。著者：Michael B. Jones、John Bradley、Nat Sakimura。
• RFC 7515（JWS、2015年5月）。JSON Web Signature。ほぼ全員が非公式に「JWT」と呼ぶ署名されたラッパー形式：ドットで結合された 3 つの base64url セグメント。JWS はコンパクト形式と JSON Serialization 形式の両方をサポートします；JWT はコンパクト形式のみを使用します。
• RFC 7516（JWE、2015年5月）。JSON Web Encryption。5 つのセグメント（ヘッダー、暗号化された鍵、IV、暗号文、認証タグ）を持つ暗号化されたバリアント。ペイロードが単に改ざん明らかであるだけでなく機密でなければならない場合は、JWS ではなく JWE を使用してください。
• RFC 7517（JWK、2015年5月）。JSON Web Key。暗号鍵の JSON 表現。JWKS エンドポイント（/.well-known/jwks.json）は JSON Web Key Set を公開します。これはダウンタイムなしの鍵ローテーションのための現代のメカニズムです：検証者は kid で鍵を検索します。
• RFC 7518（JWA、2015年5月）。JSON Web Algorithms。alg 識別子のレジストリ：HS256/384/512（HMAC）、RS256/384/512（RSASSA-PKCS1-v1_5）、ES256/384/512（ECDSA）、PS256/384/512（RSASSA-PSS）、EdDSA（Ed25519/Ed448）、および（意図的にあまり使用されない）none。
• alg: none バイパス（Tim McLean、2015）。RFC 7518 は none を非セキュアコンテキスト用の有効なアルゴリズム値としてリストします。素朴な検証者は、ヘッダーが {"alg":"none"} に書き換えられた空の署名のトークンを受け入れ、攻撃者が任意のペイロードを偽造できるようにしました。現代のライブラリはデフォルトで none を拒否します；仕様自体は検証者が「デフォルトで非セキュア JWS を受け入れてはならない」と述べています。
• HS/RS アルゴリズム混乱攻撃（Tim McLean、2015）。検証者がそれをピン留めする代わりにトークンヘッダーからアルゴリズムを選択する場合、攻撃者はヘッダーを HS256 に書き換え、サーバーの RSA 公開鍵を HMAC シークレットとして使用してトークンに署名できます。ライブラリは HS256 を見て、設定された RSA 公開鍵を対称シークレットとして扱い、署名が確認されます。緩和策：期待されるアルゴリズムを帯域外でピン留めしてください；トークンから派生させないでください。
• CVE-2022-21449「Psychic Signatures」（Neil Madden、2022年4月）。Java 15-18 の ECDSA 検証ツールは、署名の r と s 値が非ゼロであることをチェックせず、これは文字通りすべてがゼロの署名が有効として受け入れられたことを意味します。影響を受ける JVM 上で ES256/384/512 で署名された JWT は、空白の署名で偽造される可能性がありました。Oracle の 2022 年 4 月のクリティカルパッチアップデートでパッチされました。

その他のよくある質問

関連ツール