If Stripe can get away with just public and secret key pair, there is a big chance it’s enough for you as well.
It essentially takes a resource behind OAuth, strips OAuth from it and exposes it with Basic Access Authentication. I'm using it to let clients that don't support OAuth access services that force it.
So I implement separate IAM flows for my website, app and third party api access?
Or... Make use of OAuth to standardize it, using code auth+pkce for web/app, and client credentials (not user/pass, this is client id + secret, scoped to permissions you want) for third party APIs.
The scoping is so useful, api keys tend to ignore that, so platforms like digital ocean only give you an all or nothing key, meaning I can't plumb an acme client in to do DNS challenges, without also letting it spool up a VM...
1. Just because a large company does something does not make that thing safe or correct—especially when your risk appetite and attack surfaces are not the same.
2. OAuth has it’s place, but it alone isn’t enough to secure an API. With or without OAuth most applications need well defined identity management, authorization mechanisms (distinct from authentication mechanisms), and all the other pesky implementation details one needs to consider when there is a desire to guarantee the authenticity, integrity, and/or confidentiality of requests to and from said application.
Even pure server-to-server applications with "no user involved" are starting to use OAuth authentication which I don't quite understand.
https://www.verygoodsecurity.com/docs/payment-optimization/a...
Sending your service credentials to every service is arguably less secure since they can have lesser security or log unwanted things.