Basic 認証ヘッダー生成ツール

HTTP Basic 認証の仕組み

Basic 認証は RFC 7617 で定義されています。保護されたリソースにアクセスすると、サーバーは 401 Unauthorized と WWW-Authenticate: Basic realm="..." ヘッダーを返します。クライアントはユーザー名とパスワードをコロンでつなぎ、その結果を Base64 でエンコードして、リクエストのたびに送信します。

Authorization: Basic base64(username ":" password)

# RFC 7617 の例：ユーザー "Aladdin"、パスワード "open sesame"
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

ブラウザはこのやり取りを自動で処理し、ログインダイアログを表示します。一方、スクリプトや API クライアントは、チャレンジを待たずに最初のリクエストでヘッダーを送信するのが一般的です。2 つの値はコロンで区切られるため、ユーザー名にコロンを含めることはできません。パスワードには含めてもかまいません。サーバーはチャレンジに charset="UTF-8" を追加して、ASCII 以外の文字を含む認証情報を UTF-8 で送るよう示すことができます。

Base64 は暗号化ではありません

ヘッダーは一見すると意味のない文字列に見えますが、目にした人なら誰でも、このページのデコーダーや任意の Base64 デコーダーを使って数秒でパスワードを復元できます。Basic 認証を使ってよいのは、TLS によって通信中のヘッダーが暗号化される HTTPS 上だけです。また、次の点にも注意してください。

• 認証情報はリクエストのたびに送信されるため、暗号化されていない HTTP リクエストが 1 回あるだけで漏えいします。
• プロキシ、ロードバランサー、デバッグツールは、記録しないよう設定しない限り、Authorization ヘッダーをログに残すことがあります。
• ブラウザは入力された認証情報を閉じるまで記憶しており、ログアウトする標準的な方法はありません。

公開 API には、失効させることができる API トークンや OAuth のほうが適しています。Basic 認証は、社内ツール、ステージングサイト、TLS を介したサーバー間通信では今でも妥当な選択肢です。

コードからヘッダーを送信する

# curl はヘッダーを自動で生成します
curl -u 'user:password' https://api.example.com/

// JavaScript の fetch（btoa は Latin-1 の文字しか扱えません）
fetch(url, { headers: { Authorization: 'Basic ' + btoa('user:password') } })

# Python の requests
requests.get(url, auth=('user', 'password'))

https://user:password@host/ のように URL に認証情報を埋め込むのは避けてください。この形式は RFC 3986 で非推奨とされており、ブラウザの履歴やサーバーのログに残るうえ、最近のブラウザでは制限されています。