JWTジェネレーター

署名済みのJSON Web Tokenを作る

更新日：2026年9月24日 · 著者：サマン

トークンの作業はたいてい「読むこと」で、それはJWTデコーダーの仕事です。ときにはその逆、まだ存在しないトークンが必要になります。何もかも拒否するステージングAPI、いま書いているミドルウェア、5分で切れてほしいテスト用データ——どれも自分で中身を決められるトークンを必要とし、このページがそれに署名します。

ページはトークンを作るタブで開きます。アルゴリズムのメニューも、ペイロードも、鍵も、すべてcrypto.subtle.signを使ってあなたのブラウザーが組み立てて署名します。サーバーへのリクエストはどの段階でも発生しないので、貼り付けた鍵はそのタブと同じだけ private です。

ヘッダーとペイロードに最終的に入るもの

ヘッダーは自動で書かれます。選んだアルゴリズムとtyp: "JWT"、そして欄を埋めた場合はkidです。鍵IDが効いてくるのは、受け取る側が複数の鍵を持っていて名前で選ぶときです。空のままならヘッダーは2項目で収まります。

ペイロードはあなたのものです。ただし2つのクレームは違います。署名のたびにiatには現在時刻が押され、expは有効期間のメニュー——5分、1時間、1日、30日、あるいは無し——から決まります。トークンが出ると、ペイロード欄は実際に署名された内容で書き換わるので、表示されている時刻がそのまま中身です。この2つのクレームこそ試したい点なら、有効期限チェッカーがサーバー側の読み方を説明しています。

アルゴリズムを選ぶ

12種類は2つの系統に分かれます。違いは強さではなく、誰が鍵を持たなければならないかです。

既定がHS256なのは、たいていそれが試されているからです。環境変数の中のシークレット、そして両端に1つのサービス。トークンを確認する側が複数になった瞬間、公開鍵方式のほうが形として適します。検証する側に、トークンを発行できるものを預けずに済むからです。

生成したトークンに何ができて、何ができないか

ここで署名したトークンは本物です。上のデコーダーに貼り付け、同じ鍵で検証を押せば署名は通ります。ライブラリと同じ計算をしているからです。テスト用データにも、期限切れやまだ有効でないトークンで不具合を再現するのにも、ミドルウェアがaudを本当に検証しているのか、ただ読んでいるだけなのかを確かめるのにも使えます。

一方、これは侵入経路ではありません。トークンを受け入れるのは対応する鍵を持つサービスだけなので、自分のシークレットで署名しても他人には何も証明できません。署名とはそういうものであり、だからこそトークンとセッションクッキーの違いは「誰が何を保存するか」に行き着きます。

鍵と形式、そしてそこから生まれるエラー

HS系ではシークレットをそのまま貼り付けます。設定がBase64で保存している場合はシークレットは Base64 にチェックを入れてください。同じ文字列でも、そのままと復号後ではまったく違う署名になります。片方では通り、もう片方では失敗する典型的な原因です。

RS・PS・ESでは、ブラウザーはPKCS#8のPEM——-----BEGIN PRIVATE KEY-----で始まるブロック——か、鍵セットが配るJSON形式のJWKを受け取ります。古い-----BEGIN RSA PRIVATE KEY-----のブロックはPKCS#1なので、先に変換が必要です。誤って公開鍵を貼った場合も、意味の分からないエラーで落ちる代わりにその旨を伝えます。公開鍵は署名を確認できても、作ることはできないからです。