logo
Published on

HTTP認証徹底解説

Authors

はじめに

対象読者は、HTTPで使う認証方法の全体像を把握していないバックエンドエンジニアです。
この記事のゴールは、複数ある認証方法の概要とセキュリティリスクを正確に把握することです。

トークン認証やOAuth、OpenIDなどは、この記事では扱いません。

Table of Contents

BASIC認証

手順は以下です。

  1. クライアント: リクエスト送信
  2. サーバー: 認証が必要であることを伝えるステータスコード401で応答
  3. クライアント: ユーザーIDとパスワードをBase64形式でエンコードしたものを送信
  4. サーバー: 認証成功時にはステータスコード200で応答し、失敗した場合には再度ステータスコード401で応答

以下注意点があるので、多くのWebサイトで求められるセキュリティレベルには足りていないことが多いです。

  • Base64形式のエンコードは暗号化ではないので、HTTPSなどで暗号化されていない通信経路上で盗聴されたら簡単に解読されてしまう
  • 普通のブラウザではログアウトできない

DIGEST認証

手順は以下です。
BASIC認証のようにパスワードを実質平文で送信することはありません。

  1. クライアント: リクエスト送信
  2. サーバー: 認証が必要であることを伝えるステータスコード401で応答するとともに、チャレンジコード（nonce）を送信
  3. クライアント: パスワードとチャレンジコードからレスポンスコードを計算して送信
  4. サーバー: 認証成功時にはステータスコード200で応答し、失敗した場合には再度ステータスコード401で応答

以下注意点があるので、多くのWebサイトで求められるセキュリティレベルには足りていないことが多いです。

  • レスポンスコードを計算する際に使用されるハッシュアルゴリズムMD5は現在では脆弱性が指摘されている
  • なりすましを防ぐ機能は提供されていない

SSLクライアント認証

手順は以下です。
なりすましを防ぐための一つの選択肢で、後述するフォームベース認証と組み合わせて二要素認証の一つとして利用されることが多いです。

  1. サーバー: 認証が必要なリソースへのリクエストがあった場合には、サーバーはクライアントにクライアント証明書を要求する“Certificate Request”というメッセージを送信
  2. ユーザー: 送信するクライアント証明書を選択し、クライアントはクライアント証明書を“Client Certificate”というメッセージで送信
  3. サーバー: クライアント証明書を検証し、検証結果が正しければクライアントの公開鍵を取得

SSLクライアント認証は利用するのにコストが必要です。

フォームベース認証

よくある、フォームにユーザーIDとパスワードを入力してログインするあれです。

一般的には、セッション管理のためにCookieを利用して実装します。
その手順は以下です。

  1. クライアント: 資格情報（ユーザーID、パスワード）を送信
  2. サーバー: ユーザーにセッションIDを発行し、認証状態を記録する。セッションIDをCookieで送信。具体的にはSet-Cookie: SESSID=xxxを送信。
  3. クライアント: 以降のリクエストにCookieを含めて送信。具体的にはCookie: SESSID=xxxを送信。
  4. サーバー: セッションIDを検証することでどのユーザーなのか判断できる。

Cookieのやり取りを安全に行うために、以下のようなHTTPヘッダーを利用することが推奨されます。

  • HttpOnly: JavaScriptからCookieにアクセスできないように制限
  • Secure: HTTPS通信でのみCookieを送信
  • SameSite: CSRFを防ぐために、クライアントからのCookie送信条件を制限

まとめ

  • BASIC認証: 手軽だが、パスワードが平文同様で漏洩しやすく危険。HTTPSが必須。
  • DIGEST認証: BASIC認証よりは安全だが、使われる技術（MD5）が古く、脆弱性がある。
  • SSLクライアント認証: 安全性が高いが、証明書の導入にコストがかかる。二要素認証で利用されることが多い。
  • フォームベース認証: 一般的。Cookieでセッション管理するため、セキュリティ設定が重要になる。

参考文献

Discuss on Twitter • View on GitHub