結果はどうやって計算されるの?
ログからIDトークンを読む
サービスのアクセスログに、RFC 7515の例のようなトークンがあります — HS256を宣言するヘッダー、subject・名前・発行時刻を含むペイロード、そして署名セグメント。サーバーと同じようにクレームを読むためにデコードし、次に共有シークレットを貼り付けて署名が本当に一致するか確認します — 改ざんされたsubや期限切れのiatは「署名は無効」として表示されます。
入力と出力の例 | 入力 | 値 |
| トークン | eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c |
| HMACシークレット(任意) | your-256-bit-secret |
| 結果 | {"sub":"1234567890","name":"John Doe","iat":1516239022} — 署名は有効 |
計算式と前提は?
JWTコンパクトシリアライゼーション
JWT = base64url(ヘッダー) + "." + base64url(ペイロード) + "." + base64url(署名)
計算式の記号 | 記号 | 意味 |
ヘッダー | JSONヘッダー:alg、typ、多くの場合はkid — 署名アルゴリズムとキーID |
ペイロード | JSONクレーム:登録済み(sub、iat、exp、nbf、iss、aud)に加えカスタムクレーム |
base64url | URL安全文字(-と_)を使いパディングなしのbase64 |
RFC 7519 §3.1。ツールはセグメントをbase64urlでデコードしてJSONを整形します。クレームを並べ替えたり解釈したりすることはありません。
HMAC署名検証
有効 = verify(HMAC-{SHA-256|384|512}(シークレット), base64url(header.payload), 署名)
計算式の記号 | 記号 | 意味 |
シークレット | 貼り付ける共有HMACシークレット — ブラウザ内でのみ使用され、送信はされません |
base64url(header.payload) | 署名入力:トークンが運ぶままの最初の2セグメント |
署名 | 3番目のセグメントで、生のMACバイトにデコードされたもの |
crypto.subtle.verifyは定数時間の比較を行うため、不一致がタイミングで漏れることはありません。非対称アルゴリズムは署名者の公開鍵が必要で、ローカルでは検証不可と報告されます。
よくある間違いは?
- デコードできるからトークンを信頼する — デコードはクレームを見せるだけで、誰が署名したかは示しません。発信元を証明できるのは有効な署名検証だけで、しかも正しいシークレットを使ったHMACトークンに限られます。
- alg=noneのトークンは「デコードしても無害」と思い込む — これらは署名なしであり、受け入れるライブラリはすべて拒否すべきです。
- 本番トークンをアップロードするオンラインデコーダーに貼り付ける — このツールは完全にローカルです。多くのWebサービスはあなたのトークンとクレームを保存します。
前提と制限は?
- 署名検証はHMAC(HS256/384/512)のみ対応 — 非対称トークンは「ローカルでは検証不可」と報告されます。
- クレームは生のまま表示されます(exp/iat/nbfはepoch秒)。変換は行いません。
- 不透明なアクセストークンはJWTではないためデコードできません。
数値の出典は?
最終確認 2026年8月12日 · バージョン 1.0.0 · Toolivaro 外部コンテンツを保証するものではありません。
よくある質問
トークンはどこかにアップロードされますか?
いいえ。デコードと署名検証はWebCryptoを使って完全にブラウザ内で実行されます — トークンやシークレットを使ったネットワークリクエストは一切行われません。実在のユーザークレームを持つ本番トークンにも安全です。
なぜRS256トークンを検証できないのですか?
RS256や他の非対称ファミリーは署名者の公開鍵で検証しますが、その鍵は発行者のJWKSエンドポイントにあります — クライアント側ツールがあなたの代わりにその鍵を安全に取得し信頼することはできません。デコーダーは結果を偽装する代わりに、そのようなトークンを「ローカルでは検証不可」と報告します。HMAC(HS256/384/512)トークンは共有シークレットだけで済むため、シークレットを提供すれば検証されます。
トークンがalg=noneの場合はどういう意味ですか?
alg=noneは、トークンがまったく署名されていないことを宣言しています。noneを受け入れるライブラリは、悪名高い認証バイパスの原因です。デコーダーはそのようなトークンを「保護なし」としてフラグ付けし、検証すべき署名セグメントもありません。
なぜexpやiatが生の数値で表示されるのですか?
トークンがそのように運ぶからです — RFC 7519によるNumericDateのepoch秒。ツールはクレームを黙って変換も解釈もしません。静かな変換こそデコーダーが嘘をつく場所であり、生の値こそサーバーが見る真実です。
OAuth 2.0のアクセストークンもデコードできますか?
JWTである場合に限ります。多くのプロバイダー(Okta、Auth0、Azure AD)はJWTアクセストークンを発行しており、それらはここでデコードできます。不透明トークン — 単なる識別子であるランダム文字列 — は中にJSONがなくJWTではありません。どんなデコーダーもそれをクレームにはできません。
このコレクションの一部 パスワード・ハッシュ・セキュリティツール
間違いを見つけましたか? 報告する — すべての修正を確認します.
Toolivaro編集チームが当社の方法論に基づいてレビュー済み 計算方法 · 編集方針