Architecture for client / server authentication / api-key

RESTful should be stateless.

I think you should always pass the API-key. Just make sure that it is really really secret.

Some people likes to create session on API-endpoint. I personally don’t.

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).

Why would a Cookie header value be more performant than say an Authorization header value or a request param?

You also open yourself up to many potential security holes depending on how your HTTP client is used elsewhere within the system.

This Wikipedia entry has a good rundown of the more common gotchas. I’d stick with a generated API token managed outside of a cookie myself.

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).