source: draft-ietf-httpbis/latest/p7-auth.xml @ 2705

Last change on this file since 2705 was 2705, checked in by julian.reschke@…, 6 years ago

use consistent notation when referring to ABNF constructs (#553)

  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/xml
File size: 50.5 KB
Line 
1<?xml version="1.0" encoding="utf-8"?>
2<?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?>
3<!DOCTYPE rfc [
4  <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
5  <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
6  <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
7  <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
8  <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
9  <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
10  <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
11  <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
12  <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
13  <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
14  <!ENTITY ID-VERSION "latest">
15  <!ENTITY ID-MONTH "May">
16  <!ENTITY ID-YEAR "2014">
17  <!ENTITY mdash "&#8212;">
18  <!ENTITY Note "<x:h xmlns:x='http://purl.org/net/xml2rfc/ext'>Note:</x:h>">
19  <!ENTITY messaging                    "<xref target='RFC7230' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
20  <!ENTITY semantics                    "<xref target='RFC7231' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
21  <!ENTITY architecture                 "<xref target='RFC7230' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
22  <!ENTITY conformance                  "<xref target='RFC7230' x:rel='#conformance' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
23  <!ENTITY notation                     "<xref target='RFC7230' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
24  <!ENTITY abnf-extension               "<xref target='RFC7230' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
25  <!ENTITY acks                         "<xref target='RFC7230' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
26  <!ENTITY whitespace                   "<xref target='RFC7230' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
27  <!ENTITY field-components             "<xref target='RFC7230' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
28  <!ENTITY effective-request-uri        "<xref target='RFC7230' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
29  <!ENTITY msg-orient-and-buffering     "<xref target='RFC7230' x:rel='#intermediaries' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
30  <!ENTITY end-to-end.and-hop-by-hop    "<xref target='RFC7230' x:rel='#end-to-end.and.hop-by-hop.header-fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
31  <!ENTITY status.403                   "<xref target='RFC7231' x:rel='#status.403' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
32  <!ENTITY caching-authenticated-responses "<xref target='RFC7234' x:rel='#caching.authenticated.responses' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
33  <!ENTITY caching-rqd-no-store         "<xref target='RFC7234' x:rel='#cache-request-directive.no-store' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
34  <!ENTITY caching-rsd-private          "<xref target='RFC7234' x:rel='#cache-response-directive.private' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
35]>
36<?rfc toc="yes" ?>
37<?rfc symrefs="yes" ?>
38<?rfc sortrefs="yes" ?>
39<?rfc compact="yes"?>
40<?rfc subcompact="no" ?>
41<?rfc linkmailto="no" ?>
42<?rfc editing="no" ?>
43<?rfc comments="yes"?>
44<?rfc inline="yes"?>
45<?rfc rfcedstyle="yes"?>
46<?rfc-ext allow-markup-in-artwork="yes" ?>
47<?rfc-ext include-references-in-index="yes" ?>
48<rfc obsoletes="2616" updates="2617" category="std" x:maturity-level="proposed"
49     ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p7-auth-&ID-VERSION;"
50     xmlns:x='http://purl.org/net/xml2rfc/ext'>
51<x:link rel="prev" basename="p6-cache"/>
52<x:feedback template="mailto:ietf-http-wg@w3.org?subject={docname},%20%22{section}%22&amp;body=&lt;{ref}&gt;:"/>
53<front>
54
55  <title abbrev="HTTP/1.1 Authentication">Hypertext Transfer Protocol (HTTP/1.1): Authentication</title>
56
57  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
58    <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
59    <address>
60      <postal>
61        <street>345 Park Ave</street>
62        <city>San Jose</city>
63        <region>CA</region>
64        <code>95110</code>
65        <country>USA</country>
66      </postal>
67      <email>fielding@gbiv.com</email>
68      <uri>http://roy.gbiv.com/</uri>
69    </address>
70  </author>
71
72  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
73    <organization abbrev="greenbytes">greenbytes GmbH</organization>
74    <address>
75      <postal>
76        <street>Hafenweg 16</street>
77        <city>Muenster</city><region>NW</region><code>48155</code>
78        <country>Germany</country>
79      </postal>
80      <email>julian.reschke@greenbytes.de</email>
81      <uri>http://greenbytes.de/tech/webdav/</uri>
82    </address>
83  </author>
84
85  <date month="&ID-MONTH;" year="&ID-YEAR;"/>
86
87  <area>Applications</area>
88  <workgroup>HTTPbis</workgroup>
89
90  <keyword>Hypertext Transfer Protocol</keyword>
91  <keyword>HTTP</keyword>
92  <keyword>HTTP authentication</keyword>
93
94<abstract>
95<t>
96   The Hypertext Transfer Protocol (HTTP) is a stateless application-level
97   protocol for distributed, collaborative, hypermedia information systems.
98   This document defines the HTTP Authentication framework.
99</t>
100</abstract>
101
102<note title="Editorial Note (To be removed by RFC Editor)">
103  <t>
104    Discussion of this draft takes place on the HTTPBIS working group
105    mailing list (ietf-http-wg@w3.org), which is archived at
106    <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
107  </t>
108  <t>
109    The current issues list is at
110    <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> and related
111    documents (including fancy diffs) can be found at
112    <eref target="http://tools.ietf.org/wg/httpbis/"/>.
113  </t>
114  <t>
115    <spanx>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</spanx>
116  </t>
117</note>
118</front>
119<middle>
120<section title="Introduction" anchor="introduction">
121<t>
122   HTTP provides a general framework for access control and authentication,
123   via an extensible set of challenge-response authentication schemes, which
124   can be used by a server to challenge a client request and by a client to
125   provide authentication information. This document defines HTTP/1.1
126   authentication in terms of the architecture defined in
127   "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"
128   <xref target="RFC7230"/>, including the general framework previously
129   described in "HTTP Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/> and
130   the related fields and status codes previously defined in
131   "Hypertext Transfer Protocol -- HTTP/1.1" <xref target="RFC2616"/>.
132</t>
133<t>
134   The IANA Authentication Scheme Registry
135   (<xref target="authentication.scheme.registry"/>) lists registered
136   authentication schemes and their corresponding specifications, including
137   the "basic" and "digest" authentication schemes previously defined by
138   <xref target="RFC2617" x:fmt="none">RFC 2617</xref>.
139</t>
140
141<section title="Conformance and Error Handling" anchor="conformance">
142<t>
143   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
144   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
145   document are to be interpreted as described in <xref target="RFC2119"/>.
146</t>
147<t>
148   Conformance criteria and considerations regarding error handling
149   are defined in &conformance;.
150</t>
151</section>
152
153<section title="Syntax Notation" anchor="notation">
154<t>
155   This specification uses the Augmented Backus-Naur Form (ABNF) notation of
156   <xref target="RFC5234"/> with a list extension, defined in
157   &abnf-extension;, that allows for compact definition of
158   comma-separated lists using a '#' operator (similar to how the '*' operator
159   indicates repetition).
160   <xref target="imported.abnf"/> describes rules imported from
161   other documents.
162   <xref target="collected.abnf"/> shows the collected grammar with all list
163   operators expanded to standard ABNF notation.
164</t>
165</section>
166</section>
167
168<section title="Access Authentication Framework" anchor="access.authentication.framework">
169
170<section title="Challenge and Response" anchor="challenge.and.response">
171  <x:anchor-alias value="auth-scheme"/>
172  <x:anchor-alias value="auth-param"/>
173  <x:anchor-alias value="token68"/>
174  <x:anchor-alias value="challenge"/>
175  <x:anchor-alias value="credentials"/>
176<t>
177   HTTP provides a simple challenge-response authentication framework
178   that can be used by a server to challenge a client request and by a
179   client to provide authentication information. It uses a case-insensitive
180   token as a means to identify the authentication scheme, followed
181   by additional information necessary for achieving authentication via that
182   scheme. The latter can be either a comma-separated list of parameters or a
183   single sequence of characters capable of holding base64-encoded
184   information.
185</t>
186<t>
187   Authentication parameters are name=value pairs, where the name token is
188   matched case-insensitively,
189   and each parameter name &MUST; only occur once per challenge.
190</t>
191<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="auth-scheme"/><iref primary="true" item="Grammar" subitem="auth-param"/><iref primary="true" item="Grammar" subitem="token68"/>
192  auth-scheme    = <x:ref>token</x:ref>
193 
194  auth-param     = <x:ref>token</x:ref> <x:ref>BWS</x:ref> "=" <x:ref>BWS</x:ref> ( <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref> )
195
196  token68        = 1*( <x:ref>ALPHA</x:ref> / <x:ref>DIGIT</x:ref> /
197                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
198</artwork></figure>
199<t>
200   The token68 syntax allows the 66 unreserved URI characters
201   (<xref target="RFC3986"/>), plus a few others, so that it can hold a
202   base64, base64url (URL and filename safe alphabet), base32, or base16 (hex)
203   encoding, with or without padding, but excluding whitespace
204   (<xref target="RFC4648"/>).
205</t>
206<t>
207   A <x:ref>401 (Unauthorized)</x:ref> response message is used by an origin
208   server to challenge the authorization of a user agent, including a
209   <x:ref>WWW-Authenticate</x:ref> header field containing at least one
210   challenge applicable to the requested resource.
211</t>
212<t>  
213   A <x:ref>407 (Proxy Authentication Required)</x:ref> response message is
214   used by a proxy to challenge the authorization of a client, including a
215   <x:ref>Proxy-Authenticate</x:ref> header field containing at least one
216   challenge applicable to the proxy for the requested resource.
217</t>
218<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="challenge"/>
219  <x:ref>challenge</x:ref>   = <x:ref>auth-scheme</x:ref> [ 1*<x:ref>SP</x:ref> ( <x:ref>token68</x:ref> / #<x:ref>auth-param</x:ref> ) ]
220</artwork></figure>
221<x:note>
222  <t>
223     &Note; Many clients fail to parse a challenge that contains an unknown
224     scheme. A workaround for this problem is to list well-supported schemes
225     (such as "basic") first.<!-- see http://greenbytes.de/tech/tc/httpauth/#multibasicunknown2 -->
226  </t>
227</x:note>
228<t>
229   A user agent that wishes to authenticate itself with an origin server
230   &mdash; usually, but not necessarily, after receiving a
231   <x:ref>401 (Unauthorized)</x:ref> &mdash; can do so by including an
232   <x:ref>Authorization</x:ref> header field with the request.
233</t>
234<t>  
235   A client that wishes to authenticate itself with a proxy &mdash; usually,
236   but not necessarily, after receiving a
237   <x:ref>407 (Proxy Authentication Required)</x:ref> &mdash; can do so by
238   including a <x:ref>Proxy-Authorization</x:ref> header field with the
239   request.
240</t>
241<t>
242   Both the <x:ref>Authorization</x:ref> field value and the
243   <x:ref>Proxy-Authorization</x:ref> field value contain the client's
244   credentials for the realm of the resource being requested, based upon a
245   challenge received in a response (possibly at some point in the past).
246   When creating their values, the user agent ought to do so by selecting the
247   challenge with what it considers to be the most secure auth-scheme that it
248   understands, obtaining credentials from the user as appropriate.
249   Transmission of credentials within header field values implies significant
250   security considerations regarding the confidentiality of the underlying
251   connection, as described in
252   <xref target="confidentiality.of.credentials"/>.
253</t>
254<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="credentials"/>
255  <x:ref>credentials</x:ref> = <x:ref>auth-scheme</x:ref> [ 1*<x:ref>SP</x:ref> ( <x:ref>token68</x:ref> / #<x:ref>auth-param</x:ref> ) ]
256</artwork></figure>
257<t>
258   Upon receipt of a request for a protected resource that omits credentials,
259   contains invalid credentials (e.g., a bad password) or partial credentials
260   (e.g., when the authentication scheme requires more than one round trip),
261   an origin server &SHOULD; send a <x:ref>401 (Unauthorized)</x:ref> response
262   that contains a <x:ref>WWW-Authenticate</x:ref> header field with at least
263   one (possibly new) challenge applicable to the requested resource.
264</t>
265<t>
266   Likewise, upon receipt of a request that omits proxy credentials or
267   contains invalid or partial proxy credentials, a proxy that requires
268   authentication &SHOULD; generate a
269   <x:ref>407 (Proxy Authentication Required)</x:ref> response that contains
270   a <x:ref>Proxy-Authenticate</x:ref> header field with at least one
271   (possibly new) challenge applicable to the proxy.
272</t>
273<t>
274   A server that receives valid credentials that are not adequate to gain
275   access ought to respond with the <x:ref>403 (Forbidden)</x:ref> status
276   code (&status.403;).
277</t>
278<t>
279   HTTP does not restrict applications to this simple challenge-response
280   framework for access authentication. Additional mechanisms can be used,
281   such as authentication at the transport level or via message encapsulation,
282   and with additional header fields specifying authentication information.
283   However, such additional mechanisms are not defined by this specification.
284</t>
285</section>
286
287<section title="Protection Space (Realm)" anchor="protection.space">
288  <iref item="Protection Space"/>
289  <iref item="Realm"/>
290  <iref item="Canonical Root URI"/>
291<t>
292   The "<x:dfn>realm</x:dfn>" authentication parameter is reserved for use by
293   authentication schemes that wish to indicate a scope of protection.
294</t>
295<t>
296   A <x:dfn>protection space</x:dfn> is defined by the canonical root URI (the
297   scheme and authority components of the effective request URI; see
298   <xref target="RFC7230" x:fmt="of" x:rel="#effective.request.uri"/>) of the
299   server being accessed, in combination with the realm value if present.
300   These realms allow the protected resources on a server to be
301   partitioned into a set of protection spaces, each with its own
302   authentication scheme and/or authorization database. The realm value
303   is a string, generally assigned by the origin server, that can have
304   additional semantics specific to the authentication scheme. Note that a
305   response can have multiple challenges with the same auth-scheme but
306   with different realms.
307</t>
308<t>
309   The protection space determines the domain over which credentials can
310   be automatically applied. If a prior request has been authorized, the
311   user agent &MAY; reuse the same credentials for all other requests within
312   that protection space for a period of time determined by the authentication
313   scheme, parameters, and/or user preferences (such as a configurable
314   inactivity timeout). Unless specifically allowed by the authentication
315   scheme, a single protection space cannot extend outside the scope of its
316   server.
317</t>
318<t>
319   For historical reasons, a sender &MUST; only generate the quoted-string syntax.
320   Recipients might have to support both token and quoted-string syntax for
321   maximum interoperability with existing clients that have been accepting both
322   notations for a long time.
323</t>
324</section>
325
326</section>
327
328<section title="Status Code Definitions" anchor="status.code.definitions">
329<section title="401 Unauthorized" anchor="status.401">
330  <iref primary="true" item="401 Unauthorized (status code)" x:for-anchor=""/>
331  <x:anchor-alias value="401 (Unauthorized)"/>
332<t>
333   The <x:dfn>401 (Unauthorized)</x:dfn> status code indicates that the
334   request has not been applied because it lacks valid authentication
335   credentials for the target resource.
336   The server generating a 401 response &MUST; send a
337   <x:ref>WWW-Authenticate</x:ref> header field
338   (<xref target="header.www-authenticate"/>)
339   containing at least one challenge applicable to the target resource.
340</t>
341<t>
342   If the request included authentication credentials, then the 401 response
343   indicates that authorization has been refused for those credentials.
344   The user agent &MAY; repeat the request with a new or replaced
345   <x:ref>Authorization</x:ref> header field (<xref target="header.authorization"/>).
346   If the 401 response contains the same challenge as the prior response, and
347   the user agent has already attempted authentication at least once, then the
348   user agent &SHOULD; present the enclosed representation to the user, since
349   it usually contains relevant diagnostic information.
350</t>
351</section>
352
353<section title="407 Proxy Authentication Required" anchor="status.407">
354  <iref primary="true" item="407 Proxy Authentication Required (status code)" x:for-anchor=""/>
355  <x:anchor-alias value="407 (Proxy Authentication Required)"/>
356<t>
357   The <x:dfn>407 (Proxy Authentication Required)</x:dfn> status code is
358   similar to <x:ref>401 (Unauthorized)</x:ref>, but it indicates that the client
359   needs to authenticate itself in order to use a proxy.
360   The proxy &MUST; send a <x:ref>Proxy-Authenticate</x:ref> header field
361   (<xref target="header.proxy-authenticate"/>) containing a challenge
362   applicable to that proxy for the target resource. The client &MAY; repeat
363   the request with a new or replaced <x:ref>Proxy-Authorization</x:ref>
364   header field (<xref target="header.proxy-authorization"/>).
365</t>
366</section>
367</section>
368
369<section title="Header Field Definitions" anchor="header.field.definitions">
370<t>
371   This section defines the syntax and semantics of header fields related to
372   the HTTP authentication framework.
373</t>
374
375<section title="WWW-Authenticate" anchor="header.www-authenticate">
376  <iref primary="true" item="WWW-Authenticate header field" x:for-anchor=""/>
377  <x:anchor-alias value="WWW-Authenticate"/>
378<t>
379   The "WWW-Authenticate" header field indicates the authentication scheme(s)
380   and parameters applicable to the target resource.
381</t>
382<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="WWW-Authenticate"/>
383  <x:ref>WWW-Authenticate</x:ref> = 1#<x:ref>challenge</x:ref>
384</artwork></figure>
385<t>
386   A server generating a <x:ref>401 (Unauthorized)</x:ref> response
387   &MUST; send a WWW-Authenticate header field containing at least one
388   challenge.  A server &MAY; generate a WWW-Authenticate header field
389   in other response messages to indicate that supplying credentials
390   (or different credentials) might affect the response.
391</t>
392<t>
393   A proxy forwarding a response &MUST-NOT; modify any
394   <x:ref>WWW-Authenticate</x:ref> fields in that response.
395</t>
396<t>
397   User agents are advised to take special care in parsing the field value, as
398   it might contain more than one challenge, and each challenge can contain a
399   comma-separated list of authentication parameters. Furthermore, the header
400   field itself can occur multiple times.
401</t>
402<figure>
403  <preamble>For instance:</preamble>
404  <artwork type="example">
405  WWW-Authenticate: Newauth realm="apps", type=1,
406                    title="Login to \"apps\"", Basic realm="simple"
407</artwork>
408  <postamble>
409  This header field contains two challenges; one for the "Newauth" scheme
410  with a realm value of "apps", and two additional parameters "type" and
411  "title", and another one for the "Basic" scheme with a realm value of
412  "simple".
413</postamble></figure>
414<x:note>
415  <t>
416    &Note; The challenge grammar production uses the list syntax as
417    well. Therefore, a sequence of comma, whitespace, and comma can be
418    considered either as applying to the preceding challenge, or to be an
419    empty entry in the list of challenges. In practice, this ambiguity
420    does not affect the semantics of the header field value and thus is
421    harmless.
422  </t>
423</x:note>
424</section>
425
426<section title="Authorization" anchor="header.authorization">
427  <iref primary="true" item="Authorization header field" x:for-anchor=""/>
428  <x:anchor-alias value="Authorization"/>
429<t>
430   The "Authorization" header field allows a user agent to authenticate itself
431   with an origin server &mdash; usually, but not necessarily, after receiving
432   a <x:ref>401 (Unauthorized)</x:ref> response. Its value consists of
433   credentials containing the authentication information of the user agent for
434   the realm of the resource being requested.
435</t>
436<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Authorization"/>
437  <x:ref>Authorization</x:ref> = <x:ref>credentials</x:ref>
438</artwork></figure>
439<t>
440   If a request is authenticated and a realm specified, the same credentials
441   are presumed to be valid for all other requests within this realm (assuming
442   that the authentication scheme itself does not require otherwise, such as
443   credentials that vary according to a challenge value or using synchronized
444   clocks).
445</t>
446<t>
447   A proxy forwarding a request &MUST-NOT; modify any
448   <x:ref>Authorization</x:ref> fields in that request.
449   See &caching-authenticated-responses; for details of and requirements
450   pertaining to handling of the Authorization field by HTTP caches.
451</t>
452</section>
453
454<section title="Proxy-Authenticate" anchor="header.proxy-authenticate">
455  <iref primary="true" item="Proxy-Authenticate header field" x:for-anchor=""/>
456  <x:anchor-alias value="Proxy-Authenticate"/>
457<t>
458   The "Proxy-Authenticate" header field consists of at least one
459   challenge that indicates the authentication scheme(s) and parameters
460   applicable to the proxy for this effective request URI
461   (&effective-request-uri;).
462   A proxy &MUST; send at least one Proxy-Authenticate header field in
463   each <x:ref>407 (Proxy Authentication Required)</x:ref> response that it
464   generates.
465</t>
466<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/>
467  <x:ref>Proxy-Authenticate</x:ref> = 1#<x:ref>challenge</x:ref>
468</artwork></figure>
469<t>
470   Unlike <x:ref>WWW-Authenticate</x:ref>, the Proxy-Authenticate header field
471   applies only to the next outbound client on the response chain.
472   This is because only the client that chose a given proxy is likely to have
473   the credentials necessary for authentication.  However, when multiple
474   proxies are used within the same administrative domain, such as office and
475   regional caching proxies within a large corporate network, it is common
476   for credentials to be generated by the user agent and passed through the
477   hierarchy until consumed.  Hence, in such a configuration, it will appear
478   as if Proxy-Authenticate is being forwarded because each proxy will send
479   the same challenge set.
480</t>
481<t>
482   Note that the parsing considerations for <x:ref>WWW-Authenticate</x:ref>
483   apply to this header field as well; see <xref target="header.www-authenticate"/>
484   for details.
485</t>
486</section>
487
488<section title="Proxy-Authorization" anchor="header.proxy-authorization">
489  <iref primary="true" item="Proxy-Authorization header field" x:for-anchor=""/>
490  <x:anchor-alias value="Proxy-Authorization"/>
491<t>
492   The "Proxy-Authorization" header field allows the client to
493   identify itself (or its user) to a proxy that requires
494   authentication. Its value consists of credentials containing the
495   authentication information of the client for the proxy and/or realm of the
496   resource being requested.
497</t>
498<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authorization"/>
499  <x:ref>Proxy-Authorization</x:ref> = <x:ref>credentials</x:ref>
500</artwork></figure>
501<t>
502   Unlike <x:ref>Authorization</x:ref>, the Proxy-Authorization header field
503   applies only to the next inbound proxy that demanded authentication using
504   the <x:ref>Proxy-Authenticate</x:ref> field. When multiple proxies are used
505   in a chain, the Proxy-Authorization header field is consumed by the first
506   inbound proxy that was expecting to receive credentials. A proxy &MAY;
507   relay the credentials from the client request to the next proxy if that is
508   the mechanism by which the proxies cooperatively authenticate a given
509   request.
510</t>
511</section>
512
513</section>
514
515<section title="IANA Considerations" anchor="IANA.considerations">
516
517<section title="Authentication Scheme Registry" anchor="authentication.scheme.registry">
518<t>
519   The "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" defines the namespace for the
520   authentication schemes in challenges and credentials. It has been created
521   and is now maintained at <eref target="http://www.iana.org/assignments/http-authschemes"/>.
522</t>
523
524<section title="Procedure" anchor="authentication.scheme.registry.procedure">
525<t>
526  Registrations &MUST; include the following fields:
527  <list style="symbols">
528    <t>Authentication Scheme Name</t>
529    <t>Pointer to specification text</t>
530    <t>Notes (optional)</t>
531  </list>
532</t>
533<t>
534  Values to be added to this namespace require IETF Review
535  (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>).
536</t>
537</section>
538
539<section title="Considerations for New Authentication Schemes" anchor="considerations.for.new.authentication.schemes">
540<t>
541  There are certain aspects of the HTTP Authentication Framework that put
542  constraints on how new authentication schemes can work:
543</t>
544<t>
545  <list style="symbols">
546    <x:lt>
547    <t>
548      HTTP authentication is presumed to be stateless: all of the information
549      necessary to authenticate a request &MUST; be provided in the request,
550      rather than be dependent on the server remembering prior requests.
551      Authentication based on, or bound to, the underlying connection is
552      outside the scope of this specification and inherently flawed unless
553      steps are taken to ensure that the connection cannot be used by any
554      party other than the authenticated user
555      (see &msg-orient-and-buffering;).
556    </t>
557    </x:lt>
558    <x:lt>
559    <t>
560      The authentication parameter "realm" is reserved for defining protection
561      spaces as described in <xref target="protection.space"/>. New schemes
562      &MUST-NOT; use it in a way incompatible with that definition.
563    </t>
564    </x:lt>
565    <x:lt>
566    <t>
567      The "token68" notation was introduced for compatibility with existing
568      authentication schemes and can only be used once per challenge or credential.
569      Thus, new schemes ought to use the auth-param syntax instead, because
570      otherwise future extensions will be impossible.
571    </t>
572    </x:lt>
573    <x:lt>
574    <t>
575      The parsing of challenges and credentials is defined by this specification
576      and cannot be modified by new authentication schemes. When the auth-param
577      syntax is used, all parameters ought to support both token and
578      quoted-string syntax, and syntactical constraints ought to be defined on
579      the field value after parsing (i.e., quoted-string processing). This is
580      necessary so that recipients can use a generic parser that applies to
581      all authentication schemes.
582    </t>
583    <t>
584      &Note; The fact that the value syntax for the "realm" parameter
585      is restricted to quoted-string was a bad design choice not to be repeated
586      for new parameters.
587    </t>
588    </x:lt>
589    <x:lt>
590    <t>
591      Definitions of new schemes ought to define the treatment of unknown
592      extension parameters. In general, a "must-ignore" rule is preferable
593      to a "must-understand" rule, because otherwise it will be hard to introduce
594      new parameters in the presence of legacy recipients. Furthermore,
595      it's good to describe the policy for defining new parameters (such
596      as "update the specification" or "use this registry").
597    </t>
598    </x:lt>
599    <x:lt>
600    <t>
601      Authentication schemes need to document whether they are usable in
602      origin-server authentication (i.e., using <x:ref>WWW-Authenticate</x:ref>),
603      and/or proxy authentication (i.e., using <x:ref>Proxy-Authenticate</x:ref>).
604    </t>
605    </x:lt>
606    <x:lt>
607    <t>
608      The credentials carried in an <x:ref>Authorization</x:ref> header field are specific to
609      the user agent and, therefore, have the same effect on HTTP caches as the
610      "private" Cache-Control response directive (&caching-rsd-private;),
611      within the scope of the request in which they appear.
612    </t>
613    <t>
614      Therefore, new authentication schemes that choose not to carry
615      credentials in the <x:ref>Authorization</x:ref> header field (e.g., using a newly defined
616      header field) will need to explicitly disallow caching, by mandating the use of
617      either Cache-Control request directives (e.g., "no-store",
618      &caching-rqd-no-store;) or response directives (e.g., "private").
619    </t>
620    </x:lt>
621  </list>
622</t>
623</section>
624</section>
625
626<section title="Status Code Registration" anchor="status.code.registration">
627<t>
628   The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located at <eref target="http://www.iana.org/assignments/http-status-codes"/>
629   has been updated with the registrations below:
630</t>
631<?BEGININC p7-auth.iana-status-codes ?>
632<!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually-->
633<texttable align="left" suppress-title="true" anchor="iana.status.code.registration.table">
634   <ttcol>Value</ttcol>
635   <ttcol>Description</ttcol>
636   <ttcol>Reference</ttcol>
637   <c>401</c>
638   <c>Unauthorized</c>
639   <c>
640      <xref target="status.401"/>
641   </c>
642   <c>407</c>
643   <c>Proxy Authentication Required</c>
644   <c>
645      <xref target="status.407"/>
646   </c>
647</texttable>
648<!--(END)-->
649<?ENDINC p7-auth.iana-status-codes ?>
650</section>
651
652<section title="Header Field Registration" anchor="header.field.registration">
653<t>
654   HTTP header fields are registered within the "Message Headers" registry
655   maintained at
656   <eref target="http://www.iana.org/assignments/message-headers/"/>.
657</t>
658<t>
659   This document defines the following HTTP header fields, so the
660   "Permanent Message Header Field Names" registry has been updated
661   accordingly (see <xref target="BCP90"/>).
662</t>
663<?BEGININC p7-auth.iana-headers ?>
664<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
665<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
666   <ttcol>Header Field Name</ttcol>
667   <ttcol>Protocol</ttcol>
668   <ttcol>Status</ttcol>
669   <ttcol>Reference</ttcol>
670
671   <c>Authorization</c>
672   <c>http</c>
673   <c>standard</c>
674   <c>
675      <xref target="header.authorization"/>
676   </c>
677   <c>Proxy-Authenticate</c>
678   <c>http</c>
679   <c>standard</c>
680   <c>
681      <xref target="header.proxy-authenticate"/>
682   </c>
683   <c>Proxy-Authorization</c>
684   <c>http</c>
685   <c>standard</c>
686   <c>
687      <xref target="header.proxy-authorization"/>
688   </c>
689   <c>WWW-Authenticate</c>
690   <c>http</c>
691   <c>standard</c>
692   <c>
693      <xref target="header.www-authenticate"/>
694   </c>
695</texttable>
696<!--(END)-->
697<?ENDINC p7-auth.iana-headers ?>
698<t>
699   The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
700</t>
701</section>
702</section>
703
704<section title="Security Considerations" anchor="security.considerations">
705<t>
706   This section is meant to inform developers, information providers, and
707   users of known security concerns specific to HTTP authentication.
708   More general security considerations are addressed in HTTP messaging
709   &messaging; and semantics &semantics;.
710</t>
711<t>
712   Everything about the topic of HTTP authentication is a security
713   consideration, so the list of considerations below is not exhaustive.
714   Furthermore, it is limited to security considerations regarding the
715   authentication framework, in general, rather than discussing all of the
716   potential considerations for specific authentication schemes (which ought
717   to be documented in the specifications that define those schemes).
718   Various organizations maintain topical information and links to current
719   research on Web application security (e.g., <xref target="OWASP"/>),
720   including common pitfalls for implementing and using the authentication
721   schemes found in practice.
722</t>
723
724<section title="Confidentiality of Credentials" anchor="confidentiality.of.credentials">
725<t>
726   The HTTP authentication framework does not define a single mechanism for
727   maintaining the confidentiality of credentials; instead, each
728   authentication scheme defines how the credentials are encoded prior to
729   transmission. While this provides flexibility for the development of future
730   authentication schemes, it is inadequate for the protection of existing
731   schemes that provide no confidentiality on their own, or that do not
732   sufficiently protect against replay attacks. Furthermore, if the server
733   expects credentials that are specific to each individual user, the exchange
734   of those credentials will have the effect of identifying that user even if
735   the content within credentials remains confidential.
736</t>
737<t>
738   HTTP depends on the security properties of the underlying transport- or
739   session-level connection to provide confidential transmission of header
740   fields. In other words, if a server limits access to authenticated users
741   using this framework, the server needs to ensure that the connection is
742   properly secured in accordance with the nature of the authentication
743   scheme used. For example, services that depend on individual user
744   authentication often require a connection to be secured with TLS
745   ("Transport Layer Security", <xref target="RFC5246"/>) prior to exchanging
746   any credentials.
747</t>
748</section>
749
750<section title="Authentication Credentials and Idle Clients" anchor="auth.credentials.and.idle.clients">
751<t>
752   Existing HTTP clients and user agents typically retain authentication
753   information indefinitely. HTTP does not provide a mechanism for the
754   origin server to direct clients to discard these cached credentials, since
755   the protocol has no awareness of how credentials are obtained or managed
756   by the user agent. The mechanisms for expiring or revoking credentials can
757   be specified as part of an authentication scheme definition.
758</t>
759<t>
760   Circumstances under which credential caching can interfere with the
761   application's security model include but are not limited to:
762  <list style="symbols">
763     <t>Clients that have been idle for an extended period, following
764        which the server might wish to cause the client to re-prompt the
765        user for credentials.</t>
766
767     <t>Applications that include a session termination indication
768        (such as a "logout" or "commit" button on a page) after which
769        the server side of the application "knows" that there is no
770        further reason for the client to retain the credentials.</t>
771  </list>
772</t>
773<t>
774   User agents that cache credentials are encouraged to provide a readily
775   accessible mechanism for discarding cached credentials under user control.
776</t>
777</section>
778
779<section title="Protection Spaces" anchor="protection.spaces">
780<t>
781  Authentication schemes that solely rely on the "realm" mechanism for
782  establishing a protection space will expose credentials to all resources on
783  an origin server. Clients that have successfully made authenticated requests
784  with a resource can use the same authentication credentials for other
785  resources on the same origin server. This makes it possible for a different
786  resource to harvest authentication credentials for other resources.
787</t>
788<t>
789  This is of particular concern when an origin server hosts resources for multiple
790  parties under the same canonical root URI (<xref target="protection.space"/>).
791  Possible mitigation strategies include restricting direct access to
792  authentication credentials (i.e., not making the content of the
793  <x:ref>Authorization</x:ref> request header field available), and separating protection
794  spaces by using a different host name (or port number) for each party.
795</t>
796</section>
797</section>
798
799<section title="Acknowledgments" anchor="acks">
800<t>
801  This specification takes over the definition of the HTTP Authentication
802  Framework, previously defined in <xref target="RFC2617" x:fmt="none">RFC 2617</xref>.
803  We thank John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence,
804  Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work
805  on that specification. See <xref target="RFC2617" x:fmt="of" x:sec="6"/>
806  for further acknowledgements. 
807</t>
808<t>
809  See &acks; for the Acknowledgments related to this document revision.
810</t>
811</section>
812</middle>
813
814<back>
815
816<references title="Normative References">
817
818<reference anchor="RFC7230">
819  <front>
820    <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
821    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
822      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
823      <address><email>fielding@gbiv.com</email></address>
824    </author>
825    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
826      <organization abbrev="greenbytes">greenbytes GmbH</organization>
827      <address><email>julian.reschke@greenbytes.de</email></address>
828    </author>
829    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
830  </front>
831  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/>
832  <x:source href="p1-messaging.xml" basename="p1-messaging"/>
833</reference>
834
835<reference anchor="RFC7231">
836  <front>
837    <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
838    <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
839      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
840      <address><email>fielding@gbiv.com</email></address>
841    </author>
842    <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke">
843      <organization abbrev="greenbytes">greenbytes GmbH</organization>
844      <address><email>julian.reschke@greenbytes.de</email></address>
845    </author>
846    <date month="&ID-MONTH;" year="&ID-YEAR;" />
847  </front>
848  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" />
849  <x:source basename="p2-semantics" href="p2-semantics.xml">
850    <x:defines>403 (Forbidden)</x:defines>
851    <x:defines>Location</x:defines>
852  </x:source>
853</reference>
854
855<reference anchor="RFC7234">
856  <front>
857    <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
858    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
859      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
860      <address><email>fielding@gbiv.com</email></address>
861    </author>
862    <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">
863      <organization>Akamai</organization>
864      <address><email>mnot@mnot.net</email></address>
865    </author>
866    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
867      <organization abbrev="greenbytes">greenbytes GmbH</organization>
868      <address><email>julian.reschke@greenbytes.de</email></address>
869    </author>
870    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
871  </front>
872  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
873  <x:source href="p6-cache.xml" basename="p6-cache"/>
874</reference>
875
876<reference anchor="RFC2119">
877  <front>
878    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
879    <author initials="S." surname="Bradner" fullname="Scott Bradner">
880      <organization>Harvard University</organization>
881      <address><email>sob@harvard.edu</email></address>
882    </author>
883    <date month="March" year="1997"/>
884  </front>
885  <seriesInfo name="BCP" value="14"/>
886  <seriesInfo name="RFC" value="2119"/>
887</reference>
888
889<reference anchor="RFC5234">
890  <front>
891    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
892    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
893      <organization>Brandenburg InternetWorking</organization>
894      <address>
895        <email>dcrocker@bbiw.net</email>
896      </address> 
897    </author>
898    <author initials="P." surname="Overell" fullname="Paul Overell">
899      <organization>THUS plc.</organization>
900      <address>
901        <email>paul.overell@thus.net</email>
902      </address>
903    </author>
904    <date month="January" year="2008"/>
905  </front>
906  <seriesInfo name="STD" value="68"/>
907  <seriesInfo name="RFC" value="5234"/>
908</reference>
909
910</references>
911
912<references title="Informative References">
913
914<reference anchor="RFC2616">
915  <front>
916    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
917    <author initials="R." surname="Fielding" fullname="R. Fielding">
918      <organization>University of California, Irvine</organization>
919      <address><email>fielding@ics.uci.edu</email></address>
920    </author>
921    <author initials="J." surname="Gettys" fullname="J. Gettys">
922      <organization>W3C</organization>
923      <address><email>jg@w3.org</email></address>
924    </author>
925    <author initials="J." surname="Mogul" fullname="J. Mogul">
926      <organization>Compaq Computer Corporation</organization>
927      <address><email>mogul@wrl.dec.com</email></address>
928    </author>
929    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
930      <organization>MIT Laboratory for Computer Science</organization>
931      <address><email>frystyk@w3.org</email></address>
932    </author>
933    <author initials="L." surname="Masinter" fullname="L. Masinter">
934      <organization>Xerox Corporation</organization>
935      <address><email>masinter@parc.xerox.com</email></address>
936    </author>
937    <author initials="P." surname="Leach" fullname="P. Leach">
938      <organization>Microsoft Corporation</organization>
939      <address><email>paulle@microsoft.com</email></address>
940    </author>
941    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
942      <organization>W3C</organization>
943      <address><email>timbl@w3.org</email></address>
944    </author>
945    <date month="June" year="1999"/>
946  </front>
947  <seriesInfo name="RFC" value="2616"/>
948</reference>
949
950<reference anchor="RFC2617">
951  <front>
952    <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
953    <author initials="J." surname="Franks" fullname="John Franks">
954      <organization>Northwestern University, Department of Mathematics</organization>
955      <address><email>john@math.nwu.edu</email></address>
956    </author>
957    <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker">
958      <organization>Verisign Inc.</organization>
959      <address><email>pbaker@verisign.com</email></address>
960    </author>
961    <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler">
962      <organization>AbiSource, Inc.</organization>
963      <address><email>jeff@AbiSource.com</email></address>
964    </author>
965    <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence">
966      <organization>Agranat Systems, Inc.</organization>
967      <address><email>lawrence@agranat.com</email></address>
968    </author>
969    <author initials="P.J." surname="Leach" fullname="Paul J. Leach">
970      <organization>Microsoft Corporation</organization>
971      <address><email>paulle@microsoft.com</email></address>
972    </author>
973    <author initials="A." surname="Luotonen" fullname="Ari Luotonen">
974      <organization>Netscape Communications Corporation</organization>
975    </author>
976    <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart">
977      <organization>Open Market, Inc.</organization>
978      <address><email>stewart@OpenMarket.com</email></address>
979    </author>
980    <date month="June" year="1999"/>
981  </front>
982  <seriesInfo name="RFC" value="2617"/>
983</reference>
984
985<reference anchor='BCP90'>
986  <front>
987    <title>Registration Procedures for Message Header Fields</title>
988    <author initials='G.' surname='Klyne' fullname='G. Klyne'>
989      <organization>Nine by Nine</organization>
990      <address><email>GK-IETF@ninebynine.org</email></address>
991    </author>
992    <author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
993      <organization>BEA Systems</organization>
994      <address><email>mnot@pobox.com</email></address>
995    </author>
996    <author initials='J.' surname='Mogul' fullname='J. Mogul'>
997      <organization>HP Labs</organization>
998      <address><email>JeffMogul@acm.org</email></address>
999    </author>
1000    <date year='2004' month='September' />
1001  </front>
1002  <seriesInfo name='BCP' value='90' />
1003  <seriesInfo name='RFC' value='3864' />
1004</reference>
1005
1006<reference anchor="RFC3986">
1007 <front>
1008  <title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
1009  <author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
1010    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1011    <address>
1012       <email>timbl@w3.org</email>
1013       <uri>http://www.w3.org/People/Berners-Lee/</uri>
1014    </address>
1015  </author>
1016  <author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
1017    <organization abbrev="Day Software">Day Software</organization>
1018    <address>
1019      <email>fielding@gbiv.com</email>
1020      <uri>http://roy.gbiv.com/</uri>
1021    </address>
1022  </author>
1023  <author initials='L.' surname='Masinter' fullname='Larry Masinter'>
1024    <organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization>
1025    <address>
1026      <email>LMM@acm.org</email>
1027      <uri>http://larry.masinter.net/</uri>
1028    </address>
1029  </author>
1030  <date month='January' year='2005'></date>
1031 </front>
1032 <seriesInfo name="STD" value="66"/>
1033 <seriesInfo name="RFC" value="3986"/>
1034</reference>
1035
1036<reference anchor="RFC4648">
1037  <front>
1038    <title>The Base16, Base32, and Base64 Data Encodings</title>
1039    <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
1040    <date year="2006" month="October"/>
1041  </front>
1042  <seriesInfo value="4648" name="RFC"/>
1043</reference>
1044
1045<reference anchor='RFC5226'>
1046  <front>
1047    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
1048    <author initials='T.' surname='Narten' fullname='T. Narten'>
1049      <organization>IBM</organization>
1050      <address><email>narten@us.ibm.com</email></address>
1051    </author>
1052    <author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
1053      <organization>Google</organization>
1054      <address><email>Harald@Alvestrand.no</email></address>
1055    </author>
1056    <date year='2008' month='May' />
1057  </front>
1058  <seriesInfo name='BCP' value='26' />
1059  <seriesInfo name='RFC' value='5226' />
1060</reference>
1061
1062<reference anchor="OWASP" target="https://www.owasp.org/">
1063        <front>
1064    <title abbrev="OWASP">A Guide to Building Secure Web Applications and Web Services</title>
1065    <author role="editor" initials="A." surname="van der Stock"
1066            fullname="Andrew van der Stock"/>
1067    <date month="July" day="27" year="2005"/>
1068  </front>
1069  <seriesInfo name="The Open Web Application Security Project (OWASP)" value="2.0.1"/>
1070</reference>
1071
1072<reference anchor='RFC5246'>
1073   <front>
1074      <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
1075      <author initials='T.' surname='Dierks' fullname='T. Dierks'/>
1076      <author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
1077         <organization>RTFM, Inc.</organization>
1078      </author>
1079      <date year='2008' month='August' />
1080   </front>
1081   <seriesInfo name='RFC' value='5246' />
1082</reference>
1083
1084</references>
1085
1086<section title="Changes from RFCs 2616 and 2617" anchor="changes.from.rfc.2616">
1087<t>
1088  The framework for HTTP Authentication is now defined by this document,
1089  rather than RFC 2617.
1090</t>
1091<t>
1092  The "realm" parameter is no longer always required on challenges;
1093  consequently, the ABNF allows challenges without any auth parameters.
1094  (<xref target="access.authentication.framework"/>)
1095</t>
1096<t>
1097  The "token68" alternative to auth-param lists has been added for consistency
1098  with legacy authentication schemes such as "Basic".
1099  (<xref target="access.authentication.framework"/>)
1100</t>
1101<t>
1102  This specification introduces the Authentication Scheme Registry, along with
1103  considerations for new authentication schemes.
1104  (<xref target="authentication.scheme.registry"/>)
1105</t>
1106</section>
1107 
1108<section title="Imported ABNF" anchor="imported.abnf">
1109  <x:anchor-alias value="ALPHA"/>
1110  <x:anchor-alias value="CR"/>
1111  <x:anchor-alias value="DIGIT"/>
1112  <x:anchor-alias value="LF"/>
1113  <x:anchor-alias value="OCTET"/>
1114  <x:anchor-alias value="VCHAR"/>
1115  <x:anchor-alias value="SP"/>
1116  <x:anchor-alias value="quoted-string"/>
1117  <x:anchor-alias value="token"/>
1118  <x:anchor-alias value="BWS"/>
1119  <x:anchor-alias value="OWS"/>
1120<t>
1121  The following core rules are included by
1122  reference, as defined in <xref target="RFC5234" x:fmt="of" x:sec="B.1"/>:
1123  ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
1124  DIGIT (decimal 0-9), DQUOTE (double quote),
1125  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
1126  OCTET (any 8-bit sequence of data), SP (space), and
1127  VCHAR (any visible US-ASCII character).
1128</t>
1129<t>
1130   The rules below are defined in <xref target="RFC7230"/>:
1131</t>
1132<figure><artwork type="abnf2616">
1133  <x:ref>BWS</x:ref>           = &lt;BWS, see &whitespace;&gt;
1134  <x:ref>OWS</x:ref>           = &lt;OWS, see &whitespace;&gt;
1135  <x:ref>quoted-string</x:ref> = &lt;quoted-string, see &field-components;&gt;
1136  <x:ref>token</x:ref>         = &lt;token, see &field-components;&gt;
1137</artwork></figure>
1138</section>
1139
1140<?BEGININC p7-auth.abnf-appendix ?>
1141<section xmlns:x="http://purl.org/net/xml2rfc/ext" title="Collected ABNF" anchor="collected.abnf">
1142<t>
1143  In the collected ABNF below, list rules are expanded as per <xref target="RFC7230" x:rel="#notation"/>.
1144</t><figure>
1145<artwork type="abnf" name="p7-auth.parsed-abnf">
1146<x:ref>Authorization</x:ref> = credentials
1147
1148<x:ref>BWS</x:ref> = &lt;BWS, see [RFC7230], Section 3.2.3&gt;
1149
1150<x:ref>OWS</x:ref> = &lt;OWS, see [RFC7230], Section 3.2.3&gt;
1151
1152<x:ref>Proxy-Authenticate</x:ref> = *( "," OWS ) challenge *( OWS "," [ OWS
1153 challenge ] )
1154<x:ref>Proxy-Authorization</x:ref> = credentials
1155
1156<x:ref>WWW-Authenticate</x:ref> = *( "," OWS ) challenge *( OWS "," [ OWS challenge
1157 ] )
1158
1159<x:ref>auth-param</x:ref> = token BWS "=" BWS ( token / quoted-string )
1160<x:ref>auth-scheme</x:ref> = token
1161
1162<x:ref>challenge</x:ref> = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *(
1163 OWS "," [ OWS auth-param ] ) ] ) ]
1164<x:ref>credentials</x:ref> = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param )
1165 *( OWS "," [ OWS auth-param ] ) ] ) ]
1166
1167<x:ref>quoted-string</x:ref> = &lt;quoted-string, see [RFC7230], Section 3.2.6&gt;
1168
1169<x:ref>token</x:ref> = &lt;token, see [RFC7230], Section 3.2.6&gt;
1170<x:ref>token68</x:ref> = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
1171 *"="
1172</artwork>
1173</figure>
1174</section>
1175<?ENDINC p7-auth.abnf-appendix ?>
1176</back>
1177</rfc>
Note: See TracBrowser for help on using the repository browser.