A friend is creating a private API Gateway / Service, written in GO.
I am creating an Elixir Client, a simple web Phoenix web-app that will allow a few users to login and consume these API services.
We want to limit access to this private API to just our Elixir client for now, in as secure a way as possible.
Our thinking so far is:
*Use an API-key to limit access to only the Elixir Client. The intent is to prevent other external client-apps from attempting to use the API (for now).
*When a user logs in successfully, the API passes back a token or starts a session.
*Onwards, we will use a token or session for authentication for this user.
My question: after a successful login, is it superfluous to continue passing the API-key? Or, is it simply necessary by design?
If it is actually an API, cookie-less, then always pass in the API key, always. If you have cookies then use the cookie to store it instead after a login. Most APIās donāt support cookies though and always passing in the key is generally done.
For note, always passing the āsameā key is generally a security issue. Generally you get an initial key, pass it in on the first request of whatever you need to do, and you get a new single-use key back, and repeat with that one. That tends to be more irritating to use though so most donāt actually do that as it requires client-local storage too.
Thanks for that. Weāre still in research mode and every bit helps!
Iām curious about the definition of a āpure APIā. We intend that the main job of the API will be to return JSON data.
It does appear most APIs do not support cookies. Iām puzzled as to whether this is just to make things more convenient for the API architecture, or whether there is a strong anti-cookies philosophy involved.
Is it simply just more performant/convenient to use tokens (opaque or JWT) to protect API endpoints?
Eh the definition is fuzzy, but I generally use it in such a way that each request is entirely stateless.
I think itās just because adding cookies complicates āsomeā client libraries (not so much anymore, but back in the day it definitely did).
Not at all, if anything cookies are more performant. I really think itās just because so many older http client libraries didnāt have cookie support (but as stated, nowadays thatās not really an issue anymore, so its an old holdover).
A cookie would be about the same as an authorization header for that, but as a request param not as much (phoenix has to parse those out in a different way, plus you donāt want cacheārs to cache secure parameters). Passing it in via a header is fine though, via a parameter or javascript encoding or so is slower (but not enough to really matter).
As for the issues, just keep doing the same things, invalidate it on every request and issue a new one (which is much easier for the client to handle then if itās a cookie as then they donāt need to do anything special beyond cookie things).
