Basic Auth ジェネレータ

HTTP Basic Authenticationとは？

HTTP Basic Authentication（RFC 7617で定義されています）は、HTTP経由で認証情報を渡す最も簡単な方法です。クライアントはusername:passwordというリテラル文字列を含むAuthorizationヘッダーを送信し、これはBase64でエンコードされています。サーバーはこれをデコードし、アクセスを許可する前に認証情報を検証します。これはブラウザ、curl、Postman、およびほぼすべてのHTTPクライアントとサーバーフレームワークに組み込まれているため、内部API、開発/ステージング環境、シンプルなサービス間認証に今でも一般的です。

使い方

1. ユーザー名とパスワードを入力してください。
2. このツールは即座に認証情報のペアをビルドし、Base64でエンコードし、2つの値を表示します：
   • Authorization ヘッダー — リクエストに貼り付ける準備ができた完全な行：Authorization: Basic <token>。
   • Base64 トークン — username:passwordのエンコードされた部分のみ。すでにBasic を付与してくれるツール向けです。
3. 任意の値をワンクリックでコピーできます。

セキュリティに関する注意事項 — これを読んでください

Base64はエンコーディングであり、暗号化ではありません。 ヘッダーをインターセプトする者（プロキシ、ロギングシステム、ブラウザ拡張機能、同じネットワーク上のユーザー）は、1ステップでそれをプレーンテキストのユーザー名とパスワードにデコードしてしまいます。Basic Authが本当の保護を提供するのは、接続全体がHTTPS/TLSである場合だけです。プレーンHTTP経由でBasic Authヘッダーを送信してはいけません。また、トークン自体が保護する価値のあるシークレットだと思わないでください。パスワードをプレーンテキストで送信するのと全く同じように扱ってください。

簡単な内部ツーリングを超えた用途の場合は、すべてのリクエストで生の認証情報の公開を避けるために設計されたスキーム（APIキー、OAuth 2.0ベアラートークン、署名されたリクエストヘッダーなど）を検討してください（API Signature Generatorを参照してください）。

よくある質問

Base64トークンは暗号化と同じですか？ いいえ。Base64デコーディングは鍵やシークレットを必要としません。これは可逆的なテキストエンコーディングであり、暗号化変換ではありません。

curlでこれを使えますか？ はい、ただしcurl -u username:passwordは自動的に同じヘッダーをビルドしてくれます。このツールは主に、Postman、APIクライアント設定、.httpファイル、またはドキュメント用のRawヘッダー値が必要な場合に有用です。

ユーザー名またはパスワードにコロン（:）が含まれている場合はどうなりますか？ RFC 7617に従い、最初のコロンのみがユーザー名とパスワードを区切ります。パスワード内のコロンは問題なく、サーバー側でデコードされた後もパスワードの一部のままです。ユーザー名内のコロンはスキームではサポートされていません。

これは非ASCII文字を処理しますか？ はい。認証情報はBase64エンコーディングの前にUTF-8でエンコードされ、userid:passwordペア用にRFC 7617が推奨するUTF-8文字セットと一致します。

プライバシー

すべてがブラウザ内でローカルに行われます。ユーザー名とパスワードは、このツールによってサーバーに送信されることはありません。結果のヘッダーで何をするか（例えば、HTTPS経由で独自のAPIに送信する場合など）は、もちろんあなた次第です。