|
In the context of a HTTP transaction, the basic authentication scheme 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.
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 plain text and could be intercepted easily. The scheme also provides no protection for the information passed back from the server. To prevent the user name and password being read directly, they are encoded as a sequence of base-64 characters before transmission. A later mechanism, digest access authentication, was developed in order to replace the basic authentication scheme and enable credentials to be passed securely over an otherwise insecure channel.
One advantage of the basic authentication scheme is that it is supported by most clients. It is rarely used on normal Internet web sites but is suitable for small, private systems.
The basic authentication scheme was originally defined by RFC 1945 although further information regarding security issues may be found in RFC 2068 and RFC 2617.
Example
Here is a typical transaction between an HTTP client and an HTTP server running on the local machine (localhost). It comprises of 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 Unauthorised Server: SokEvo/1.0 Date: Sat, 27 Nov 2004 10:18:15 GMT WWW-Authenticate: Basic realm="SokEvo" 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: SokEvo/1.0 Date: Sat, 27 Nov 2004 10:19:07 GMT WWW-Authenticate: Basic realm="SokEvo" Content-Type: text/html Content-Length: 10476 (followed by a blank line and HTML text comprising of the restricted page). | 
Feeds |
Contact