A Non-Microsoft Scenario

If you've surfed the Internet at all, you've probably encountered sites or web pages which require a password and user ID. When such a page is reached, the browser would pop up a little password entry dialog box. The interesting thing here is that there seems to be something built into the browser-server combination that provides this authentication capability. Yet, if you were to look into the documentation for the browser (and sometimes even from the server), you may be surprised to find that this capability is often not well described. At any rate, there seems to be no standard way to follow for authenticating a remote user using a random browser and server combination. How exactly is this done?

The secret, it turns out, lies in the transmitted HTTP packet's header information.

The scenario which leads to the triggering of the pop-up on the browser is as follow:

The client clicked on a link on the browser display which attempts to access some protected resource
The browser, having no way to tell a requested resource is protected, formats a normal HTTP request packet and transmit it to the server asking for the resource
The server attempts to access the resource and faces an 'access denied' situation
The server sends an access denied HTTP response packet back to the client, but in the header indicates the authentication schemes that the server will support in the order of preference
The browser receives the 'access denied' packet, and looks into the header to find the authentication schemes supported by the server and matches it against what it would support
If the lowest common denominator between the browser and server authentication support is basic authentication, the browser will pop-up the dialog box asking the user for a user ID and password
The user keys in the user ID and password
The browser retries the request packet, this time including the desired authentication method, the user ID, and Base64-encoded (totally unsecured) password in the header
The server receives the request packet with authentication information, impersonates the client if authentication is successful, and accesses the protected resource on behalf of the remote user
The server sends the contents of the requested resource back to the browser which promptly displays it

We should notice a few distinguishing points about the above scenario:

Nothing about it is specific to Microsoft or ActiveX: the situation can be handled with any browser supporting basic authentication, and any server running on any operating system which supports authentication capabilities
If the user were to access a series of protected pages, the above scenario would repeat itself, asking the user to repeatedly enter his or her user ID and password
The password of the user is sent over the wire with minimal encoding, leaving it vulnerable to potential interception

The form of authentication detailed above is called basic authentication and is the most widely used one over the Internet, since most browser, web server, and operating system combinations will support it.