I've been reading a lot about many API security considerations, the differences in terminology, OAUTH, OpenID, etc. Although I understand their absolute necessity when it comes to securing an API properly, I am confronted with my (perhaps naive) vision of how things could be. I was hoping you could tell me how wrong or right I am and point me in the right direction. That would certainly be appreciated.

So, what exactly was I asked to do? -- The company I work for, called Company X, has lots of data stored internally. We now finally have an external PostgreSQL db in place and a webserver using Amazon EC2. This works really well. Now, I use Slim Framework to create routes, handle GET/POST/PUT/DELETE requests, send out queries using PDO and so on. Now I've come to the point where Company X asks me how their clients will be able to communicate with the API. Now of course I wouldn't hand over grant access to everyone, so I was initially thinking of an API key per client. I've used Instagram and other similar APIs and they seem to work on a similar way. However, I am also reading that "API keys are not enough". I can understand why this method may be too simplistic for a delicate issue of exchanging information, but I don't know if the other options are WAY to complex for the goals I am facing.

So, again to be clear, what I would like to accomplish is the following task: I want users to GET (let's say) notes from our server, I want them to be able to POST notes, updates them and delete them as well.

My question is how I can do this on a secure manner, without having to dive into dozens of protocol documentation. Of course, if that is the way to go then fine, but I am sure that there might be other ways that can prove to be just as safe.

Thanks for reading and especially if you decide to help me or at least tell me how far off I am from thinking with the right frame of mind. :-)

1 Answer 1


Edit: Clarified based on use case

First off, no system is perfect. Engineering is the art of making the best tradeoffs.

For backend-to-backend APIs (e.g. your server app and 3rd party API service) - API keys are really good. Most issues with API keys comes from developers neglecting how they store them (in code => commit to github public repos etc). API keys are

  1. high entropy strings
  2. can be revoked instantly
  3. don't auto-expire (great for machine automation I.e. APIs)

Many security companies like Amazon (cloud provider), Stripe (payments) or Crypteron (data security as a service) use API keys. If you're the API creator, you absolutely must design-in

  • a proper API key lifecycle management (customer developers can refresh API keys without much intervention) and
  • should strictly enforce TLS.

As a consumer of API keys, ideally you want separate API keys for development vs production, so your dev team doesn't see production data. Basically have dev resource/instances vs production resources/instances

Things change for end-user to back-end communications i.e. mobile phone app => your server app. In this case, you really don't want to use API keys because you're technically authenticating end users - not an API itself. If you use a static API key, anyone can disassemble the mobile app binary and scan for the API key. You won't know when that happens, but even if you knew, you instantly need to update all clients with a new API key - and you're back at square 1.

Basically, never use API keys in client apps like mobile apps or browser apps. Ever. It's as bad as having clients directly connect to your DB rather than having a web/app server in the middle.

You're better off with cached credentials + basic authentication + TLS for a two party system (user, your service). If one is using a 3rd party to verify identity (e.g. Facebook), OAuth is another option to orchestrate between the three parties (user, Facebook, your service). Based on your concern, I'm assuming your end-user clients (mobile or browser) are directly connecting to Slim Framework's REST end points? Slim Framework seems to supports basic authentication so that plus TLS should be a good starting point. If you have specific concerns, clarify them in the question.

Disclosure: I work for Crypteron. Check us out!

  • Thanks for your answer @DeepSpace101, I appreciate it. I especially hear lots of criticism on the use of API keys for POST/PUT/DELETE requests, is that something I should be concerned about? So to be clear, I am talking about a single API key. -- Would that suffice for these goals?
    – digifrog
    Apr 21, 2016 at 15:40
  • @user47147 I've updated the answer to consider the user-api scenario. Upvote/select if the answer helps you. Ate at my desk so I could answer this for you :) Apr 21, 2016 at 20:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .