Public API security: authentication vs. rate limiting etc

Is any of the two positions above horribly wrong or would be laughed at if presented on the market of serious APIs?

Considering the data that is returned from the API is public information I do not really see why authentication is required, assuming your statement "The moot point is whether the API should require authentication for what is essentially public data." is correct. (The essentially part in that sentence makes me wonder though)

The statement:

'We can't just keep the API open to whoever wants to call it'

is incomplete as it does not describe why. Why can't it be open to anyone? What are you afraid of?

Rate limiting should be implemented obviously and the statement that it should be addressed by the DDoS protection layer in insufficient because you should use the defense in depth approach.

This means that you embed protection in every possible layer (within reason).

An open API can be abused or load attacked.

An example would be to configure the web server that is serving the API with rate limiting as well and not solely rely on the DDoS protection.

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?

Yes, they both are sensible and a cost / benefit approach can be applied here. How much are you willing to invest in order to protect public data?

TL;DR: Rate limiting is your only option.

As you are going to have mobile apps and websites as API clients, you will be sending the API key/secret to client devices - including ones potentially controlled by an attacker. You can never rely on the confidentiality of these keys for security decisions. They are just too easily compromised. Sure you can disable and re-issue a compromised key/secret, but given your architecture you will just have to send the new key/secret to the clients where they'll get compromised again. Basically, you're signing up for an endless game of whack-a-mole.

Even if a key/secret isn't compromised, being that you're going to allow 3rd-party clients, you must protect against non-malicious clients that request too much data, whether due to poor design or bugs. So you absolutely need rate-limiting in place - even for authenticated clients.

In short, the authentication that you are proposing provides little if any security, and even with that authentication, you need rate limiting in place. While your DoS protection has to be based on the rate limiting, I would still use the API key/secret to assist in monitoring and debugging.

You are missing one important point: It is way easier to exploit a public API. It's relatively easy for a sophisticated attacker to work around rate-limiting. If there is any kind of vulnerability, like SQLi or XXE, it will be detected and abused pretty fast by automated tools, and the abuse will not be traceable to a specific user, if there aren't any.