Distributing and using API-keys for web-applications

I have a web-application for which I'm building a Drupal module that allows my customers to access certain data on my application.

I intend to distribute secret API-keys to my customers who need to enter that value in their copy of the Drupal module. This Drupal module then talks to my web-application, but I need to make sure that the POST requests are indeed coming from that source.

How can this 'secret key' be used to pass some infor开发者_开发知识库mation that when my application receives it, it knows:

(a) its from that client's server.
(b) it hasnt been eavesdropped on / copied and used by someone else?

Should I be using this API-key as a password to encrypt some data that matches the rest of the POST request? When receiving it, I decrypt it using my copy of their API-key and it if matches the rest of the data, I consider it validated?

Is there a frame-work that does this for me? Something within Zend?

Use HTTPS and just send the API key in the request. It's that simple.

If you use HTTP then you are going to reinvent the wheel.

Update:

Here is an update after reading the comments, because in the question you didn't explain that you want to give the API keys to visitors of the website (in which case you would be screwed no matter what you do).

The comment by juanpaco explains what to do (and what I originally assumed that you're doing anyway) but I'll try to explained it in a little bit more detail.

The most important thing is that you don't use the API key in the web form. The API key is only used in the communication between your customers servers and your API server.

Here is a simplified explanation:

1. You give your customer a key and some software/module/library to install on his server.
2. When a visitor visits your customer's website he sees some HTML generated by your module that does not include any API key and can communicate only with your customer's server (with HTTPS if there is any sensitive information or user accounts involved at all).
3. Your module on the customer's server gets the request from the visitor.
4. Your module connects to your server using the API key (with HTTPS).
5. Your API server responds to the customer's server.
6. The customer's server responds to the visitor.

Your API key is never sent in the cleartext and never given to website visitor.

This is the only reasonable way to use API keys and after I first read your questions I assumed that you are concerned about the safety of sending your API keys between your servers and the servers of your customers.

If your customers were to give their keys to every visitor of their websites then those visitors would always be able to know them, no matter how hard you would try to make it. Giving visitors API keys and making them possible to use but impossible to read would be impossible. Not hard - impossible. No matter what protocols, encryption or anything you use.

(Thanks to juanpaco for bringing this old answer to my attention.)

1. Collect and store every client incoming url(e.g. www.authorisedclienturl.com) as part of the parameters you would store on your server before generating an API key to be shared with the client.
2. The client will use HTTPS to send the API key in the request boby from their registred authorised client urls only.
3. Use the API key to decript the client information on your server and retrieve the registered client url, verify that the incoming request url is present in the registered urls, then accept and proceed with other processes.