Greg Murray's Blog

Creating and Using API Keys with Java Based Ajax Services

In Restricting Access to your Ajax Services we discussed the options that you may use to protect your services which included using an API key. Creating and Using API Keys for Java Based Ajax Services provides both the client and server code for using API keys on your Java based services. Included in the document are a discussion on the motivations and limitations of using API keys with servlets using the built in security APIs of Java.

Do you use API keys with your services? If so what techniques are you using?

Comments

• We use randomized keys for all WS communications in order to assert logical rules without first interpreting the data (used mainly for normalization before processing). This also has the added benefit of security-- everyone else is doing it :-)

  Posted by: jhook on June 04, 2007 at 02:39 PM

• Providing a web service based service using random keys that are rendered when the page is rendered is by far a good approach and would also prevent external domains from writing proxies that could miss-use the service.

  So I suspect you own both sides correct? I mean both the content rendered to the client and the service running in the same domain?

  The case we are trying to address is to provide a JavaScript client access to a service in another domain that does not require a server side proxy. We had considered sending out a script agent that would look up the web application name of the server using the service the window.location.href but as this would be done using JavaScript there is still the possibility that it could be compromised.

  One thing I learned from doing the API key example is that there is not a really good way guarantee a service is not miss-used while at the same time provide widespread access.

  Posted by: gmurray71 on June 05, 2007 at 01:05 AM

• How about reading the "Referrer" or "Host" properties from the request to the WS and serving the request based on whether the domain is trusted or not?

  Posted by: ksenji on June 05, 2007 at 12:05 PM

• This would be another alternative that could be done but it would be subject to the same potential Host / Referer spoofing issues correct? The only benefit you might have is that if the known set of trusted hosts is not published a potential hacker would have to guess the trusted hosts.

  Posted by: gmurray71 on June 05, 2007 at 01:32 PM

• Yes, you are right. The Referrer and Host can be spoofed as well. As you mentioned it is really difficult to stop XSRF while being generally available to genuine clients.
  One way I guess to avoid those sort of attacks on just API key usage is by using SSL for publishing the API key (which is unique per client) as well as the service itself. That way some other request forging site cannot get to the API key to make the XSRF and only genuine clients can make the request. Would that work?

  Posted by: ksenji on June 05, 2007 at 05:17 PM

• Binding keys to each client over SSL would help though it would making access the service difficult which was the whole point of providing the API keys ;-)

  Authentication over https seems like a better option if the risk of such attacks outweighs the ease of sharing a service. All said I still think there are valid cases for both providing and not providing API key based services. Google with it's maps, Ajax search, Ajax feeds, and data APIs are a good example of such cases.

  Posted by: gmurray71 on June 05, 2007 at 06:37 PM

This work is licensed under a Creative Commons License.