2

I have seen references to API keys in several places. I have setup a few for various web services. However, I don't have a firm understanding of how they are protected (or not protected) from being copied and used by apps other than my own. I read a quick blurb from Google that said to use regular authentication over API keys due to them being able to be copied.

So my questions are: Are API keys just a bad way to subscribe services? Is there a way to protect them from being discovered? Maybe the app logs into a auth point for your services and is served the key to use with other services? But this key could still be gleaned from memory. Are API keys going to go away maybe in deference to things like oauth?

Comments
  • 0
  • 0
    Api keys shouldn't be part of your code base - especially if it's open sourced.
    Keep them outside, like a database, another repo ( environment config ) or hell drag them out of a json file in a private AWS S3 bucket.
  • 2
    Let's say you make a weather app.

    Let's say you get your weather data from some third party by using a REST-API. To protect their servers, you have to submit an API key for every request.

    To prevent the leak of this API key (it's rate limited so you only have 50'000 requests/day, too!) you must not include it in your app! Instead the users will connect to your servers, which does the request to the third party server (and e.g. caches results etc.).

    Even in your server's code, the API key is not directly encoded, rather it is passed the environment, e.g. as environment variable to your code. This prevents the API key being in your version control.

    For the authentication app <-> your servers, different methods are common: Usually the user logs in regularly (e.g. Username + Password, Google or Apple SSO) and gets back an API key for _his_ user account on _your_ service. The key for your server can be stores on the user's device, in a read protected area (which you cannot access from other apps).

    In this casd, your services verifies the user's API key, and makes a request to the third party weather API with the server's API key.
  • 0
    ok but what about all of these demo apps that tell to your make a file in your src directory for axios and have you put the key for some random third party site in there. that's client side or no? I missed the part explaining the finer points of public and src somewhere.
  • 1
    @M1sf3t
    Isn't /public the compiled code and /src the sources to compile it?

    Not a FE dev, I just seem to remember that being the name or the folder after compiling an angular project on our servers... I could be remembering wrong... Or was /public for static assets?
  • 0
    @Hazarth maybe, that would make sense at least. I know public is for static assets and global stylesheets, but that's about as much of an explanation as I've come across. Most of the time it's just "hey put this here and trust I know what I'm talking about".
Add Comment