[mattmanser]

Can you explain why only "public non-user-specific data" is suitable for basic auth over HTTPS?

For most SasS products, basic auth or an API key is going to be fine. In fact, a ton of SasS vendors do exactly that. It's also totally fine for, say, an enterprise API used by a partner or clients.

Oauth is a cluster-fuck of terribleness, a nightmare for you to work with and a nightmare for your consumers to use. If you do it, you will need to have excellent support docs and examples or have to hand-hold external devs to get it working. The only time I might start considering OAuth is if you want other apps to be granted permissions to use the API on behalf of the user, where you want some granularity of which parts they can access.

I'm not saying OAuth doesn't have a use, but it's awful, overcomplicated implementation means it's a huge time-sink compared to basic auth over HTTPS and I certainly wouldn't recommend it without a very good reason.

[brabel]

The OAuth use case you mention is spot on but with OAuth clients available in every language remotely popular I don't agree it's complicated. And I think that even if you don't have a strong user case for OAuth you will sooner or later. Better to go with the standard practice for user centric APIs instead of using ad hoc solutions.

[mattmanser]

It is vastly more complicated, you have to do all sorts of redirecting and capturing with OAuth that you simply don't have to do with basic authentication.

And woe betide you if you're not using a framework that vaguely plugs + plays oauth.

Couple that with all the shennanigans involved when trying to get two servers to talk to each other without a human involved in oauth.