ユーザー名とパスワードから HTTP Basic 認証ヘッダーを生成し、そのまま貼れる curl コマンドも出力。既存の Basic トークンを資格情報に戻すデコードにも対応。
HTTP Basic 認証ヘッダーを作成し、既存のものをデコードします。 ユーザー名とパスワードを入力すると、Authorization ヘッダー、生の base64 トークン、そして端末にそのまま貼れる curl コマンドが得られます。下部のデコーダーで既存トークンを逆変換できます。
すべての処理はブラウザ内で行われ、データは送信されません。とはいえ、本ページを含むいかなる Web ページにも本番の資格情報を貼り付けないでください。
RFC 7617 で定義される Basic 認証は、HTTP で最も単純な認証方式です。クライアントはユーザー名とパスワードをコロンで連結し、その結果を base64 でエンコードしてヘッダーに載せます。
Authorization: Basic YWxpY2U6czNjcjN0サーバーが資格情報を要求するときは 401 Unauthorized と WWW-Authenticate: Basic realm="..." を返し、ブラウザがネイティブのログインダイアログを表示します。ハンドシェイクもノンスも有効期限もなく、すべてのリクエストが同じヘッダーを運びます。
これは必ず身体に染み込ませるべき点です。base64 は鍵も秘密も持たない可逆的な転送エンコーディングです。ヘッダーを見た人は誰でも即座にデコードできます。本ページのデコーダーがやっているのはまさにそれです。したがって Basic 認証それ自体の機密性はゼロであり、TLS がリクエスト全体を保護する HTTPS 上でのみ使うべきです。平文 HTTP では、パスワードを平文で送るのと変わりません。
ユーザー名にコロンを含めることはできません。最初のコロンが区切りだからです。パスワードにはいくつ含まれていても構いません。デコーダーは最初のコロンで分割し、残りをすべてパスワードとして扱います。ユーザー名にどうしてもコロンが必要なら、Basic 認証は使えず別の方式が必要です。
初期の仕様は ASCII 外について曖昧で、歴史的に非 ASCII のパスワードがクライアントとサーバーの間で壊れる原因になっていました。RFC 7617 はサーバーが期待を宣言できるよう charset="UTF-8" パラメータを追加し、実務では現代のスタックはすべて UTF-8 を使います。本ツールも base64 の前に UTF-8 バイト列へ変換し、現在のブラウザの挙動に合わせています。
Basic 認証は次の場面では依然として合理的です。内部ネットワークでのマシン間通信、nginx や Apache の背後にあるステージング環境の簡易保護、単純な資格情報が必要な CI ジョブ、そして API キーの運搬手段として（キーをユーザー名欄に入れ、パスワードは空か x のようなプレースホルダーにする）。決済系やメール系の API のいくつかは、まさにこのパターンです。
一方、公開サイトのエンドユーザーログインには不向きです。ログアウトの手段がなく、ブラウザはセッション中ずっと資格情報をキャッシュし、ダイアログのスタイルも変更できず、多要素認証やセッション単位のレート制限も追加できません。
URL に埋め込む資格情報（user:pass@example.com）は非推奨で、履歴・ログ・リファラヘッダーに漏れるため、多くのブラウザがブロックまたは削除します。curl に -u user:pass を渡すのも、シェル履歴とプロセス一覧にパスワードを残すため、同じマシンの他ユーザーから見えてしまいます。-u user だけを指定して curl に入力を促させるか、環境変数から読み込むほうが安全です。