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.
2
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.
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
8
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