JWTデコーダー・ジェネレーター
JWTのデコード(Header・Payload・署名表示・有効期限判定)に加え、HS256/HS384/HS512 でのJWT生成にも対応。すべてブラウザ内処理。
JWTのデコード(Header・Payload・署名表示・有効期限判定)に加え、HS256/HS384/HS512 でのJWT生成にも対応。すべてブラウザ内処理。
JWT(JSON Web Token)は、RFC 7519で定義されたトークン形式で、主にWeb認証・認可で使われます。コンパクトでURLセーフな形式で、JSON形式のクレーム(情報)を安全に転送できます。
JWTはOAuth 2.0、OpenID Connect、APIの認証トークンなどで広く利用されています。Firebase Auth、Auth0、AWS Cognitoなどの認証サービスもJWTを発行します。
JWTはドット(.)で区切られた3つのBase64urlエンコード済みパートで構成されます。
{"alg":"HS256","typ":"JWT"}形式: xxxxx.yyyyy.zzzzz(ヘッダー.ペイロード.署名)
本ツールはJWTトークンをクライアントサイド(ブラウザ内)でデコードします。サーバーへのデータ送信は一切行いません。
注意: 署名の検証は行いません。署名検証には秘密鍵または公開鍵が必要であり、ブラウザ上での安全な検証には適さないためです。
JWTペイロードには「クレーム」と呼ばれるキーバリューペアが含まれます。RFC 7519で定義された登録済みクレームは以下の通りです。
これら以外にも、アプリケーション固有のカスタムクレーム(name, email, roleなど)を自由に追加できます。
JWTデコーダーを使用する際は、以下の点にご注意ください。
HTTP ステータスコードの設計思想 — RFC 9110 の 5 クラス分類と歴史的コードの運命
HTTP ステータスコードはなぜ 3 桁なのか、なぜ先頭の数字でクラス分類されるのか。HTTP/0.9 (1991) にはステータスコードが存在せず、RFC 1945 (1996) で初めて定義されました。RFC 9110 (2022) で再整理された現在の体系を一次資料で辿り、418 I'm a teapot や 451 Fahrenheit、25 年間 reserved のままの 402 など、個性的なコードの物語も紹介します。
Base64 と Base64URL の違い — RFC 4648 で押さえる3つの落とし穴
Base64 は RFC 4648 で定義される標準エンコーディングですが、URL やファイル名で使うには「+/」「=」に関する罠があります。標準形と URL-safe 形の違いを仕様レベルで整理します。
JWTの exp / iat / nbf — 実務で引っかかる時刻検証の落とし穴
JWTの時刻クレーム(exp, iat, nbf)は仕様上シンプルですが、本番運用では「時計ずれ」「iatを信頼しすぎる罠」など複数の落とし穴があります。実装のベストプラクティスをまとめます。