How do I include my API key in my open-source application?
July 29, 2008 7:25 PM Subscribe
I am developing a Firefox extension for use with a publicly available web API. Problem - API is restricted with a (developer) key that shouldn't be distributed in cleartext. Bonus - API provider is interested in working with me, as I am an early-adopter of the API program. Undesired solution - changing API keys so they're available to registered users. Is this possible?
Essentially, from my VERY limited knowledge, Firefox extensions are distributed with plainly readable source-code. In order to access the API I want to use, I need to include a developer key that is associated with my developer's account. The problem here is that I don't want users getting their grubby little hands on my API key and creating rogue applications that could cause my usage limits to be exceeded or my account deleted.
Let me re-iterate that we don't want to change the API so that users (instead of developers) have a key or token.
Is there a way to do this?
Essentially, from my VERY limited knowledge, Firefox extensions are distributed with plainly readable source-code. In order to access the API I want to use, I need to include a developer key that is associated with my developer's account. The problem here is that I don't want users getting their grubby little hands on my API key and creating rogue applications that could cause my usage limits to be exceeded or my account deleted.
Let me re-iterate that we don't want to change the API so that users (instead of developers) have a key or token.
Is there a way to do this?
I'd say the easiest solution is to setup your own server and proxy all their requests through it. They call your service without an API key, you relay it to the final destination with the proper API keys.
posted by AaRdVarK at 7:49 PM on July 29, 2008 [1 favorite]
posted by AaRdVarK at 7:49 PM on July 29, 2008 [1 favorite]
Another benefit of the proxy is if many users make similar requests, you can cache the responses and make the most of your usage limits.
posted by AaRdVarK at 7:51 PM on July 29, 2008
posted by AaRdVarK at 7:51 PM on July 29, 2008
Have the provider supply an encrypted version of the key, combined with some other data (like extension version or some other data that the extension might supply along with its initial handshaking). Supply that encrypted bundle with the distributed extension.
It's not perfect: anyone could remove the encrypted key from your extension and add it to their own, but they'd also have to have their extension claim to be yours as well (providing the same handshaking). For most people, that's going to be too much work especially if they can get their own developer key much more easily.
I also like hattifattener and AaRdVarK's answers.
posted by 5MeoCMP at 7:51 PM on July 29, 2008
It's not perfect: anyone could remove the encrypted key from your extension and add it to their own, but they'd also have to have their extension claim to be yours as well (providing the same handshaking). For most people, that's going to be too much work especially if they can get their own developer key much more easily.
I also like hattifattener and AaRdVarK's answers.
posted by 5MeoCMP at 7:51 PM on July 29, 2008
I'm responsible for one of the early versions of this kind of API key, from the Google Search API. The problem you're talking about is a significant technical flaw in this approach and I don't know of a great solution for it.
The usual workaround I've seen is that users of the application get their own API keys and use them with the apps. That may well not be acceptable in your case, but if it is then it's a neat solution.
Your next best option is Aardvark's suggestion of proxying the API requests through a server you yourself host.
Your last hope is to obfuscate the key a little bit in your Firefox extension's code, and hope someone isn't rude enough to steal it. If keys are readily available that's probably not a huge risk, it really depends on whether your key has any particular limits or liabilities.
posted by Nelson at 8:21 PM on July 29, 2008
The usual workaround I've seen is that users of the application get their own API keys and use them with the apps. That may well not be acceptable in your case, but if it is then it's a neat solution.
Your next best option is Aardvark's suggestion of proxying the API requests through a server you yourself host.
Your last hope is to obfuscate the key a little bit in your Firefox extension's code, and hope someone isn't rude enough to steal it. If keys are readily available that's probably not a huge risk, it really depends on whether your key has any particular limits or liabilities.
posted by Nelson at 8:21 PM on July 29, 2008
You need temporary session API keys. The extension could ping your server which would generate a session key for the client. Of course the API provider would have to be on board with it and be able to authenticate those session keys as valid. Off the top of my head a hash of a nice long salt and the developer API key ought to work. The API would need to be extended or the key would need to be special-cased (if it starts with SESS- it's a session key, otherwise it's a developer key, etc). I'd consider adding a timestamp to the hash so the sessions are time-limited but that's more work for everyone.
IANACryptographer, YMMV etc but if I were in your provider's position it's what I'd start with.
posted by Skorgu at 8:44 PM on July 29, 2008
IANACryptographer, YMMV etc but if I were in your provider's position it's what I'd start with.
posted by Skorgu at 8:44 PM on July 29, 2008
Encourage the service provider to allow a valid username and password as API keys.
I know it's pretty much a dodge around your real question, but this does seem to be the prevailing method in successful user-data centered web services with meaningful enduser integration in the browser (i.e. del.icio.us).
posted by Matt Oneiros at 10:15 PM on July 29, 2008
I know it's pretty much a dodge around your real question, but this does seem to be the prevailing method in successful user-data centered web services with meaningful enduser integration in the browser (i.e. del.icio.us).
posted by Matt Oneiros at 10:15 PM on July 29, 2008
This thread is closed to new comments.
posted by hattifattener at 7:44 PM on July 29, 2008