I’m designing a JSON web API and want to distinguish clients by unique IDs, in order to monitor usage and block malicious/misbehaving clients. The API is NOT encapsulated in a JavaScript library and NOT exclusive to web apps, any client type can use it (desktop, phone, etc.).
The problem is, that the web app (official website) is also a client of the API itself, thus would have to expose its API key. As a result, some user could just extract the key from the JavaScript on the page and use it, instead of generating his own key.
Is it possible to mitigate this problem somehow with some better/smarter design choices, or do I have to live with the fact that anyone using the API in bad faith can exploit this?
I have 100% control over the frontend app (EmberJS) and backend servers (Go), so any alternation can be suggested.
- I’m using rate limiting per session/ip to add an extra protection layer for that case
- The twitter.com page was once also a client of its own API. How did they solve that?
Note: The question is not about authentication or security itself, but how to require 3rd party users to use an API key in addition (!) to authentication!
You should distinguish between web and non-web clients. An access key for web cannot be used in non-web and vice-versa. For web clients, you can do referer checking etc. You could also dynamically create access keys for your application and automatically change them daily (or every session). You can also add some special verification for your app only, e.g. some additional key that is calculted by obfuscated JS.
Nothing can prevent a malicious user to emulate a browser, execute the JS, manipulate that, and then do bad things – but you can make it annoying enough that they decide it’s not worth their effort. Really important things like permissions etc. obviously need to be checked server-side, so abusing your API should not be much of a problem. You will have to treat API abuse via your site’s API key the same as you do with regular web app abuse – IP blocks etc.
You still need to keep API keys for non-web clients secret. This can only be done unreliably by obfuscation, which you can leave at the hands of the client developer. If their key gets leaked and abused, you revoke it, and they will be motivated to fix it.
Have a look at OAuth 2.0, they impelement many features that could be useful for you. Even if you don’t want to use it, you can take some inspiration from it. OpenStreetMap uses OAuth (not sure if 1 or 2) for their flash-based editor; as long as it is called from the same origin by a logged-in user, the OAuth permission granting is done automatically. For third-party apps, the user needs to do it manually. You may want to check that out.