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

Basic 認証ヘッダーを生成する手順

1. ユーザー名 と パスワード を入力します。
2. サーバーが ISO-8859-1（Latin-1）を前提とする古いものでない限り、文字コード は UTF-8 のままにします。
3. 結果をコピーします。Authorization: Basic … の行全体なら ヘッダーをコピー、Base64 の部分だけなら トークンのみコピー を使います。
4. すぐ使えるコード の下で URL をエンドポイントに設定し、使うクライアントのコードをコピーします。入れ替え を押すとヘッダーをデコーダーに送り、内容を再確認できます。

ヘッダーの中身

Basic 認証は RFC 7617 で定義されています。クライアントは 2 つの値をコロンでつなぎ、そのバイト列を Base64 エンコードして、1 つのヘッダーで送ります。

最後の 2 行を見ると、文字コードが重要な理由がわかります。同じテキストでもバイト列が変わるので、もう一方のエンコーディングを前提とするサーバーには誤ったパスワードに見えます。UTF-8 を求めるサーバーは、チャレンジで WWW-Authenticate: Basic realm="api", charset="UTF-8" のようにそれを伝えられます。

ここでの Base64 は伝送用の形式にすぎません。ヘッダーをコピーした人は誰でも、Basic 認証デコーダー でパスワードに戻せます。Basic 認証を HTTPS だけで使うべきなのはそのためです。詳しくは Base64 は暗号化ではない をご覧ください。

ツールが警告する文字

• ユーザー名のコロン。 RFC 7617 で禁止されています。サーバーは最初のコロンで分割するので、ユーザー名の一部がパスワードに入ってしまいます。
• 制御文字。 タブや改行などで、Basic 認証の資格情報には使えません。
• Latin-1 にない文字。 その文字コードを選んでいる場合の、絵文字やキリル文字などです。? に置き換えられますが、それで望みどおりになることはまずありません。
• UTF-8 での非 ASCII 文字。 RFC としては正しいのですが、古いサーバーは異なる読み方をすることがあるので、先にテストしてください。

パスワードのコロンは問題ありません。2 つの値を区切るのは最初のコロンだけだからです。

コードから Basic 認証を送る

ツール内のコードは、入力した値を使って生成され、言語ごとに安全にクォートされます。素の形は次のとおりです。

curl -u 'deploy:hunter2' https://api.example.com/

import requests

r = requests.get("https://api.example.com/",
                 auth=("deploy".encode("utf-8"), "hunter2".encode("utf-8")))

Python の例では、あえてバイト列を渡しています。requests は str の値を受け取ると Latin-1 でエンコードするため、€ や ł を含むパスワードは失敗します。バイト列なら、選んだ UTF-8 をそのまま送ります。

ブラウザの JavaScript では、ヘッダーを自分で組み立ててください。fetch は user:pass@ を含む URL を拒否し、btoa() は Latin-1 以外の文字で例外を投げるので、Base64 にする前に文字列を UTF-8 のバイト列にエンコードします。生成される fetch のコードは、完成したトークンを埋め込むことで両方を回避しています。UTF-8 の手順は JavaScript の Base64 ガイド で、Buffer を使う版は Node.js で説明しています。

それでもリクエストが 401 を返すとき

まずレスポンスの WWW-Authenticate ヘッダーを確認してください。Bearer とあれば API はトークンを求めており、Basic 認証の資格情報を受け付けることはありません。Basic とあれば、実際に送ったヘッダー（curl -v なら > Authorization: Basic … と出力されます）をデコードし、期待した内容と比べてください。紛れ込んだ空白や、パスワードマネージャーからコピーした末尾の改行がよくある原因です。プロキシは同じ形式の専用ヘッダー Proxy-Authorization を使います。

よくある質問