Understanding HTTP Authentication
This article is now a part of the Windows SDK.
Authentication is the process of identifying whether a client is eligible to access a resource. The HTTP protocol supports authentication as a means of negotiating access to a secure resource.
The initial request from a client is typically an anonymous request, not containing any authentication information. HTTP server applications can deny the anonymous request while indicating that authentication is required. The server application sends WWW-Authentication headers to indicate the supported types of authentication scheme. This document describes several authentication schemes for HTTP and discusses their support in Windows Communication Foundation (WCF).
HTTP Authentication Schemes
The server can specify multiple authentication schemes for the client to choose from. The following list describes some of the authentication schemes commonly found in Windows applications.
Authentication Scheme |
Description |
Anonymous |
An anonymous request does not contain any authentication information. This is equivalent to granting everyone access to the resource. |
Basic |
Basic authentication sends a Base64 encoded string that contains a user name and password for the client. Base64 is not a form of encryption and should be considered the same as sending the user name and password in clear text. If a resource needs to be protected, strongly consider using an authentication scheme other than basic authentication. |
Digest |
Digest authentication is a challenge-response scheme that is intended to replace Basic authentication. The server sends a data string called a nonce to the client as a challenge. The client responds with a hash that includes the user name, password, and nonce, among additional information. Using hashing and the nonce makes it more difficult to steal and reuse the user's credentials with this authentication scheme. Digest authentication requires the use of Windows domain accounts. The digest realm indicates the Windows domain name. Due to this, a server running on an operating system that does not support Windows domains, such as Windows XP Home, cannot be used with Digest authentication. When the client is running on an operating system that does not support Windows domains, a domain account must be explicitly specified during the authentication. |
Ntlm |
Ntlm authentication is a challenge-response scheme that is a more secure variation of Digest authentication. Ntlm uses Windows credentials to transform the challenge data instead of the unencoded user name and password. Ntlm authentication requires multiple exchanges between the client and server. The server and any intervening proxies must support persistent connections to successfully complete the authentication. |
Negotiate |
Negotiate authentication automatically selects between Kerberos and Ntlm authentication depending on availability. Kerberos is used in preference if available, otherwise Ntlm is tried instead. Kerberos authentication significantly improves upon Ntlm. Using Kerberos authentication is both faster than Ntlm and allows the use of mutual authentication and delegation of credentials to remote machines. |
Passport |
The underlying Windows HTTP service includes authentication using federated protocols. However, the standard HTTP transports in WCF do not support the use of federated authentication schemes, such as Microsoft Passport. Support for this feature is currently available through the use of message security. |
Choosing an Authentication Scheme
When selecting the potential authentication schemes for an HTTP server, first consider whether the resource needs to be protected. Using HTTP authentication requires transmitting more data and can limit interoperability with clients. Allow anonymous access to resources that do not need to be protected.
If the resource needs to be protected, next consider which authentication schemes provide the required level of security. The weakest standard authentication scheme discussed here is Basic authentication. Basic authentication does not protect the user's credentials. The strongest standard authentication scheme discussed here is Negotiate authentication, resulting in Kerberos. A server should not present an authentication scheme that it is not prepared to accept or that does not adequately secure the protected resource. Clients are free to choose between any of the authentication schemes presented by the server. Some clients default to a weak authentication scheme or the first authentication scheme in the server's list.
Next time: Building A Custom Message Encoder to Record Throughput, Part 3
Comments
Anonymous
May 12, 2006
The clock continues to count down for the start of TechEd 2006 in Boston. We're now exactly one month...Anonymous
July 24, 2006
I still get a lot of hits for the series of documentation articles I did back in April and May. All...Anonymous
November 21, 2006
I'm writing a middle-tier service that needs to act as the client. I can get the user name from the clientAnonymous
March 13, 2009
Just like WCF, WWSAPI supports Basic, Digest, NTLM and Negotiate HTTP header authentication (If you are