API認証の仕組みを図にした。Basicが暗号化ではない、という話

• HTTPは前を覚えていないので、毎回いちから名乗り直す
• Basicの変換は暗号化ではない。誰でも元に戻せる
• 別のドメインへ転送されるとき、資格情報は取り除かれる

APIを使うとき、鍵やトークンを header に入れる。あれが何をしているのかを図にした。

断られてから、名乗り直す

標準的な流れはこうなっている。

MDNの説明では、資格情報なしで保護されたリソースを要求すると、サーバーは401で応答し、WWW-Authenticate ヘッダーを返す。ここにアクセスに使える認証方式が示される。

クライアントは、対応している中からもっとも安全な方式を選び、Authorization ヘッダーに資格情報を載せて再送する。

書式は共通

Authorization: <方式> <資格情報>

方式の名前は大文字小文字を区別しないとされている。

Basicは暗号化していない

ここが最も誤解されやすい。Basic認証の手順はこうだ。

1. 利用者名とパスワードをコロンでつなぐ
2. それをBase64で変換する
3. ヘッダーに載せる

MDNは警告として、はっきりこう書いている。

Base64エンコードは簡単に元に戻すことができ、元の名前とパスワードを取得することができます。そのため、Basic認証には暗号化セキュリティがありません。

つまり変換であって、保護ではない。見た目が意味不明な文字列になるので安全そうに見えるが、戻す手順は公開されている。

だからHTTPSが前提になる

MDNは、認証を使う際には常にHTTPSを勧めるとしたうえで、Basicを使う場合は特にその必要性が強くなると書いている。

暗号化されていない通信でBasicを使うと、パスワードをほぼそのまま流しているのと変わらない。

方式ごとの違い

Bearerの利点は、パスワードを流さずに済むことと、怪しければその1本だけ無効にできることにある。パスワードだと、漏れたときに変更の影響が全体に及ぶ。

「持っている人が使える」という性質

Bearerは、トークンを持っていること自体が資格になる。誰が持っているかは問わないので、漏れたらそのまま使われる。

そのため、置き場所の決まりが要る。

• コードに直接書かない
• 公開する場所に置かない
• 有効期限を設ける
• 用途ごとに分けて発行する（1本止めても他が止まらない）

見落としやすい挙動

MDNに明記されている性質がある。オリジンを跨ぐリダイレクトでは、Authorization ヘッダーは取り除かれる。

つまり別のドメインに転送されたとき、資格情報は転送先に渡らない。意図した挙動で、転送先に資格情報が漏れないための仕組みになっている。

実務では、これが「転送を挟んだ途端に401になる」原因になる。転送先に直接送る形に直す必要がある。

401と403の違い

• 401 … 名乗っていない、または名乗りが通らない
• 403 … 名乗りは通ったが、そのことをする権限が無い

401なら資格情報の問題、403なら権限設定の問題になる。直す場所が違う。

自分で作る側になるとき

認証を実装する側では、通す判定と権限の判定を分ける必要がある。名乗りが通ったことと、その操作をしてよいことは別だ。

WordPressでも同じ構造になっていて、送信元の確認と権限の確認は別の関数で行う。この話は入力欄の検査を頼むとき、画面側だけでは足りないと知ったに書いた。

APIに渡してよい情報の線引きは仕事でAIを使うとき、入力してよい情報の線を決めたにまとめてある。

まとめ

• HTTPは前を覚えていないので、リクエストごとに資格情報を添える
• 401と WWW-Authenticate で方式が示され、Authorization で名乗り直す
• Basicの変換は暗号化ではない。HTTPSが前提になる
• Bearerは持っている人が使える。期限と用途を分ける
• 別ドメインへの転送では資格情報は取り除かれる
• 401は資格情報の問題、403は権限の問題

出典

• MDN「Authorization」（書式、Basicの手順と警告、WWW-Authenticateとの関係、オリジン間リダイレクトでの扱い）
• MDN「HTTP の概要」（ステートレス性）

図は本記事のために作成したもの。認証の実装は仕様の確認が要るので、各サービスの公式ドキュメントに当たること。本記事は2026年10月13日時点の内容に基づく。