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デコーダーを使用する際は、以下の点にご注意ください。
パスキーはなぜフィッシングに強いのか ― WebAuthn / FIDO2 と公開鍵ログインの仕組み
パスキー(passkey)は、パスワードを保存しないログイン方式です。WebAuthn / FIDO2 の公開鍵認証、チャレンジ署名、origin / RP ID への結びつき、同期パスキーと端末固定キーの違い、復旧設計の注意点を整理します。
Cookie はなぜ壊れやすいのか ― SameSite / Secure / HttpOnly / Partitioned を正しく読む
Cookie の Secure、HttpOnly、SameSite、Partitioned(CHIPS)、__Host- / __Secure- プレフィックスは、それぞれ守る対象が違います。CSRF、XSS、第三者Cookie廃止、埋め込みウィジェットの状態管理まで、Set-Cookie 属性の設計意図を整理します。
SNI はなぜ見えていたのか ― TLS Encrypted ClientHello(ECH)と HTTPS の最後の平文
HTTPSでも、TLSハンドシェイクのSNIは長く平文で送られてきました。2026年にRFC 9849として標準化された TLS Encrypted ClientHello(ECH) が何を隠し、何を隠さないのかを、TLS 1.3、ClientHelloInner/Outer、HTTPS/SVCB DNSレコード、DoHとの関係から整理します。
量子コンピュータで TLS は破られるのか ― ML-KEM / Kyber とポスト量子暗号の実務
NIST は 2024 年に ML-KEM、ML-DSA、SLH-DSA を正式標準化しました。量子コンピュータが RSA / ECC に与える影響、Harvest Now, Decrypt Later、Kyber から ML-KEM への改名、TLS のハイブリッド鍵交換、開発者が今やるべきことを整理します。