I'm trying to create an API with minimum forced structure. The messages can come from end user device or from a backend server. I'm ok with opening separate API for end user traffic and from servers. The client are web and mobile companies that can send their data to the API. (Think google analytics for websites, mobile application and events from web servers) What will be the best practice to know that a http request to the API got from a trusted client? If there is any good article in that manner, that what be great also.

-- EDIT -- What will be the best practice to authenticate the client (not the end user)

closed as too broad by TildalWave, Xander, AJ Henderson, Eric G, Adi Oct 26 '14 at 10:37

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


You cannot trust the client, ever.

  • A malicious user may abuse legitimate client software (theirs, or someone else's)
  • An attacker may reverse engineer enough of the API to pretend to be a legitimate client

Instead of trusting the client, work to ensure that the client's input is trustworthy.

  • input validation
  • input sanitization
  • schema compliance
  • velocity checking

Do these things at your end, which you do control, to provide security for your system. Don't waste your time imagining you can control the remote endpoints.

  • OK. So, I've updated the question. What will be the best practice to authenticate the client? – Gluz Oct 23 '14 at 4:09

I'm answering my own questions but for future seekers, I found this great article: http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication. Maybe I didn't explain my question well but this was the answer I was looking for.

-- UPDATE --

Rory Alsop, asked to post a summary. You should definitely read the source. But in case you can't, I've attached a part of the solution screenshot from the source. enter image description here

  • 1
    nice find & nice read, one of the better explanation imho – that guy from over there Oct 23 '14 at 6:50
  • Gluz - can you please post a summary of the content at that site, as otherwise it is not useful here and may be deleted/converted to a comment. – Rory Alsop Oct 23 '14 at 10:41
  • Decent article for preventing MITM attacks. However, it's validation of the client is only as good as the client's protection of their ("secret" or "shared", not "private" as the article would have it) key... which is why you cannot trust the client, ever. If you want to secure the API, you still have to do it at your end. – gowenfawr Oct 23 '14 at 11:43
  • Note - original article can now be found at web.archive.org/web/20151016205928/http:/www.thebuzzmedia.com/… Text (and comments) here recommend looking at OAuth 2 instead, which wasn't final at the time, but now is and has a lot of library/platform support: oauth.net/2 – Dave A-W May 12 '16 at 1:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.