[baddox]

I’d say it depends a lot.

If your API just serves public non-user-specific data, a simple API key might be okay. The obvious downside of this method is that a user leaking their client API key is a big problem, especially if your users are likely to distribute code that makes requests (e.g. a mobile app that makes requests to your API).

The state of the art is probably still OAuth, where clients regularly request session keys. This means a leaked key probably won’t cause problems for very long. The obvious downside of this is complexity, but that can be mitigated by releasing client libraries that smooth over the process.

[fyfy18]

One thing to be aware of with OAuth 2.0 is Refresh Tokens. If the spec is followed, the Refresh Tokens are long-lived and never expire (the spec makes a suggestion that you revoke used tokens, but it's not required), so if they are leaked you are in for a bad time.

There's an RFC that goes into some of the security considerations of OAuth 2.0, that should be required reading if you implement it (even from a pre-built library): https://tools.ietf.org/html/rfc6819

[Fradow]

If the Refresh Tokens are leaked, you revoke them and the user has to re-authenticate.

It's crucial that clients are able to respond to their refresh tokens being revoked.

The good thing is that it is a standard workflow, contrary to API key being revoked, which is generally not handled (most people hard-code API key in their client).

[imtringued]

What's the appeal of tokens that never expire? You cannot delete the revokations after the token has expired.

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