--- title: "HTTPのBasic認証とDigest認証とは？Authorizationヘッダの違いを整理【SG試験】" description: "HTTPのBasic認証とDigest認証について、401応答、WWW-Authenticate、Authorization、Base64、nonce、HTTPSとの関係を整理し、SG試験で選択肢を切る判断軸を解説します。" last_modified_at: "2026-07-18" canonical_url: "https://stemtazoo.github.io/sg/http-basic-digest-auth/" section: "sg" --- ## まず結論 HTTPの認証機能では、代表的に**Basic認証**と**Digest認証**を切り分けます。 | 認証方式 | クライアントが送る情報 | 判断ポイント | |---|---|---| | Basic認証 | `利用者ID:パスワード`をBase64で表現した文字列 | Base64は暗号化ではない | | Digest認証 | ID、パスワード、nonce、URIなどから作るハッシュ値 | パスワードそのものを送らない | SG試験では、次の3点が重要です。 - Base64ならBasic認証 - nonceを使ったハッシュ値ならDigest認証 - どちらも通信全体を暗号化する仕組みではないため、実務ではHTTPSを使う ## 直感的な説明 Basic認証は、IDとパスワードを書いた紙を、別の文字表現に変えて送るイメージです。 文字の見た目は変わりますが、元へ戻せるため、通信を盗み見られると認証情報も知られるおそれがあります。 Digest認証は、サーバから渡された使い捨てに近い値である**nonce**などを混ぜて、回答用のハッシュ値を作って返すイメージです。 ただし、Digest認証が守る中心は認証情報です。Webページ本文や送受信データ全体を暗号化するわけではありません。 > BasicとDigestの違いは認証情報の送り方、HTTPSは通信路全体の保護です。 ## 定義・仕組み ### HTTP認証の基本的な流れ 1. クライアントが保護されたページへアクセスする 2. サーバが`401 Unauthorized`を返す 3. サーバが`WWW-Authenticate`ヘッダで認証方式を知らせる 4. クライアントが認証情報を`Authorization`ヘッダで送る 5. サーバが確認し、許可または拒否する | ヘッダ・応答 | 送る側 | 役割 | |---|---|---| | `401 Unauthorized` | サーバ | 認証が必要であることを通知する | | `WWW-Authenticate` | サーバ | 利用する認証方式などを示す | | `Authorization` | クライアント | 認証情報を送る | ### Basic認証 Basic認証では、利用者IDとパスワードを次の形でつなげます。 ```text 利用者ID:パスワード ``` この文字列をBase64でエンコードし、Authorizationヘッダに指定します。 ```text Authorization: Basic Base64でエンコードした文字列 ``` Base64は暗号化ではありません。秘密鍵なしで元の文字列へ戻せます。 そのため、Basic認証は**HTTPSと組み合わせて通信路を保護する**ことが重要です。 ### Digest認証 Digest認証では、利用者ID、パスワード、サーバが提示するnonce、HTTPメソッド、URIなどを使ってハッシュ値を作ります。 nonceを使う目的は、過去に盗聴した認証情報をそのまま再送する**リプレイ攻撃**を難しくすることです。 ただし、nonceの管理や実装が不適切なら、十分な対策にならない場合があります。 古い試験問題ではMD5が登場することがありますが、現在の仕様ではSHA-256なども扱われます。 SG試験では、細かいアルゴリズム名よりも、次を優先します。 - Basic：Base64 - Digest：nonceなどを使ったハッシュ値 ### HTTPSとの関係 | 仕組み | 主に守るもの | |---|---| | Basic認証 | 利用者IDとパスワードによる本人確認 | | Digest認証 | パスワードそのものを送らない認証 | | HTTPS | 認証情報を含む通信内容全体 | Basic認証でもHTTPSを使えば、通信途中で認証情報を盗み見られにくくなります。 Digest認証でも、通信本文やCookieなどを守るためにHTTPSが必要です。 ## どんな場面で使う？ ### Basic認証 - 検証環境の簡易なアクセス制限 - Webサーバ設定による管理画面の保護 - 限定公開ページ 簡単に設定できますが、HTTPSなしで使うべきではありません。 ### Digest認証 パスワードそのものを送らない方式として使われてきました。 ただし、現在のWebサービスでは、HTTPS、フォーム認証、セッションCookie、トークン認証、MFAなどを組み合わせる構成が一般的です。 ### フォーム認証との違い フォーム認証では、Web画面の入力フォームからIDとパスワードを送り、認証後はセッションCookieなどでログイン状態を管理します。 Basic認証やDigest認証はHTTP自体の認証方式であり、フォーム認証とは仕組みが違います。 ### MFAとの違い Basic認証やDigest認証は、認証情報の送信方式です。 知識・所持・生体など複数要素を組み合わせるMFAとは別の考え方です。 ## よくある誤解・混同 ### 誤解1：Base64は暗号化である 誤りです。 Base64はデータを扱いやすい文字列へ変換するエンコードです。 ### 誤解2：Digest認証ならHTTPSは不要である 誤りです。 Digest認証はパスワードそのものを送らない方式ですが、通信内容全体を暗号化するわけではありません。 ### 誤解3：Authorizationヘッダはサーバから送る 誤りです。 - サーバ：`WWW-Authenticate` - クライアント：`Authorization` と切り分けます。 ### 誤解4：nonceを使えばすべての攻撃を防げる 誤りです。 nonceは主に認証情報の再利用を難しくしますが、盗聴、改ざん、フィッシング、弱いパスワードなど、すべての問題を解決するものではありません。 ### 誤解5：Basic認証とフォーム認証は同じ 誤りです。 Basic認証はHTTPのAuthorizationヘッダを使います。フォーム認証はWebフォームとセッション管理を使うのが一般的です。 ### SG試験の判断基準 - 「IDとパスワードをコロンで連結しBase64化」→ Basic認証 - 「nonceを使ってハッシュ値を作る」→ Digest認証 - 「認証方式を通知するヘッダ」→ `WWW-Authenticate` - 「クライアントが認証情報を送るヘッダ」→ `Authorization` - 「通信全体を暗号化する」→ HTTPS - 「Digest認証ならHTTPS不要」→ 誤り ## 確認問題（SG試験対策） HTTP認証に関する説明として、最も適切なものはどれか。 - ア. Basic認証ではBase64を使うため、HTTPSを使わなくても認証情報は暗号化される。 - イ. Digest認証ではnonceなどを使ってハッシュ値を作るが、通信全体を暗号化するものではない。 - ウ. Authorizationヘッダはサーバが認証方式を通知するために送る。 - エ. WWW-AuthenticateヘッダはクライアントがIDとパスワードを送るために使う。
▶ クリックして答えと解説を見る（ここを開く） **正解：イ** ### 解説 - ア：不適切。Base64は暗号化ではありません。 - イ：適切。Digest認証は認証情報の送り方を改善しますが、通信全体の保護にはHTTPSが必要です。 - ウ：不適切。Authorizationヘッダはクライアントが認証情報を送るために使います。 - エ：不適切。WWW-Authenticateヘッダはサーバが認証方式を通知するために使います。 👉 判断ポイント **認証情報の作り方と、通信路全体の暗号化を分けて考えます。**
## まとめ（試験直前用） - Basic認証は`ID:パスワード`をBase64で表現する - Digest認証はnonceなどを使ってハッシュ値を作る - Base64は暗号化ではない - `WWW-Authenticate`はサーバ、`Authorization`はクライアント - Digest認証も通信全体を暗号化しない - Basic・Digestのどちらでも実務ではHTTPSを使う - 判断軸は**認証情報の送り方か、通信路全体の保護か**