Basic access authentication

In the context of an HTTP transaction, the basic access authentication is a method designed to allow a web browser, or other client program, to provide credentials – in the form of a user name and password – when making a request.

Before transmission, the user name is appended with a colon and concatenated with the password. The resulting string is encoded with the Base64 algorithm. For example, given the user name Aladdin and password open sesame, the string Aladdin:open sesame is Base64 encoded, resulting in QWxhZGRpbjpvcGVuIHNlc2FtZQ==. The Base64-encoded string is transmitted and decoded by the receiver, resulting in the colon-separated user name and password string.

While encoding the user name and password with the Base64 algorithm typically makes them unreadable by the naked eye, they are easily decoded, e.g., in Perl:

use MIME::Base64;
$encoded = 'QWxhZGRpbjpvcGVuIHNlc2FtZQ==';      
$decoded = decode_base64 $encoded;
print "$decoded\n"; # Aladdin:open sesame

in Python:

import base64
print base64.decodestring("QWxhZGRpbjpvcGVuIHNlc2FtZQ==")

or with openssl:

$ echo -n "Aladdin:open sesame" | openssl enc -base64
QWxhZGRpbjpvcGVuIHNlc2FtZQ==
$ echo "QWxhZGRpbjpvcGVuIHNlc2FtZQ==" | openssl enc -base64 -d
Aladdin:open sesame
$ 

Security is not the intent of the encoding step. Rather, the intent of the encoding is to encode non-HTTP-compatible characters that may be in the user name or password into those that are HTTP-compatible.

The basic access authentication was originally defined by RFC 1945 (Hypertext Transfer Protocol – HTTP/1.0) although further information regarding security issues may be found in RFC 2616 (Hypertext Transfer Protocol – HTTP/1.1) and RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication).

Advantages

One advantage of the basic access authentication is that it is supported by all popularTemplate:Refun web browsers. It is rarely used on publicly accessible Internet web sites but may sometimes be used by small, private systems. A later mechanism, digest access authentication, was developed in order to replace the basic access authentication and enable credentials to be passed in a relatively secure manner over an otherwise insecure channel.

Disadvantages

Although the scheme is easily implemented, it relies on the assumption that the connection between the client and server computers is secure and can be trusted. Specifically, the credentials are passed as plaintext and could be intercepted easily. The scheme also provides no protection for the information passed back from the server.

According to RFC 2616, existing browsers retain authentication information indefinitely. HTTP does not provide a method for a server to direct clients to discard these cached credentials. This means that there is no effective way for a server to "log out" the user without closing the browser. This is a significant defect that requires browser manufacturers to support a 'logout' user interface element or API available to JavaScript, further extensions to HTTP, or use of existing alternative techniques such as retrieving the page over SSL/TLS with an unguessable string in the URL.

Example

Here is a typical transaction between an HTTP client and an HTTP server running on the local machine (localhost). It comprises the following steps.

• The client asks for a page that requires authentication but does not provide a user name and password. Typically this is because the user simply entered the address or followed a link to the page.
• The server responds with the 401 response code and provides the authentication realm.
• At this point, the client will present the authentication realm (typically a description of the computer or system being accessed) to the user and prompt for a user name and password. The user may decide to cancel at this point.
• Once a user name and password have been supplied, the client re-sends the same request but includes the authentication header.
• In this example, the server accepts the authentication and the page is returned. If the user name is invalid or the password incorrect, the server might return the 401 response code and the client would prompt the user again.

Note: A client may pre-emptively send the authentication header in its first request, with no user interaction required.

---

Client request (no authentication):

GET /private/index.html HTTP/1.0
Host: localhost

(followed by a new line, in the form of a carriage return followed by a line feed).

Server response:

HTTP/1.0 401 Authorization Required
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:18:15 GMT
WWW-Authenticate: Basic realm="Secure Area"
Content-Type: text/html
Content-Length: 311

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
 "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML>
  <HEAD>
    <TITLE>Error</TITLE>
    <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
  </HEAD>
  <BODY><H1>401 Unauthorised.</H1></BODY>
</HTML>

Client request (user name "Aladdin", password "open sesame"):

GET /private/index.html HTTP/1.0
Host: localhost
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

(followed by a blank line, as before).

Server response:

HTTP/1.0 200 OK
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:19:07 GMT
Content-Type: text/html
Content-Length: 10476

(followed by a blank line and HTML text comprising of the restricted page).

References and notes

^ "all popular web browsers" in this context includes any browsers currently holding 0.2% of the market share or more. See Comparison of Web Browsers for more information on HTTP support in web browsers.

See also

• Digest access authentication