In the context of an HTTP transaction, basic access authentication is a method for a web browser or other client program to provide 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 in the HTTP header 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 makes them unreadable to the unaided eye, they are as easily decoded as they are encoded. 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.
Basic access authentication was originally defined by RFC 1945 (Hypertext Transfer Protocol – HTTP/1.0). Further information regarding security issues can be found in RFC 2616 (Hypertext Transfer Protocol – HTTP/1.1) and RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication).
HTTP/1.1 supports both Basic and Digest Access Authentication.
One advantage of the basic access authentication is all web browsers support it. Rarely it is 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 unsecure channel.
Programmers and system administrators sometimes use basic access authentication, in a trusted network environment, to manually test web servers using Telnet or other plain-text network tools. This is a cumbersome process, but the network traffic is human-readable for diagnostic purposes.
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, if SSL/TLS is not used, then the credentials are passed as plaintext and could be intercepted.
A typical transaction between an HTTP client and an HTTP server might comprise the following steps:
- the client requests 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 ("Unauthorized") response code, including the required authentication scheme and 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 has the option to cancel at this point
- once the user has supplied a user name and password, the client adds an Authorization header (with value base64encode(username+":"+password)) to the original request and re-sends it
- 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 Authorization header in its first request, with no user interaction required.
Client request (no authentication):
GET /private/index.html HTTP/1.1 Host: localhost
(followed by a new line, in the form of a carriage return followed by a line feed).
HTTP/1.1 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 Unauthorized.</H1></BODY> </HTML>
Client request "Aladdin:open sesame" (user name "Aladdin", password "open sesame"):
GET /private/index.html HTTP/1.1 Host: localhost Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
(followed by a blank line, as before).
HTTP/1.1 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 of the restricted page).
The username and password value for the Authorization header can be easily encoded and decoded, here is a PHP example:
echo base64_encode("Aladdin:open sesame"), PHP_EOL; echo base64_decode("QWxhZGRpbjpvcGVuIHNlc2FtZQ=="), PHP_EOL;
References and notes
|This article includes a list of references, related reading or external links, but its sources remain unclear because it lacks inline citations. Please improve this article by introducing more precise citations. (April 2009)|
- Apache. "Authentication, Authorization, and Access Control". http://httpd.apache.org/docs/1.3/howto/auth.html#intro. Retrieved 2011-04-04.
- Network Working Group. "Hypertext Transfer Protocol -- HTTP/1.0". http://www.ietf.org/rfc/rfc1945.txt. Retrieved 2011-04-04.
- "Logging out of HTTP Authentication with Firefox" from Tolaris.com