3

So I'm planning to use APIs for my host app. But the APIs are built such that it requires a sessionkey for every request.

So my question is, how would I dogfood my API? Cause, apparently I'm thinking in the line of creating a "special" key for my host app (cause it makes no sense to request for a key for my own use), but, anyone inspecting the headers of the request could find this key and literally use it and bypass requesting their own keys.

Maybe there's a best practice for dogfooding our own API without a special key or someway to differentiate whether the request is coming from the host app or the public.

I couldn't use IP to differentiate too, cause the public could be using the same server to call the APIs. That's just the way it is, and is a one of the constraints to keep in mind.

resting
  • 319
  • 2
  • 7
  • 9
    "cause it makes no sense to request for a key for my own use" - why? – ckhan Apr 29 '13 at 09:21
  • @ckhan, MetaFight cause using the host app, you're already logged in and authenticated, so there's no reason to request a sessionkey just to use the APIs. – resting May 01 '13 at 05:04

3 Answers3

12

You're about to learn an important lesson about APIs. Any time you find yourself saying "I need something special that shouldn't be available to others", you're wrong. That's especially true when it comes to identification and authentication.

Ross Patterson
  • 10,277
  • 34
  • 43
  • and also especially true when talking about testing. Test what the users will use, not some special code only you have access to. – Bryan Oakley Jul 24 '13 at 01:04
1

There shouldn't be any special key on a live API server as you also mentioned that the header may be parsed and key may be found. What we did in a similar situation was creating a sandbox or a separate environment (separate URL only known to the development team) and then changing the code to accept a special key.

I think the point in the question is to skip authentication. To avoid sniffing secure communication is the solution i.e. communicating over HTTPS

gnat
  • 21,442
  • 29
  • 112
  • 288
Abdullah Shoaib
  • 238
  • 1
  • 5
  • Wouldn't this be susceptible to the same kind of communication sniffing as the original suggestion? If, in the original scenario, the special key could be discovered by sniffing, then, in the second scenario, the special key AND the sandbox can be found by sniffing. It sounds like proper *authentication* is needed. – MetaFight Apr 29 '13 at 09:45
  • I thick the point in the question is to skip _authentication_. To avoid sniffing secure communication is the solution i.e. communicating over HTTPS. – Abdullah Shoaib Apr 29 '13 at 09:53
  • As Ross Patterson has already mentioned, "skipping authentication" is tantamount do "doing it wrong." And, what you're suggesting with HTTPS is a form of authentication. It's just delegated to somewhere else in the stack. – MetaFight Apr 29 '13 at 13:29
  • @MetaFight Okay, I agree that skipping authentication is wrong, but that's the requirement in the question. Question is not "is it right or wrong?" it is "how...". Other than that HTTPS provides authentication of the web site and associated web server and not API authentication, it's also transport layer encryption which prevents Man in the middle attacks. [link](http://en.wikipedia.org/wiki/HTTP_Secure) – Abdullah Shoaib Apr 29 '13 at 13:43
  • Regarding HTTPS you're absolutely right. It wouldn't hide either the special key or the sandbox url from the client. It would only prevent a man-in-the-middle from finding either. Fiddler is your friend *and* your foe ;) – MetaFight Apr 29 '13 at 14:02
  • *"... and then changing the code to accept a special key"* Next thing you know, someone merges those changes into mainline by mistake. – user Apr 29 '13 at 14:47
  • @AbdullahShoaib that is an alternative. but wouldn't user be able to see where the requests are heading to when they look at the headers? – resting May 01 '13 at 05:08
  • Over HTTPS, I don't think so. Yes if credentials are passed in the URL such as example.com/1/username/password then they will be visibele. – Abdullah Shoaib May 01 '13 at 18:28
0

You have some choice, none of them special.

  • session based auth system

  • auth with each request

For a replacement of username and password,
you can choose or combine some methods like:

  • auth with digital credential like SSH keys

  • one-time auth like RSA tokens, SMS, PHONE CALL or some bio-methods

gnat
  • 21,442
  • 29
  • 112
  • 288
Ryan Wong
  • 1