Base64URL エンコードのガイド：リンクと JWT に収まる Base64

標準 Base64 のプラスとスラッシュは URL で意味を持つため、リンクに貼ると壊れます。Base64URL はその置き換えであり、アルゴリズム自体は同じです。

これでなければならない場面

バイナリや JSON をクエリパラメータ、パス、ファイル名、OAuth の state や PKCE の検証値に入れるなら、URL 安全な文字表が必要です。そうしないとプラスは空白として届き、スラッシュはパス区切りとして扱われ、サーバに届く前に壊れます。

代表例が JWT です。ヘッダとペイロードは Base64URL の JSON で、ドットで連結します。署名も同じ文字表なので、Authorization ヘッダにも URL にもそのまま置けます。

UTF-8 のバイト列を Base64 にし、プラスをマイナス、スラッシュをアンダースコアに変え、末尾の等号をすべて削除します。順序を変えたり一部だけ置換すると、戻せない文字列になります。等号を消すのは URL でもエスケープが必要なためです。

サイズは約4/3に増えます。これは Base64 の固定のオーバーヘッドで、ツールが余計なことをしているわけではありません。出力は英数字とマイナス、アンダースコアだけなので、URL に入れても再エンコードは不要です。

Base64URL は暗号ではありません。鍵がなく、誰でも戻せます。JWT のペイロードは「暗号化」ではなく「エンコード」なので、ロールや内部 ID、メールアドレスを入れるのは公開に近い行為です。

署名が保証するのは完全性で、改ざんは検出できますが内容は隠せません。機密性が必要なら JWE やペイロードの暗号化、改ざん検出が必要なら署名です。両者は併用できますが、代替にはなりません。

通常の Base64 との違いは何ですか

プラスをマイナス、スラッシュをアンダースコアにし、末尾の等号を削除する3点だけです。復号時は逆置換してパディングを戻します。中身は同じで、URL に入れるかどうかで選びます。

なぜ等号を削除するのですか

等号はデータを持たないパディングですが、URL ではエスケープが必要で、コピーや連結のときに壊れやすいからです。長さから補う数を推測できるため、往復は無損失です。

JWT の中身は安全ですか

安全ではありません。Base64URL でエンコードされているだけで、トークンを持つ人は全項目を読めます。署名は改ざんされていないことの証明で、秘匿性はありません。