The API server can generate a certificate and provide it to the client via a secure channel before any requests are made. This certificate is then used in the authentication process; this confirms the identity of both the client and server before requests are made. Although this method provides the greatest level of security (barring a dedicated VPN connection, which won't be covered here), it also has the most strenuous requirements on both sides: not all modules (say, NuSOAP) can handle client-side certificates.

Advantages:

• Identity confirmed — Both the server and the client can be sure of who they are communicating with.

• Encryption — Both the request and the response are protected from intermediate prying eyes.

Disadvantages:

• Increased load — Encrypting and decrypting communications is noticeably more CPU-intensive than unencrypted communications. Every request requires additional back and forth communications to set up the secure socket.

• Additional server requirements — The server must create a unique client certificate for each client that wishes to access the API. These APIs must be created and stored in a secure location and transmitted to the client via a secure channel.

Client-side certificates are as good as it gets in terms of API security; both the server and client are assured of the other's identity. Just like using an SSL endpoint, client-side certificates stack well with either HTTP authentication or message-based authentication. As with all forms of security, this increased level of security comes with a price: additional CPU load for both the client and the server, and the elimination of several useful client-side tools for interacting with the API.