Cookie-based HTTP Authenticationt.broyer@ltgt.net
Applications
This document specifies an HTTP authentication scheme for use when credentials
are validated by an out-of-band mechanism (not defined here) and later
communicated to the server through the use of a cookie. Which out-of-band
mechanism should be used, and how, is described by the 401 (Unauthorized)
response body. It is common practice that this mechanism is an HTML form,
sending the user's credentials with the use of an HTTP POST request to a tier
URL which will set a cookie in response; though this document doesn't preclude
the use of other mechanisms.
Distribution of this document is unlimited. Please send comments to the
ietf-http-auth mailing list at ietf-http-auth@osafoundation.org, which may be joined by sending a message with subject
"subscribe" to ietf-http-auth-request@osafoundation.org.
Discussions of the ietf-http-auth mailing list are archived at
.
XML versions, latest edits and the issues list for this document
are available from .
Authentication on the web can be done either at the
Hypertext Transfer Protocol (HTTP) level with a 401 (Unauthorized) status
code, or using SSL certificates. Among other issues already listed in
User Agent Authentication
Forms, the former suffers from a poor user experience while the latter
can quickly become expensive. That's why the most common authentication mechanism
is based on HyperText Markup Language
(HTML) forms and cookies.
However, form-based authentication is almost always implemented with an HTTP
redirect to the login form, making it impossible for non-browser user agents
to detect a protected resource (this leads to people downloading and saving
login forms instead of the protected resource they wanted, web service clients
failing with unrecoverable errors, etc.).
User Agent Authentication Forms
tried to overcome this with an amendment to HTML forms making them
"HTTP-authentication aware".
This document solves the problem the other way around, keeping the mechanism
backwards compatible with browsers while making it independant of HTML.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL-NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in Appendix of .
The terminology used here follows and extends that in the HTTP specification
Appendix of .
The "cookie" authentication scheme tries to reconcile the current practice of
many web sites and web development frameworks of using HTML forms and cookies
to authenticate users, and the Access Authentication Framework described in
Section 1.2 of . The user credentials being
passed through cookies, the Authorization and Proxy-Authorization request
headers are therefore not used.
The "cookie" authentication scheme cannot be used for proxy authentication
(within the value of a Proxy-Authenticate response header) because, as defined
in Section 3.5 of : "Proxies MUST NOT
introduce Set-Cookie2 (Cookie) headers of their own in proxy responses
(requests)."
When the origin server sends a 401 (Unauthorized) response containing a
WWW-Authenticate header with a "cookie" authentication scheme, the response
body gives instructions on how to create the appropriate cookies, generally
by issuing another HTTP request (preferably a POST request) to a distinct URL.
In most current web sites and web applications, the response body would be an
HTML document containing a form; when the form is submitted, the server checks
the user-provided form-data and upon validation sends the appropriate
Set-Cookie2 response header fields within a 303 (See Other) response redirecting
back to the protected resource.
The "cookie" authentication scheme is however not limited to such scenarios: the
response body could be for example an SVG image with an embedded XForms, or an
HTML document with an embedded script that will compute a hash of user-provided
data and set the cookie by script before reloading the resource, or some specific
entity recognized by the UA, which will authenticate using an out-of-band
mechanism and set the appropriate cookie before re-requesting the protected
resource. This last scenario might be better solved using another authentication
scheme, though this scenario would allow server-side negotiation of the
authentication mechanism using content negotiation; instead of the client-side
negotiation traditionally used when sending multiple WWW-Authenticate response
headers.
Syntax (using the augmented Backus-Naur Form (BNF) defined
in Section 2.1 of ): URI <">
URI = absolute-URI | ( path-absolute [ "?" query ] )
cookie-name = "cookie-name" "=" token
secure-cookie-name = "secure-cookie-name" "=" token
path-absolute =
quoted-string =
query =
token =
]]>
The meanings of the values of the directives used above are as follows:
OPTIONAL. The value of the "form-action" attribute is the URI reference
of the resource that will set the cookies used for authenticating the user
in subsequent requests. The value must resolve to an URI reference where
the "scheme" part MUST be "http" or "https", the "authority" part contains
no "userinfo", the "host" and "abs_path" parts have the same contraints as
the "Domain" and "Path" attributes of a Set-Cookie2 response header
respectively.
REQUIRED. The value of the "cookie-name" attribute is the name of the
cookie that is checked by the server to authenticate the user; an UA thus
could then inform the user this cookie is necessary to gain access to the
protected resource, and eventually use a different, more secure, storage
than for other cookies.
OPTIONAL. In case the application uses a mix of secured and unsecured
channels, the value of the "secure-cookie-name" attribute is the name of
the cookie that is checked by the server to authenticate the user when the
communication uses a secured channel, while the cookie named by the
"cookie-name" attribute will be used for unsecured channel.
The applicability of the cookie(s) (its Domain, Port and Path attributes)
defines the protection space.
This memo includes no request to IANA.
As with any use of cookies, care should be taken by servers to avoid cookie
spoofing, and clients to prevent unexpected cookie sharing (see Section 6 and Section 7 of ).
However, using cookies for account information requires that some additional
measures be taken. Using HTTP Over TLS or other
means of encrypting the conversation is sufficient to mitigate most threats,
though it requires that some additional measures be taken, as described in this
section.
To mitigate replay attacks (re-use of a sniffed cookie), the value of the
cookie used for authentication SHOULD NOT contain the users credentials but
rather a key associated with the authentication session, and this key SHOULD
be renewed (and expired) frequently.
Sensitive information (such as the user's IBAN on an online store) and
sensitive actions (such as confirming an order) SHOULD only happen on a
secure channel such as HTTP Over TLS, and
protected with a secure cookie (a cookie with the "Secure" bit set) so that
it cannot be stolen on a unsecured channel.
This document does not specify how credentials are sent to the "form-action"
URL, though care should be taken that those credentials cannot be sniffed.
In the case of an HTML form, the "form-action" SHOULD use a secure channel
such as HTTP Over TLS.
TODO: document how secure-cookie-name helps with security by preventing
replay-attacks. The cookie must obviously have the Secure attribute set.
TODO: add some words about CSRF (and find a normative reference). Mention
"logout" as a mean to mitigate CSRF.
Key words for use in RFCs to Indicate Requirement LevelsHarvard Universitysob@harvard.eduHypertext Transfer Protocol -- HTTP/1.1University of California, Irvinefielding@ics.uci.eduW3Cjg@w3.orgCompaq Computer Corporationmogul@wrl.dec.comMIT Laboratory for Computer Sciencefrystyk@w3.orgXerox Corporationmasinter@parc.xerox.comMicrosoft Corporationpaulle@microsoft.comW3Ctimbl@w3.orgHTTP Authentication: Basic and Digest Access AuthenticationNorthwestern University, Department of MathematicsNorthwestern UniversityEvanstonIL60208-2730USAjohn@math.nwu.eduVerisign Inc.301 Edgewater PlaceSuite 210WakefieldMA01880USApbaker@verisign.comAbiSource, Inc.6 Dunlap CourtSavoyIL61874USAjeff@AbiSource.comAgranat Systems, Inc.5 Clocktower PlaceSuite 400MaynardMA01754USAlawrence@agranat.comMicrosoft Corporation1 Microsoft WayRedmondWA98052USApaulle@microsoft.comNetscape Communications Corporation501 East Middlefield RoadMountain ViewCA94043USAOpen Market, Inc.215 First StreetCambridgeMA02142USAstewart@OpenMarket.com
"HTTP/1.0", includes the specification for a Basic Access
Authentication scheme. This scheme is not considered to be a secure
method of user authentication (unless used in conjunction with some
external secure system such as SSL ), as the user name and
password are passed over the network as cleartext.
This document also provides the specification for HTTP's
authentication framework, the original Basic authentication scheme
and a scheme based on cryptographic hashes, referred to as "Digest
Access Authentication". It is therefore also intended to serve as a
replacement for RFC 2069 . Some optional elements specified by
RFC 2069 have been removed from this specification due to problems
found since its publication; other new elements have been added for
compatibility, those new elements have been made optional, but are
strongly recommended.
Like Basic, Digest access authentication verifies that both parties
to a communication know a shared secret (a password); unlike Basic,
this verification can be done without sending the password in the
clear, which is Basic's biggest weakness. As with most other
authentication protocols, the greatest sources of risks are usually
found not in the core protocol itself but in policies and procedures
surrounding its use.
HTTP Over TLSThis memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.HTTP State Management MechanismBell Laboratories, Lucent Technologies600 Mountain Ave. Room 2A-333Murray HillNJ07974(908) 582-2250(908) 582-1239dmk@bell-labs.comEpinions.com, Inc.2037 Landings Dr.Mountain ViewCA94301lou@montulli.org
This document specifies a way to create a stateful session with
Hypertext Transfer Protocol (HTTP) requests and responses. It
describes three new headers, Cookie, Cookie2, and Set-Cookie2, which
carry state information between participating origin servers and user
agents. The method described here differs from Netscape's Cookie
proposal , but it can interoperate with HTTP/1.0 user
agents that use Netscape's method. (See the HISTORICAL section.)
This document reflects implementation experience with RFC 2109 and
obsoletes it.
Uniform Resource Identifier (URI): Generic SyntaxWorld Wide Web ConsortiumMassachusetts Institute of Technology77 Massachusetts AvenueCambridgeMA02139USA+1-617-253-5702+1-617-258-5999timbl@w3.orghttp://www.w3.org/People/Berners-Lee/Day Software5251 California Ave., Suite 110IrvineCA92617USA+1-949-679-2960+1-949-679-2972fielding@gbiv.comhttp://roy.gbiv.com/Adobe Systems Incorporated345 Park AveSan JoseCA95110USA+1-408-536-3024LMM@acm.orghttp://larry.masinter.net/HTML 4.01 SpecificationUser Agent Authentication Forms
Most detail of request and response headers has been omitted. Assume that the
user agent has no stored cookies.
User Agent -> Server
Server -> User Agent
Unauthorized
]]>
User Agent -> Server
Server -> User Agent
User Agent -> Server
Server -> User Agent
User Agent -> Server
Server -> User Agent
Unauthorized
]]>
User Agent -> Server
Server -> User Agent
User Agent -> Server
Server -> User Agent
User Agent -> Server
Server -> User Agent
TODO: using CSRF and server-to-server communication to achieve cross-domain
single sign-on between sso.some-co.com and www.some-tm.net.
At some-tm.net, the 401 response body loads a javascript from
sso.some-co.com that sets a "temporary" cookie if already authenticated
or redirects to sso.some-co.com otherwise. In the former case, the
server validates the "temporary" cookie by calling sso.some-co.com and
then sets the appropriate cookie to authenticate the user at some-tm.net.
On the latter case, the server then redirects the browser back to
some-tm.net with some token in the URL; this token is validated the same
way as with the "temporary" cookie and the browser is then redirected
back to the protected resource.
Fallback in case javascript is not available is a <meta refresh>
(in a <noscript>) to redirect the browser to sso.some-co.com. The
process is then similar to JA-SIG Central Authentication Service (CAS).
Or maybe these should be two distinct examples?
And do not forget the "single-logout" issue.