Base64URL デコードのガイド：JWT を読む、ただし信じない

デコードは文字表を戻すだけです。ペイロードに管理者ロールと書いてあっても、そのトークンが正しいとは限りません。検証はサーバでしかできません。

最も多い用途は JWT の中身確認

ログイン処理を調べるとき、中央の区切りを貼るだけで主体、有効期限、スコープを読めます。ペイロードは Base64URL の JSON なので、鍵も通信も不要です。

もう一つはリンクのパラメータです。共有リンク、コールバック URL、計測用パラメータは JSON を Base64URL にしたものが少なくありません。デコードすれば、エンコードされた文字列から推測せずに中身を確認できます。

ツールはマイナスとアンダースコアをプラスとスラッシュに戻し、長さが4の倍数になるよう等号を補ってから復号します。失敗の多くは、文字列の途切れ、URL 由来のパーセントエンコードや中国語の混入、そもそも Base64URL でない入力です。

「文字化けする」場合もあります。バイト列が UTF-8 のテキストではないという意味で、暗号文、圧縮データ、画像が該当します。Base64 はバイトの可逆性だけを保証し、読めることまでは保証しません。

ヘッダには使用アルゴリズムが書いてありますが、その値は攻撃者が決められます。alg に none を指定する古典的な攻撃は、クライアントがその指定を信じることで成立します。検証はサーバで、想定したアルゴリズムと信頼できる鍵で行います。

Base64URL は暗号ではなく、復号に鍵も不要なので、誰でも同じことができます。復号、復号化、検証を混同しないでください。復号は「中身は何か」、検証は「誰が署名し、変わっていないか」に答えます。

文字化けしたらどうすればよいですか

元のバイト列が UTF-8 のテキストではないということです。暗号文、圧縮データ、画像の可能性があります。Base64 はバイトを運ぶだけで、読める形にはしません。用途に合う道具に切り替えてください。

等号は自分で補う必要がありますか

不要です。ツールが長さに応じて補います。手で補う場合は全体が4の倍数になるよう注意してください。数え間違えると、静かに別の内容に復号されます。

JWT の署名を検証できますか

できません。ここは復号だけで、鍵も証明書も扱いません。署名の検証はサーバ側で信頼できる鍵を使って行います。ブラウザで読んだ内容は参考情報です。