Authentication can be passed in the HTTP headers of incoming requests. This is the same type of authentication that is used when your browser creates a small login window when attempting to access a site. The authentication information is Base 64-encoded, so it does look like it is encrypted when transmitted over the wire, but in reality it is not. This encoding only ensures that all characters are valid to be passed in the header and is not intended to provide any level of security.

Advantages:

• Easily handled — Because the authentication information is sent in the HTTP headers, it can be handled by some moderately complex routers or gateways. This will allow for hardware-level throttling of abusive clients, or routing based on specific users. On the application side, the authentication will actually be handled by your web server, not your application. Web servers are developed and tested with high performance in mind, so this will likely end up being faster than any attempt to handle authentication in the application itself.

• Transparent — Because the web server is handling the authentication, you may choose to completely ignore what user is logged in, and concentrate solely on handling the request. This is obviously only applicable when requests are user-agnostic (every user receives the same response to the same query).

• Easy to code — Adding an additional HTTP header is relatively easy in most programming languages. It is also pretty universally available even in shared hosting situations (which may prevent things like SSL requests or external libraries).

Disadvantages:

• Authentication is sent in the clear — Base 64 is a two-way algorithm. Anyone who intercepts the request can determine the username and password being used, but they don't even need to; they can just use an identical header themselves.

• Username restriction — When using HTTP authentication, the colon (:) cannot be used in the username. A minor restriction, but one to keep in mind.

• No encryption — All requests and responses are visible to anyone between the requesting server and the API server.

• Slight barrier to use — Those unfamiliar with this method of authentication may shy away from attempting it.

This basic level of authentication is sufficient for many API applications. The presence of some basic authentication allows the API to either be client-aware or client-agnostic, depending on its specific needs, and also allows for throttling or denial to abusive clients. It would be a good idea with this type of authentication to provide some separation between the username and password combo used for the API and the site at large. This way, should the API's authentication information be compromised (by someone with access to the code, or by grabbing it off the wire), the valid user can use their regular information to change the API's credentials.