Chiroru's Diary

日々の学びをちょこちょこメモしていきます

HTTPの認証と機能(キャッシュ/パイプライン化)

Rails 勉強会 HTTP

7/11(土)にRailsGirls Shiojiri Moreに参加しました！
今回は『Webを支える技術』の9.8~9.12の部分を読んだので、そのまとめを書いていきます。

【目次】

HTTP認証

主流のHTTP認証方式として、Basic認証・Digest認証があります。またWebAPIでは、拡張機能であるWSSE認証を利用することもあります。

これらの認証機能は、アクセス制御がかかったリソースに、まずクライアントがアクセスをし、サーバーが「ステータスコード401」と必要な認証情報がわかる「WWW-Authenticateヘッダ」を含んだレスポンスを返すことで区別が可能となります。

これより、クライアントはその方式に従った認証情報を送ることができます。

Basic

ユーザー名とPWを利用する認証方式です。

リクエストごとにAuthorizationヘッダに、平文から暗号化したユーザー名とPWの2つを入れて送信しますが、この平文から暗号化された文字列は容易に元に戻すことができてしまうので、HTTPS通信の利用など、対応を考えなければいけません。

Digest

Basicと比べ、PWがハッシュ関数を適用して暗号化される、よりセキュアな認証方式です。

WWW-Authenticateヘッダの値(チャレンジ)には、リクエストごとに変化するnonce(number of used)、ダイジェストの作成方法を決めるqop(quality of protection)、推測不可能なopaqueが含まれます。

ちなみにqopにはauthとauth-initの２種類があり、

  • 「auth」はメソッド＋URI
  • 「auth-init」はメソッド＋URI＋メッセージボディ

がダイジェストの作成に利用されます。

Basicと同じくユーザー名は平文からの暗号化なので、こちらの対応策もまたHTTPS通信の利用となります。

あまり普及していない・・

みたいです。この理由は、リクエストの度に401レスポンスを得なければならず、クライアントにとって操作が煩雑となること、またwebサーバーによって認証がオプション扱いされており、サポートされてない可能性があるためです。

一方Basic認証は

同じURI空間のリソースであれば、一度の認証のみで後は自動で認証情報が送信されます。

WSSE

Basic認証とDigest認証の中間のような認証方法です。
HTTP1.1の標準外の認証方式でWebAPIの認証に使用されます。

クライアントはAuthenticationヘッダにWSSE、profile値、PWダイジェスト、nonce、日時を含めてリクエストを送信します。

PWをネットワーク状に流さない反面、生のPWをサーバーに置いておく必要があります。

認証と認可

認証は「誰(何)であるか」がポイントなのに対し、認可は「権限があるか」がポイントととなります。

認証(authentication)

基本的に以下の3つのうち一つを満たしていればOKです。

  1. WHAT YOU ARE (inherence factor)
    顔貌、指紋、署名など、その人自身を提示して、相手にアイデンティティを確認させる方法

  2. WHAT YOU HAVE (possession factor)
    身分証などその人だけが持っているものを提示する方法

  3. WHAT YOU KNOW (knowledge factor)
    パスワード、秘密の質問等、その人だけが知っていることを提示する方法

認可(authorization)

ある特定の条件に対して、リソースアクセスの権限を与えることです。

自分が誰であろうと、権限を持っていることによってリソースアクセスが許可されます。

参考：よくわかる認証と認可

HTTPの機能

キャッシュ

サーバーから得たリソースデータをローカルストレージに一定期間保存しておき、期間内の再アクセス時に再利用する仕組みのことです。

こうすることで、同じデータを表示させる時に、前回より速く表示が可能となります。

サーバーから取得したリソースのヘッダに含まれる以下の3種類から、キャッシュの可否、またその期間がわかります。

  • Pragma:no-cache：キャッシュ不可
  • Expires：キャッシュ有効期間(max1年の指定を推奨)
  • Cache-Control：より細かい指定が可能

条件付きGET

キャッシュが使えるか検証する仕組みのことです。

  • If-Modifide-Since：リソースの更新日時を確認
  • If-None-Match：指定した値にマッチしていないかを確認

サーバー側を実装する際は、より正確に更新確認ができるIf-None-MatchでEtag(リソースの更新状態を比較できる文字列)ヘッダの利用が推奨されています。

パイプライン化

クライアントとサーバー間でのリクエストとレスポンスのやり取りを持続させ、レスポンスを待たずしてリクエストを送ることができます。

接続を切断するには、Connectionヘッダに値closeを指定します。

感想・まとめ

Railsには便利なgemがあるので、これまで認証機能の中身についてあまり考えることがなかったなぁと読みながら考えていました。
また現在では、二段階認証や多要素認証などの方式もあるのでそれらの勉強も改めて必要そうです。
その際には『Real World HTTP』という参考書を紹介していただいたので、また読んでみたいと思いました！