Changeset 1473 for draft-ietf-httpbis/latest/p7-auth.html
- Timestamp:
- 10/11/11 09:40:06 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p7-auth.html
r1472 r1473 359 359 } 360 360 @bottom-center { 361 content: "Expires May 8, 2012";361 content: "Expires May 13, 2012"; 362 362 } 363 363 @bottom-right { … … 405 405 <meta name="dct.creator" content="Reschke, J. F."> 406 406 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 407 <meta name="dct.issued" scheme="ISO8601" content="2011-11- 05">407 <meta name="dct.issued" scheme="ISO8601" content="2011-11-10"> 408 408 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 409 409 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework."> … … 436 436 </tr> 437 437 <tr> 438 <td class="left">Expires: May 8, 2012</td>438 <td class="left">Expires: May 13, 2012</td> 439 439 <td class="right">HP</td> 440 440 </tr> … … 489 489 <tr> 490 490 <td class="left"></td> 491 <td class="right">November 5, 2011</td>491 <td class="right">November 10, 2011</td> 492 492 </tr> 493 493 </tbody> … … 517 517 in progress”. 518 518 </p> 519 <p>This Internet-Draft will expire on May 8, 2012.</p>519 <p>This Internet-Draft will expire on May 13, 2012.</p> 520 520 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 521 521 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 651 651 and by a client to provide authentication information. It uses an extensible, case-insensitive token to identify the authentication 652 652 scheme, followed by additional information necessary for achieving authentication via that scheme. The latter can either be 653 a comma-separated list of attribute-value pairs or a single sequence of characters capable of holding base64-encoded information. 653 a comma-separated list of parameters or a single sequence of characters capable of holding base64-encoded information. 654 </p> 655 <p id="rfc.section.2.1.p.2">Parameters are name-value pairs where the name is matched case-insensitively, and each parameter name <em class="bcp14">MUST</em> only occur once per challenge. 654 656 </p> 655 657 <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.a.1"></span><span id="rfc.iref.a.2"></span><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.b.1"></span><span id="rfc.iref.g.3"></span> auth-scheme = <a href="#core.rules" class="smpl">token</a> … … 659 661 b64token = 1*( <a href="#notation" class="smpl">ALPHA</a> / <a href="#notation" class="smpl">DIGIT</a> / 660 662 "-" / "." / "_" / "~" / "+" / "/" ) *"=" 661 </pre><p id="rfc.section.2.1.p. 3">The "b64token" syntax allows the 66 unreserved URI characters (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>), plus a few others, so that it can hold a base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) encoding,663 </pre><p id="rfc.section.2.1.p.4">The "b64token" syntax allows the 66 unreserved URI characters (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>), plus a few others, so that it can hold a base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) encoding, 662 664 with or without padding, but excluding whitespace (<a href="#RFC4648" id="rfc.xref.RFC4648.1"><cite title="The Base16, Base32, and Base64 Data Encodings">[RFC4648]</cite></a>). 663 665 </p> 664 <p id="rfc.section.2.1.p. 4">The 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent. This response <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one challenge applicable to the requested resource.665 </p> 666 <p id="rfc.section.2.1.p. 5">The 407 (Proxy Authentication Required) response message is used by a proxy to challenge the authorization of a client and <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing at least one challenge applicable to the proxy for the requested resource.666 <p id="rfc.section.2.1.p.5">The 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent. This response <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one challenge applicable to the requested resource. 667 </p> 668 <p id="rfc.section.2.1.p.6">The 407 (Proxy Authentication Required) response message is used by a proxy to challenge the authorization of a client and <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing at least one challenge applicable to the proxy for the requested resource. 667 669 </p> 668 670 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.c.1"></span><span id="rfc.iref.g.4"></span> <a href="#challenge.and.response" class="smpl">challenge</a> = <a href="#challenge.and.response" class="smpl">auth-scheme</a> [ 1*<a href="#notation" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">b64token</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ] 669 </pre><div class="note" id="rfc.section.2.1.p. 7">671 </pre><div class="note" id="rfc.section.2.1.p.8"> 670 672 <p> <b>Note:</b> User agents will need to take special care in parsing the WWW-Authenticate and Proxy-Authenticate header field values because 671 673 they can contain more than one challenge, or if more than one of each is provided, since the contents of a challenge can itself … … 673 675 </p> 674 676 </div> 675 <div class="note" id="rfc.section.2.1.p. 8">677 <div class="note" id="rfc.section.2.1.p.9"> 676 678 <p> <b>Note:</b> Many browsers fail to parse challenges containing unknown schemes. A workaround for this problem is to list well-supported 677 679 schemes (such as "basic") first. 678 680 </p> 679 681 </div> 680 <p id="rfc.section.2.1.p. 9">A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a 401682 <p id="rfc.section.2.1.p.10">A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a 401 681 683 (Unauthorized) — <em class="bcp14">MAY</em> do so by including an Authorization header field with the request. 682 684 </p> 683 <p id="rfc.section.2.1.p.1 0">A client that wishes to authenticate itself with a proxy — usually, but not necessarily, after receiving a 407 (Proxy Authentication685 <p id="rfc.section.2.1.p.11">A client that wishes to authenticate itself with a proxy — usually, but not necessarily, after receiving a 407 (Proxy Authentication 684 686 Required) — <em class="bcp14">MAY</em> do so by including a Proxy-Authorization header field with the request. 685 687 </p> 686 <p id="rfc.section.2.1.p.1 1">Both the Authorization field value and the Proxy-Authorization field value consist of credentials containing the authentication688 <p id="rfc.section.2.1.p.12">Both the Authorization field value and the Proxy-Authorization field value consist of credentials containing the authentication 687 689 information of the client for the realm of the resource being requested. The user agent <em class="bcp14">MUST</em> choose to use one of the challenges with the strongest auth-scheme it understands and request credentials from the user based 688 690 upon that challenge. 689 691 </p> 690 692 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.c.2"></span><span id="rfc.iref.g.5"></span> <a href="#challenge.and.response" class="smpl">credentials</a> = <a href="#challenge.and.response" class="smpl">auth-scheme</a> [ 1*<a href="#notation" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">b64token</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ] 691 </pre><p id="rfc.section.2.1.p.1 3">If the origin server does not wish to accept the credentials sent with a request, it <em class="bcp14">SHOULD</em> return a 401 (Unauthorized) response. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource.692 </p> 693 <p id="rfc.section.2.1.p.1 4">If a proxy does not accept the credentials sent with a request, it <em class="bcp14">SHOULD</em> return a 407 (Proxy Authentication Required). The response <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy for the requested693 </pre><p id="rfc.section.2.1.p.14">If the origin server does not wish to accept the credentials sent with a request, it <em class="bcp14">SHOULD</em> return a 401 (Unauthorized) response. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource. 694 </p> 695 <p id="rfc.section.2.1.p.15">If a proxy does not accept the credentials sent with a request, it <em class="bcp14">SHOULD</em> return a 407 (Proxy Authentication Required). The response <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy for the requested 694 696 resource. 695 697 </p> 696 <p id="rfc.section.2.1.p.1 5">The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional698 <p id="rfc.section.2.1.p.16">The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional 697 699 mechanisms <em class="bcp14">MAY</em> be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying 698 700 authentication information. However, such additional mechanisms are not defined by this specification. 699 701 </p> 700 <p id="rfc.section.2.1.p.1 6">Proxies <em class="bcp14">MUST</em> forward the WWW-Authenticate and Authorization headers unmodified and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section 4.1</a>.702 <p id="rfc.section.2.1.p.17">Proxies <em class="bcp14">MUST</em> forward the WWW-Authenticate and Authorization headers unmodified and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section 4.1</a>. 701 703 </p> 702 704 <div id="rfc.iref.p.1"></div> … … 1209 1211 </ul> 1210 1212 <h2 id="rfc.section.C.19"><a href="#rfc.section.C.19">C.19</a> <a id="changes.since.17" href="#changes.since.17">Since draft-ietf-httpbis-p7-auth-17</a></h2> 1211 <p id="rfc.section.C.19.p.1">No changes yet.</p> 1213 <p id="rfc.section.C.19.p.1">Closed issues: </p> 1214 <ul> 1215 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/321">http://tools.ietf.org/wg/httpbis/trac/ticket/321</a>>: "Repeating auth-params" 1216 </li> 1217 </ul> 1212 1218 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 1213 1219 <p class="noprint"><a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.W">W</a>
Note: See TracChangeset
for help on using the changeset viewer.