最終更新日：2026年7月18日

sg sg-technology access_control network crypto_auth

まず結論

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とパスワードを次の形でつなげます。

利用者ID:パスワード

この文字列をBase64でエンコードし、Authorizationヘッダに指定します。

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を使う
  • 判断軸は認証情報の送り方か、通信路全体の保護か

© 2024-2026 stemtazoo. All rights reserved.