Basic認証 | Security Atlas

先に読むと理解しやすい記事：HTTP・HTTPS / 認証・認可

ユーザー名とパスワードをヘッダーで送る

Basic認証は、HTTPのAuthorizationヘッダーでユーザー名とパスワードを送る方式です。サーバーが組を確認し、認証が必要なページへのアクセスを受け付けるか決めます。

たとえば確認用ページで、ブラウザが入力ダイアログを表示する構成があります。入力した情報をブラウザが保持し、対象となる後のリクエストにもヘッダーを付ける場合があります。

認証情報のないリクエストへ、サーバーは401とWWW-Authenticate: Basicを返せます。realmは保護領域を示す文字列です。ブラウザはこれを見て入力を求めることがあります。

クライアントはユーザー名、コロン、パスワードを連結し、Base64に変換してBasicの後ろに付けます。次の値は説明用のalice:testを変換したものです。サーバーは復元した情報を検証します。

復元後は最初のコロンを区切りとして、前をユーザー名、後をパスワードとして扱います。そのためユーザー名にはコロンを含められません。非ASCII文字の扱いも送受信側の合意が必要で、独自の文字コード処理を加えるより、利用するサーバーの認証機能と仕様を確認します。

説明用の通信例・設定例・擬似コード

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="preview"

// 認証情報を送るリクエストのヘッダー
Authorization: Basic YWxpY2U6dGVzdA==

Base64はバイト列を文字で表す方法です。復元に秘密鍵は必要ありません。Authorizationを読める人は、その値を復元してパスワードを得られます。

通信はHTTPSで保護します。それでもサーバーやTLSを終端する配信サービスではヘッダーを扱えるため、アクセスログや調査用ログへ認証情報を出力しないようにします。

フォームログインとセッションIDの方式では、最初のパスワード照合後、後続の通信ではIDを送る構成にできます。Basic認証では、認証情報を送る各リクエストにユーザー名とパスワードの組が含まれます。

Basic認証だけでは、端末ごとの失効、多要素認証、細かな役割管理などはそろいません。必要な機能は別途用意します。ページの保護ができたことと、利用者管理の全体が完成したことを区別します。

全員が同じ情報を使うと、一人の利用だけ止めるために全員の情報を変更する必要が生じます。共通の名前だけでは誰が使ったかも区別できません。個別管理が必要なら、その目的に合う認証基盤を選びます。

ブラウザが資格情報を保持するため、セッションCookieと同じ操作で確実にログアウトできるとは限りません。ブラウザが認証情報を自動送信する文脈ではCSRFも考慮し、更新APIで送信元や操作を検証します。

確認問題：Basic認証のページが呼ぶAPIも自動的に守られるでしょうか。答えは限りません。APIやファイルの公開設定は別に確認します。

自分の環境で、ページ本体、ダウンロードURL、別ホストのAPI、配信サービスを経由しない接続先を確認します。ヘッダーのBase64値もパスワードと同じ秘密として扱います。

未確認事項・限界

通信例・設定例・被害の例は、仕組みを理解するための仮定です。特定の製品で発生した事件を示すものではありません。ブラウザやサービス固有の設定は、利用する環境の公式資料でも確認してください。