1

I have some REST services on my site that will be available for 3rd parties to access. My plan is simple. In order to call on these services, they need to request a key from me. I will privately supply them with a GUID. Each call to any of my services will, via a filter, check the header for the key and accept/reject the request accordingly. This site is all HTTPS so the key would be encrypted during transit. I'm not worried about the key being visually identifiable to authorized clients. In other words, I'm not worried about any kind of 'inside' attacks or people sharing the key. I just don't want random, unauthorized outside users.

I have looked around and I don't really see anybody doing it exactly this way. I feel like I'm over-simplifying... but on the other hand, I don't see what's wrong with it either.

My question is.. does this sound secure enough (from a basic/minimal perspective) or does it expose some gaping security hole that I'm not seeing?

FWIW - I am using the Spring Framework, including Spring Security 4.

Thanks!

Jim Ott
  • 725
  • 13
  • 24
  • Sounds like a basic API key implementation, etc. I would check [this out first](https://stackoverflow.com/questions/25317405/securing-rest-api-using-custom-tokens-stateless-no-ui-no-cookies-no-basic-au). – syncdk Feb 14 '17 at 16:38
  • Yeah. Sorry, I wasn't clear in my original message. I'm already have this going. It's live and works well. My question was more about.. does it sound secure enough (from a basic/minimal perspective) or does it expose some gaping security hole that I'm not seeing? I'll update the original post. – Jim Ott Feb 14 '17 at 18:34
  • Cool, It's a pretty common pattern really, sometimes the minimal approach is the best. I've submitted an answer with an additional approach that could be used. – syncdk Feb 14 '17 at 23:24

1 Answers1

2

If it's HTTPS and the API key is in the header encrypted during transit as you described etc, then it follows a pretty standard design authentication pattern.

Your security now depends on how you distribute and store your API keys.

Although, you could use an "Application Identifier and Key pairs" approach.

Whereas the API Key Pattern combines the identity of the application and the secret usage token in one token, this pattern separates the two. Each application using the API issues an immutable initial identifier known as the Application ID (App ID). The App ID is constant and may or may not be secret. In addition each application may have 1-n Application Keys (App_Keys). Each Key is associated directly with the App_ID and should be treated as secret.

Just in case you wish to extend the application in the future.

syncdk
  • 2,820
  • 3
  • 25
  • 31