Hypertext Transfer Protocol (HTTP/1.1): Authentication

Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
Request for Comments: 7235                                         Adobe
Obsoletes: 2616                                          J. Reschke, Ed.
Updates: 2617                                                 greenbytes
Category: Standards Track                                      June 2014
ISSN: 2070-1721

Abstract

Hypertext Transfer Protocol (HTTP) は、分散型で協調的なハイパーメディア情報システムのための、ステートレスなアプリケーション層プロトコルである。本書は、HTTP 認証フレームワークを定義する。

Status of This Memo

本書は Internet Standards Track 文書である。

本書は Internet Engineering Task Force (IETF) の成果物である。IETF コミュニティの合意を反映している。本書は公開レビューを受け、Internet Engineering Steering Group (IESG) により出版が承認された。Internet Standards に関する追加情報は RFC 5741 の Section 2 にある。

本書の現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc7235 から入手できる。

Copyright Notice

Copyright (c) 2014 IETF Trust および文書の著者として識別される者。All rights reserved.

本書は、本書の出版日時点で有効な BCP 78 および IETF Trust の「IETF Documents に関する法的規定」(http://trustee.ietf.org/license-info) の適用を受ける。これらの文書には、本書に関するあなたの権利と制約が記載されているため、注意深く確認してほしい。本書から抽出された Code Components には、Trust Legal Provisions の Section 4.e に記載のとおり Simplified BSD License の本文を含めなければならず、Simplified BSD License に記載のとおり、いかなる保証もなく提供される。

本書には、2008 年 11 月 10 日より前に公開された、あるいは一般に利用可能となった IETF Documents または IETF Contributions に由来する資料が含まれる場合がある。これらの資料の一部について著作権を管理する者が、IETF Standards Process の外で当該資料に修正を加えることを IETF Trust が許可する権利を付与していない可能性がある。当該資料の著作権を管理する者から適切なライセンスを取得しない限り、本書は IETF Standards Process の外で修正してはならず、また IETF Standards Process の外で派生著作物を作成してはならない。ただし、RFC として公開するための体裁整形、または英語以外の言語への翻訳は例外とする。

Table of Contents

• Hypertext Transfer Protocol (HTTP/1.1): Authentication
  • Abstract
  • Status of This Memo
  • Copyright Notice
  • Table of Contents
  • 1. Introduction
    • 1.1. Conformance and Error Handling
    • 1.2. Syntax Notation
  • 2. Access Authentication Framework
    • 2.1. Challenge and Response
    • 2.2. Protection Space (Realm)
  • 3. Status Code Definitions
    • 3.1. 401 Unauthorized
    • 3.2. 407 Proxy Authentication Required
  • 4. Header Field Definitions
    • 4.1. WWW-Authenticate
    • 4.2. Authorization
    • 4.3. Proxy-Authenticate
    • 4.4. Proxy-Authorization
  • 5. IANA Considerations
    • 5.1. Authentication Scheme Registry
      • 5.1.1. Procedure
      • 5.1.2. Considerations for New Authentication Schemes
    • 5.2. Status Code Registration
    • 5.3. Header Field Registration
  • 6. Security Considerations
    • 6.1. Confidentiality of Credentials
    • 6.2. Authentication Credentials and Idle Clients
    • 6.3. Protection Spaces
  • 7. Acknowledgments
  • 8. References
    • 8.1. Normative References
    • 8.2. Informative References
  • Appendix A. Changes from RFCs 2616 and 2617
  • Appendix B. Imported ABNF
  • Appendix C. Collected ABNF
  • Index
    • 4
    • A
    • C
    • G
    • P
    • R
    • W
  • Authors' Addresses

1. Introduction

HTTP は、拡張可能なチャレンジ・レスポンス方式の認証スキーム群を通じて、アクセス制御および認証のための一般的な枠組みを提供する。これにより、サーバはクライアントからの要求に対してチャレンジを提示でき、クライアントは認証情報を提供できる。本書は、"Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing" [RFC7230] で定義されるアーキテクチャに基づいて HTTP/1.1 の認証を定義する。これには、"HTTP Authentication: Basic and Digest Access Authentication" [RFC2617] で以前に記述された一般的フレームワーク、および "Hypertext Transfer Protocol -- HTTP/1.1" [RFC2616] で以前に定義された関連フィールドとステータスコードが含まれる。

IANA Authentication Scheme Registry (Section 5.1) には、登録済みの認証スキームと、それに対応する仕様が列挙されている。これには RFC 2617 により以前定義された "basic" および "digest" の認証スキームも含まれる。

1.1. Conformance and Error Handling

本書中のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は、[RFC2119] に記載のとおりに解釈されるものとする。

適合性基準およびエラー処理に関する考慮事項は [RFC7230] の Section 2.5 で定義される。

1.2. Syntax Notation

本仕様は [RFC5234] の Augmented Backus-Naur Form (ABNF) 記法を用いる。さらに、[RFC7230] の Section 7 で定義されるリスト拡張を使用し、'#' 演算子を用いてカンマ区切りリストを簡潔に定義できるようにする（'*' 演算子が繰り返しを示すのと同様である）。Appendix B は他文書から取り込んだ規則を説明する。Appendix C は、すべてのリスト演算子を標準の ABNF 記法へ展開した、文法の全体像を示す。

2. Access Authentication Framework

2.1. Challenge and Response

HTTP は、サーバがクライアント要求にチャレンジを提示し、クライアントが認証情報を提供するために利用できる、簡潔なチャレンジ・レスポンス方式の認証フレームワークを提供する。これは、認証スキームを識別する手段として大文字小文字を区別しないトークンを用い、その後に当該スキームで認証を達成するために必要な追加情報が続く。後者は、カンマ区切りのパラメータリスト、または base64 エンコードされた情報を保持できる単一の文字列（連続した文字列）である。

認証パラメータは name=value の組である。name トークンは大文字小文字を区別せずに照合され、各パラメータ名は 1 つのチャレンジ内で 1 回だけ出現しなければならない (MUST)。

auth-scheme    = token

auth-param     = token BWS "=" BWS ( token / quoted-string )

token68        = 1*( ALPHA / DIGIT /
                     "-" / "." / "_" / "~" / "+" / "/" ) *"="

token68 の構文は、66 個の予約されていない URI 文字 ([RFC3986]) に加えていくつかの文字を許可し、空白文字を除外した上で ([RFC4648])、base64、base64url（URL およびファイル名に安全なアルファベット）、base32、または base16（hex）エンコーディングを、パディングの有無にかかわらず保持できる。

401 (Unauthorized) の応答メッセージは、オリジンサーバがユーザエージェントの認可に対してチャレンジを提示するために用いられる。この応答には、要求されたリソースに適用可能な少なくとも 1 つのチャレンジを含む WWW-Authenticate ヘッダフィールドが含まれる。

407 (Proxy Authentication Required) の応答メッセージは、プロキシがクライアントの認可に対してチャレンジを提示するために用いられる。この応答には、要求されたリソースについて当該プロキシに適用可能な少なくとも 1 つのチャレンジを含む Proxy-Authenticate ヘッダフィールドが含まれる。

challenge   = auth-scheme [ 1*SP ( token68 / #auth-param ) ]

注: 多くのクライアントは、不明なスキームを含むチャレンジを正しく解析できない。この問題への回避策として、よくサポートされているスキーム（例: "basic"）を先に列挙する方法がある。

オリジンサーバに対して自身を認証したいユーザエージェントは（通常は 401 (Unauthorized) を受け取った後だが、必ずしもそうである必要はない）、要求に Authorization ヘッダフィールドを含めることでそれを行える。

プロキシに対して自身を認証したいクライアントは（通常は 407 (Proxy Authentication Required) を受け取った後だが、必ずしもそうである必要はない）、要求に Proxy-Authorization ヘッダフィールドを含めることでそれを行える。

Authorization フィールド値および Proxy-Authorization フィールド値はいずれも、要求されているリソースの realm に対するクライアントの資格情報を含む。これは応答で受け取ったチャレンジ（過去のいずれかの時点のものである可能性がある）に基づく。これらの値を生成する際、ユーザエージェントは、理解できる auth-scheme のうち最も安全だと考えるチャレンジを選択し、必要に応じてユーザから資格情報を取得して値を生成するのが望ましい。ヘッダフィールド値の中で資格情報を送信することは、Section 6.1 に記載のとおり、下位接続の機密性に関して重大なセキュリティ上の考慮事項を伴うことを意味する。

credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]

資格情報を省略した保護リソースへの要求、無効な資格情報（例: 誤ったパスワード）を含む要求、または部分的な資格情報（例: 認証スキームが 1 往復以上を必要とする場合）を含む要求を受信した場合、オリジンサーバは、要求されたリソースに適用可能な少なくとも 1 つの（場合によっては新しい）チャレンジを含む WWW-Authenticate ヘッダフィールドを伴う 401 (Unauthorized) 応答を送信するべきである (SHOULD)。

同様に、プロキシ資格情報を省略した要求、無効または部分的なプロキシ資格情報を含む要求を受信した場合、認証を要求するプロキシは、当該プロキシに適用可能な少なくとも 1 つの（場合によっては新しい）チャレンジを含む Proxy-Authenticate ヘッダフィールドを伴う 407 (Proxy Authentication Required) 応答を生成するべきである (SHOULD)。

有効な資格情報を受信したとしてもアクセスを得るには不十分である場合、サーバは 403 (Forbidden) ステータスコード（[RFC7231] の Section 6.5.3）で応答するのが望ましい。

HTTP は、アクセス認証に関してこの単純なチャレンジ・レスポンス方式の枠組みにアプリケーションを限定しない。たとえば、トランスポート層での認証やメッセージのカプセル化による認証、あるいは追加のヘッダフィールドで認証情報を指定するなど、追加メカニズムを利用できる。しかし、そのような追加メカニズムは本仕様では定義しない。

2.2. Protection Space (Realm)

"realm" 認証パラメータは、保護の範囲を示したい認証スキームが利用するために予約されている。

保護空間は、アクセス対象サーバの canonical root URI（有効な要求 URI の scheme および authority コンポーネント。 [RFC7230] の Section 5.5 を参照）と、存在する場合は realm 値との組み合わせによって定義される。これらの realm により、サーバ上の保護対象リソースを、保護空間の集合へ分割でき、各保護空間はそれぞれ独自の認証スキームおよび／または認可データベースを持てる。realm 値は文字列であり、一般にはオリジンサーバが割り当て、認証スキームに固有の追加の意味論を持ち得る。なお、同一の auth-scheme であっても realm が異なる複数のチャレンジを、1 つの応答が持つことがあり得る。

保護空間は、資格情報を自動的に適用できる範囲（ドメイン）を決定する。以前の要求が認可されている場合、ユーザエージェントは、その保護空間内の他のすべての要求に対して同じ資格情報を再利用してもよい (MAY)。再利用期間は認証スキーム、パラメータ、および／またはユーザの設定（例: 設定可能な非アクティブ時間のタイムアウト）により決定される。認証スキームが明示的に許可しない限り、単一の保護空間はそのサーバの範囲外へは広げられない。

歴史的な理由により、送信者は quoted-string 構文のみを生成しなければならない (MUST)。受信者は、長年にわたり両方の表記を受け入れてきた既存クライアントとの相互運用性を最大化するため、token と quoted-string の両方の構文をサポートする必要があるかもしれない。

3. Status Code Definitions

3.1. 401 Unauthorized

401 (Unauthorized) ステータスコードは、対象リソースに対する有効な認証資格情報が欠けているため、要求が適用されなかったことを示す。401 応答を生成するサーバは、対象リソースに適用可能な少なくとも 1 つのチャレンジを含む WWW-Authenticate ヘッダフィールド（Section 4.1）を送信しなければならない (MUST)。

要求に認証資格情報が含まれていた場合、401 応答は、その資格情報に対して認可が拒否されたことを示す。ユーザエージェントは、Authorization ヘッダフィールド（Section 4.2）を新規または置換して要求を再送してもよい (MAY)。401 応答に、直前の応答と同じチャレンジが含まれており、かつユーザエージェントがすでに少なくとも 1 回認証を試みている場合、ユーザエージェントは、同封された表現をユーザに提示するべきである (SHOULD)。そこには通常、関連する診断情報が含まれるためである。

3.2. 407 Proxy Authentication Required

407 (Proxy Authentication Required) ステータスコードは 401 (Unauthorized) に似ているが、プロキシを利用するためにクライアントが自身を認証する必要があることを示す。プロキシは、対象リソースに対して当該プロキシに適用可能なチャレンジを含む Proxy-Authenticate ヘッダフィールド（Section 4.3）を送信しなければならない (MUST)。クライアントは、Proxy-Authorization ヘッダフィールド（Section 4.4）を新規または置換して要求を再送してもよい (MAY)。

4. Header Field Definitions

本節は、HTTP 認証フレームワークに関連するヘッダフィールドの構文および意味を定義する。

4.1. WWW-Authenticate

"WWW-Authenticate" ヘッダフィールドは、対象リソースに適用可能な認証スキームとパラメータを示す。

WWW-Authenticate = 1#challenge

401 (Unauthorized) 応答を生成するサーバは、少なくとも 1 つのチャレンジを含む WWW-Authenticate ヘッダフィールドを送信しなければならない (MUST)。サーバは、資格情報（または別の資格情報）を提示することで応答が変わり得ることを示すために、他の応答メッセージ内で WWW-Authenticate ヘッダフィールドを生成してもよい (MAY)。

応答を転送するプロキシは、その応答内の WWW-Authenticate フィールドを変更してはならない (MUST NOT)。

ユーザエージェントはフィールド値の解析に際し特別な注意を払うことが推奨される。というのも、複数のチャレンジが含まれる可能性があり、各チャレンジはカンマ区切りの認証パラメータリストを含む可能性があるためである。さらに、ヘッダフィールド自体が複数回出現し得る。

例:

WWW-Authenticate: Newauth realm="apps", type=1,
                  title="Login to \"apps\"", Basic realm="simple"

このヘッダフィールドには 2 つのチャレンジが含まれている。1 つは realm 値が "apps" の "Newauth" スキームで、追加パラメータとして "type" と "title" を持つ。もう 1 つは realm 値が "simple" の "Basic" スキームである。

注: challenge の文法生成規則もリスト構文を用いる。したがって、「カンマ、空白、カンマ」の連なりは、直前のチャレンジに適用されるものとも、チャレンジのリストにおける空要素とも解釈できる。実際には、この曖昧性はヘッダフィールド値の意味に影響せず、したがって無害である。

4.2. Authorization

"Authorization" ヘッダフィールドは、ユーザエージェントがオリジンサーバに対して自身を認証できるようにする。通常は 401 (Unauthorized) 応答を受け取った後だが、必ずしもそうである必要はない。その値は、要求されているリソースの realm に対するユーザエージェントの認証情報を含む credentials から構成される。

Authorization = credentials

要求が認証され realm が指定された場合、同一の credentials は、この realm 内の他のすべての要求に対して有効であると推定される（ただし、認証スキーム自体が別途要件を課していないことが前提であり、たとえばチャレンジ値に応じて credentials が変化する場合や、同期した時計を用いる場合などがある）。

要求を転送するプロキシは、その要求内の Authorization フィールドを変更してはならない (MUST NOT)。HTTP キャッシュにおける Authorization フィールドの取り扱いに関する詳細および要件は [RFC7234] の Section 3.2 を参照せよ。

4.3. Proxy-Authenticate

"Proxy-Authenticate" ヘッダフィールドは、この有効な要求 URI（[RFC7230] の Section 5.5）に対してプロキシに適用可能な認証スキームとパラメータを示す、少なくとも 1 つのチャレンジから構成される。プロキシは、自ら生成する各 407 (Proxy Authentication Required) 応答において、少なくとも 1 つの Proxy-Authenticate ヘッダフィールドを送信しなければならない (MUST)。

Proxy-Authenticate = 1#challenge

WWW-Authenticate と異なり、Proxy-Authenticate ヘッダフィールドは応答チェーン上の次のアウトバウンドクライアントにのみ適用される。これは、特定のプロキシを選択したクライアントだけが、その認証に必要な credentials を持っている可能性が高いためである。しかし、同一の管理ドメイン内で複数のプロキシが用いられる場合（例: 大企業ネットワークにおけるオフィス内および地域のキャッシュプロキシ）には、credentials がユーザエージェントによって生成され、消費されるまで階層を通って受け渡されるのが一般的である。そのため、このような構成では、各プロキシが同じチャレンジ集合を送信することにより、Proxy-Authenticate が転送されているかのように見える。

なお、WWW-Authenticate に関する解析上の考慮事項は本ヘッダフィールドにも適用される。詳細は Section 4.1 を参照せよ。

4.4. Proxy-Authorization

"Proxy-Authorization" ヘッダフィールドは、認証を要求するプロキシに対して、クライアントが自身（またはそのユーザ）を識別できるようにする。その値は、要求されているリソースのプロキシおよび／または realm に対するクライアントの認証情報を含む credentials から構成される。

Proxy-Authorization = credentials

Authorization と異なり、Proxy-Authorization ヘッダフィールドは、Proxy-Authenticate フィールドを用いて認証を要求した次のインバウンドプロキシにのみ適用される。複数のプロキシが連鎖して使用される場合、Proxy-Authorization ヘッダフィールドは、credentials を受け取ることを期待していた最初のインバウンドプロキシによって消費される。プロキシは、そのプロキシ群が協調して特定の要求を認証するための仕組みとして必要であれば、クライアント要求から受け取った credentials を次のプロキシへ中継してもよい (MAY)。

5. IANA Considerations

5.1. Authentication Scheme Registry

"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" は、チャレンジおよび資格情報における認証スキームの名前空間を定義する。このレジストリは作成され、現在は http://www.iana.org/assignments/http-authschemes で管理されている。

5.1.1. Procedure

登録には、以下のフィールドを含めなければならない (MUST):

• Authentication Scheme Name
• 仕様本文へのポインタ
• Notes（任意）

この名前空間へ追加される値には IETF Review が必要である（[RFC5226] の Section 4.1 を参照）。

5.1.2. Considerations for New Authentication Schemes

HTTP Authentication Framework には、新しい認証スキームがどのように動作できるかに制約を与える側面がいくつかある:

• HTTP 認証はステートレスであると見なされる。つまり、要求を認証するために必要な情報はすべて、サーバが過去の要求を記憶していることに依存するのではなく、要求の中で提供されなければならない (MUST)。基盤となる接続に基づく、または接続に紐付けられた認証は、本仕様の範囲外であり、かつ（認証済みユーザ以外のいかなる当事者にも接続が利用されないことを保証する手順を講じない限り）本質的に欠陥がある（[RFC7230] の Section 2.3 を参照）。

• 認証パラメータ "realm" は、Section 2.2 に記載のとおり保護空間を定義するために予約されている。新しいスキームは、この定義と両立しない形で "realm" を用いてはならない (MUST NOT)。

• "token68" 記法は、既存の認証スキームとの互換性のために導入され、1 つのチャレンジまたは credentials あたり 1 回しか使用できない。したがって、新しいスキームは、将来の拡張が不可能になってしまうため、token68 ではなく auth-param 構文を用いるのが望ましい。

• チャレンジおよび credentials の解析は本仕様で定義されており、新しい認証スキームがこれを変更することはできない。auth-param 構文を用いる場合、すべてのパラメータは token と quoted-string の両方の構文をサポートするのが望ましく、また構文上の制約は、解析後のフィールド値（すなわち quoted-string の処理後）に対して定義されるのが望ましい。これは、受信者がすべての認証スキームに適用できる汎用パーサを使用できるようにするために必要である。

  注: "realm" パラメータの値構文を quoted-string に制限したことは、繰り返すべきではない悪い設計判断であった。

• 新しいスキームの定義は、不明な拡張パラメータの取り扱いを定義するのが望ましい。一般に、「must-understand」規則よりも「must-ignore」規則のほうが望ましい。そうでなければ、レガシー受信者が存在する状況で新しいパラメータを導入するのが困難になるためである。さらに、新しいパラメータを定義する方針（例: 「仕様を更新する」または「このレジストリを使用する」）を記述することも有益である。

• 認証スキームは、オリジンサーバ認証（WWW-Authenticate を使用）で利用可能か、プロキシ認証（Proxy-Authenticate を使用）で利用可能か、または両方で利用可能かを文書化する必要がある。

• Authorization ヘッダフィールドで運ばれる credentials はユーザエージェント固有であるため、それらは当該 credentials が現れる要求の範囲内で、"private" Cache-Control 応答ディレクティブ（[RFC7234] の Section 5.2.2.6）と同等の影響を HTTP キャッシュに与える。

  したがって、Authorization ヘッダフィールド内に credentials を載せないことを選ぶ新しい認証スキーム（例: 新たに定義したヘッダフィールドを使用する）は、Cache-Control 要求ディレクティブ（例: "no-store"。[RFC7234] の Section 5.2.1.5）または応答ディレクティブ（例: "private"）の使用を義務付けることで、キャッシュを明示的に禁止する必要がある。

5.2. Status Code Registration

"Hypertext Transfer Protocol (HTTP) Status Code Registry"（http://www.iana.org/assignments/http-status-codes に所在）は、以下の登録により更新された:

Value	Description	Reference
401	Unauthorized	Section 3.1
407	Proxy Authentication Required	Section 3.2

5.3. Header Field Registration

HTTP ヘッダフィールドは、http://www.iana.org/assignments/message-headers/ で管理されている "Message Headers" レジストリ内に登録される。

本書は以下の HTTP ヘッダフィールドを定義するため、"Permanent Message Header Field Names" レジストリがそれに応じて更新された（[BCP90] を参照）。

Header Field Name	Protocol	Status	Reference
Authorization	http	standard	Section 4.2
Proxy-Authenticate	http	standard	Section 4.3
Proxy-Authorization	http	standard	Section 4.4
WWW-Authenticate	http	standard	Section 4.1

変更管理者は: "IETF (iesg@ietf.org) - Internet Engineering Task Force" である。

6. Security Considerations

本節は、HTTP 認証に固有の既知のセキュリティ上の懸念について、開発者、情報提供者、および利用者に知らせることを目的とする。より一般的なセキュリティ上の考慮事項は、HTTP メッセージング [RFC7230] およびセマンティクス [RFC7231] で扱われる。

HTTP 認証という話題に関するあらゆる事項はセキュリティ上の考慮事項であるため、以下の考慮事項の一覧は網羅的ではない。さらに、この一覧は、個別の認証スキームに関するすべての潜在的な考慮事項を議論するものではなく、一般的に認証フレームワークに関するセキュリティ上の考慮事項に限定されている（個別の認証スキームに関する考慮事項は、それらを定義する仕様に文書化されるのが望ましい）。さまざまな組織が Web application セキュリティに関するトピック情報や、最新研究へのリンク（例: [OWASP]）を維持しており、実務で見られる認証スキームを実装・利用する際の一般的な落とし穴も含まれる。

6.1. Confidentiality of Credentials

HTTP 認証フレームワークは、資格情報の機密性を維持するための単一の仕組みを定義しない。代わりに、各認証スキームが、送信前に credentials をどのようにエンコードするかを定義する。これは将来の認証スキーム開発に柔軟性を与える一方で、機密性を自前で提供しない既存スキーム、あるいはリプレイ攻撃への防御が不十分なスキームを保護するには不十分である。さらに、サーバが個々のユーザに固有の credentials を期待している場合、その交換は、credentials の内容が機密のままであっても、そのユーザを識別する効果を持つ。

HTTP は、ヘッダフィールドを機密に送信するために、基盤となるトランスポート層またはセッション層の接続のセキュリティ特性に依存する。言い換えると、このフレームワークを用いて認証済みユーザにアクセスを限定するサーバは、利用する認証スキームの性質に応じて接続が適切に保護されることを確実にする必要がある。たとえば、個々のユーザの認証に依存するサービスは、credentials を交換する前に、TLS（"Transport Layer Security", [RFC5246]）で接続を保護することをしばしば要求する。

6.2. Authentication Credentials and Idle Clients

既存の HTTP クライアントおよびユーザエージェントは、通常、認証情報を無期限に保持する。HTTP は、オリジンサーバがクライアントに対して、これらのキャッシュされた credentials を破棄するよう指示する仕組みを提供しない。なぜならプロトコルは、credentials がどのように取得され、ユーザエージェントによってどのように管理されているかを認識しないためである。credentials の期限切れや失効の仕組みは、認証スキーム定義の一部として指定できる。

credentials のキャッシュがアプリケーションのセキュリティモデルを妨げ得る状況には、以下が含まれるが、これらに限られない:

• 長期間アイドル状態だったクライアント。この後、サーバはクライアントにユーザへ再度 credentials の入力を促させたい場合がある。

• セッション終了を示す表示（例: ページ上の "logout" または "commit" ボタン）を含むアプリケーション。これ以降、アプリケーションのサーバ側は、クライアントが credentials を保持する理由がもはやないことを「知っている」。

credentials をキャッシュするユーザエージェントは、ユーザの制御下でキャッシュされた credentials を破棄できる、容易にアクセス可能な仕組みを提供することが推奨される。

6.3. Protection Spaces

保護空間を確立するために "realm" メカニズムだけに依存する認証スキームは、オリジンサーバ上のすべてのリソースに credentials をさらすことになる。あるリソースに対して認証済みの要求を正常に行ったクライアントは、同一オリジンサーバ上の他のリソースに対しても同じ認証 credentials を使用できる。これにより、別のリソースが他のリソース向けの認証 credentials を収集することが可能になる。

これは、同一の canonical root URI（Section 2.2）の下で複数の当事者のリソースをオリジンサーバがホストする場合に特に問題となる。緩和策としては、認証 credentials への直接アクセスを制限すること（すなわち Authorization 要求ヘッダフィールドの内容を利用可能にしないこと）や、当事者ごとに異なるホスト名（またはポート番号）を使用して保護空間を分離することなどがある。

7. Acknowledgments

本仕様は、RFC 2617 で以前定義されていた HTTP Authentication Framework の定義を引き継ぐ。John Franks、Phillip M. Hallam-Baker、Jeffery L. Hostetler、Scott D. Lawrence、Paul J. Leach、Ari Luotonen、Lawrence C. Stewart の当該仕様に関する作業に感謝する。追加の謝辞については [RFC2617] の Section 6 を参照せよ。

本書の改訂に関連する謝辞については [RFC7230] の Section 10 を参照せよ。

8. References

8.1. Normative References

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
• [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.
• [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
• [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014.

8.2. Informative References

• [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
• [OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web Applications and Web Services", The Open Web Application Security Project (OWASP) 2.0.1, July 2005.
• [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
• [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
• [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
• [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
• [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFC 2617", BCP 26, RFC 5226, May 2008.
• [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

Appendix A. Changes from RFCs 2616 and 2617

HTTP Authentication のフレームワークは、RFC 2617 ではなく本書によって定義されるようになった。

"realm" パラメータは、チャレンジにおいて常に必須であるわけではなくなった。その結果、ABNF は auth パラメータをまったく持たないチャレンジも許容するようになった。（Section 2）

"Basic" のようなレガシー認証スキームとの整合性のために、auth-param リストに対する代替として "token68" が追加された。（Section 2）

本仕様は Authentication Scheme Registry を導入し、新しい認証スキームに関する考慮事項を併せて提示する。（Section 5.1）

Appendix B. Imported ABNF

以下のコア規則は、[RFC5234] の Appendix B.1 で定義されるとおり参照により含まれる: ALPHA（文字）、CR（復帰）、CRLF（CR LF）、CTL（制御文字）、DIGIT（10 進 0-9）、DQUOTE（二重引用符）、HEXDIG（16 進 0-9/A-F/a-f）、LF（改行）、OCTET（任意の 8 ビットのデータ列）、SP（空白）、VCHAR（表示可能な US-ASCII 文字）。

以下の規則は [RFC7230] で定義される:

BWS           = <BWS, see [RFC7230], Section 3.2.3>
OWS           = <OWS, see [RFC7230], Section 3.2.3>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token         = <token, see [RFC7230], Section 3.2.6>

Appendix C. Collected ABNF

以下の集約 ABNF では、リスト規則は [RFC7230] の Section 1.2 に従って展開されている。

Authorization = credentials

BWS = <BWS, see [RFC7230], Section 3.2.3>

OWS = <OWS, see [RFC7230], Section 3.2.3>

Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS
 challenge ] )
Proxy-Authorization = credentials

WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge
 ] )

auth-param = token BWS "=" BWS ( token / quoted-string )
auth-scheme = token

challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *(
 OWS "," [ OWS auth-param ] ) ] ) ]
credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param )
 *( OWS "," [ OWS auth-param ] ) ] ) ]

quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>

token = <token, see [RFC7230], Section 3.2.6>
token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
 *"="

Index

4

• 401 Unauthorized (status code) 6
• 407 Proxy Authentication Required (status code) 6

A

• Authorization header field 8

C

• Canonical Root URI 5

G

• Grammar
  • auth-param 4
  • auth-scheme 4
  • Authorization 8
  • challenge 4
  • credentials 5
  • Proxy-Authenticate 8
  • Proxy-Authorization 9
  • token68 4
  • WWW-Authenticate 7

P

• Protection Space 5
• Proxy-Authenticate header field 8
• Proxy-Authorization header field 9

R

• Realm 5

W

• WWW-Authenticate header field 7

Authors' Addresses

Roy T. Fielding (editor)\ Adobe Systems Incorporated\ 345 Park Ave\ San Jose, CA 95110\ USA

EMail: fielding@gbiv.com\ URI: http://roy.gbiv.com/

Julian F. Reschke (editor)\ greenbytes GmbH\ Hafenweg 16\ Muenster, NW 48155\ Germany

EMail: julian.reschke@greenbytes.de\ URI: http://greenbytes.de/tech/webdav/