We are raising a SaaS product that allows businesses to setup and orchestrate selling of a certain class of goods/services. This product has an API in its core and an ecosystem of various apps around it. These include web apps (sites) facing the general public, a web-based CMS and an iOS app for sales staff. Our clients can either use these or build their own apps to talk to our API.
There has been a long debate between us as to how the API should be secured. It does have authentication (both API key/secret for apps and username/password for users) and role/permission based authorization. At the moment, no useful response can be obtained from the API (apart from its version) unless the requester authenticates itself. This includes endpoints returning data that is available to the general public such as the list of items for sale.
The moot point is whether the API should require authentication for what is essentially public data.
The arguments for authentication:
- We can't just keep the API open to whoever wants to call it — even if they can obtain the info anyway by exploiting the public web apps. An open API can be abused or load attacked. Better to control who has access by issuing keys/secrets per client app which will be the first line of defence.
The arguments against authentication:
- There is no point in restricting access to what is made available publicly anyway (via public facing web apps that have key/secret with the "public" role built in them);
- Making authentication required does not add value and only creates unnecessary overhead by requiring the public apps implement auth clients, keep keys/secrets and refresh auth tokens. The apps should only authenticate against the API when a user needs to log in (which some clients simply do not need as they use guest checkout);
- Any concerns of abuse (e.g. exceeding the requests rate limit, load attacks etc.) should be addressed by DDoS protection layer, or the API internally, or both. Authentication is not the right protection from this because a malicious client could obtain app credentials and create troubles to the API anyway, let alone that the rate of auth attempts needs to be limited as well.
Is any of the two positions above horribly wrong or would be laughed at if presented on the market of serious APIs? Is there a right approach here, or are the both approaches sensible in terms of security and could be chosen based on other considerations like convenience/ease to implement?