Base64・URL エンコード・JWT の解説

エンコードは暗号化ではない

エンコードは、特定の文字しか通さない経路をデータが通れるように、書き方を変えることです。鍵を使わないので、誰でも元に戻せます。暗号化もデータを変えますが、元に戻せるのは鍵を持つ人だけです。ハッシュはさらに別物で、元に戻せない一方向の指紋です。詳しくはハッシュ関数の解説をご覧ください。

Base64 と URL エンコードはエンコードです。JWT は通常署名されていて、誰が発行したかと内容が変更されていないことを証明しますが、内容そのものはエンコードされているだけです。値を秘密にする必要があるなら、これらの形式ではなく暗号化が必要です。

Base64 の仕組み

Base64 はデータを 3 バイト（24 ビット）ずつ読み、6 ビットずつ 4 つのグループに分けます。各グループは 0〜63 の数で、64 文字のアルファベットの 1 文字として書きます。0〜25 は A〜Z、26〜51 は a〜z、52〜61 は 0〜9、その後が + と / です。「Man」という単語で手順を見てみましょう。

入力の長さが 3 の倍数でないときは、最後のグループを埋めてパディングで示します。1 バイト余れば 2 文字と ==、2 バイト余れば 3 文字と = になります。「Ma」は TWE=、「M」は TQ== です。

3 バイトが 4 文字になるため、Base64 はデータを約 3 分の 1 大きくし、形式によっては改行も加わります。メールに添付した 3 MB の写真は約 4 MB のテキストとして送られ、スタイルシートにデータ URL で埋め込んだ画像は元のファイルより約 3 分の 1 重くなります。

Base64 に出会う場所

• メールの添付ファイル（MIME）は、1 行 76 文字で折り返した Base64 テキストです。
• データ URL は data:image/png;base64,iVBORw0… のように、小さなファイルを HTML や CSS に直接埋め込みます。
• HTTP 基本認証は user:password を Base64 にして Authorization ヘッダーで送ります。パスワードを一見して読めなくするだけなので、安全なのは HTTPS 上だけです。
• 証明書と鍵の PEM ファイルは、-----BEGIN …----- と -----END …----- の行の間にある、64 文字で折り返した Base64 です。
• JSON と XML にはバイナリ型がないため、署名やサムネイルなどのバイナリ値を Base64 文字列で持ちます。

Base64URL とパディング

標準 Base64 の + と / は URL やファイルパスで意味を持つため、2 つ目のアルファベットである Base64URL は代わりに - と _ を使います。デコーダーが長さを計算できるので、= のパディングも通常は省きます。JWT、多くの API トークン、一部のファイル名が Base64URL を使います。標準 Base64 を Base64URL にするには、+ を -、/ を _ に置き換え、末尾の = を消します。元に戻すときは置き換えを逆にし、長さが 4 の倍数になるまで = を付け足します。

URL のパーセントエンコード

URL に使える文字は限られていて、そのうちいくつかはアドレスの構造を表します。/ と ? はパスとクエリを分け、& と = はパラメーターを区切り、# はフラグメントの始まりです。値にこれらの文字や ASCII 以外の文字が含まれる場合はパーセントエンコードします。値を UTF-8 にした各バイトを、% の後に 16 進数 2 桁で書く方法です。é は C3 A9 の 2 バイトなので、「café」は caf%C3%A9 になります。

英字、数字、そして - . _ ~ はエンコードの必要がありません。トラブルの原因になりやすい文字は次のとおりです。

値を 1 つずつエンコードしてから URL を組み立てましょう。JavaScript の encodeURIComponent は値 1 つ用で、/ ? & = # もエンコードします。一方 encodeURI はアドレス全体用なので、これらの文字をそのまま残します。値 1 つに encodeURI を使うのは、クエリ文字列が壊れるよくある原因です。

プラス記号、スペース、二重エンコード

HTML フォームはフィールドを application/x-www-form-urlencoded 形式で送り、スペースは + になります。一般的な URL の構文では、+ はただのプラス記号です。そのため「C++」の検索を q=C++ と送ると、フォームデータをデコードするサーバーには「C」の後にスペース 2 つが付いた値として届きます。正しくは q=C%2B%2B と送ります。クエリ文字列を手でデコードするときは、どの規則で作られたかを先に確かめてください。

二重エンコードは、すでにエンコードされた値をもう一度エンコードすると起こります。% 自体が %25 になるので、%20 は %2520 になります。URL に %25 の後に 16 進数 2 桁が続く部分があれば、処理のどこかで 2 回エンコードしています。一度デコードして、余分な手順がどこにあるかを探してください。

JWT の中身

JSON Web Token（JWT）は、ユーザーが誰か、トークンがいつまで有効かといったクレームを、発行するシステムから受け入れるシステムへ運びます。よく使われる署名付きの形式は、ドットで区切られた Base64URL の 3 つの部分、つまりヘッダー、ペイロード、署名からなります。前の 2 つをデコードすると普通の JSON です。

Header:  {"alg": "HS256", "typ": "JWT"}
Payload: {"sub": "user-42", "role": "editor", "iat": 1767225600, "exp": 1767229200}

標準（RFC 7519）はいくつかの登録クレームを定めており、アプリケーションは上の role のように独自のクレームを追加します。

ペイロードはエンコードされているだけなので、トークンを持つ人なら誰でも読めます。個人情報や秘密は入れず、トークンは小さく保ちましょう。トークンはリクエストのたびに送られ、多くのサーバーはリクエストヘッダーのサイズを制限しています。

署名は秘密ではない：JWT の検証方法

署名はヘッダーとペイロードをもとに計算します。HS256 では、発行者と受信者が 1 つの秘密鍵を共有し、SHA-256 による HMAC を使います。RS256 や ES256 では、発行者が秘密鍵で署名し、受信者は対になる公開鍵で確認するため、受信者が自分でトークンを作ることはできません。

トークンを受け取るサーバーは、どのクレームを信用するにも、その前に想定したアルゴリズムと鍵で署名を検証し、exp、nbf、iss、aud を確認する必要があります。LeedyBox のツールのようにデコードするだけでは、これらをすべて省いています。トークンに何が書かれているかはわかりますが、本物かどうかはわかりません。ライブラリは、署名なしのトークンを表す「none」アルゴリズムも拒否しなければなりません。署名なしのトークンを使うと決めている場合を除きます。内容そのものを隠す必要があるときはトークンを暗号化（JWE）し、その場合トークンは 5 つの部分からなり、鍵がなければ読めません。

よくある問題と対処法

よくある質問