If you're using APIs from third parties, the most typical authentication method is a static key that you stick in the "Authorization" HTTP header.

OAuth flows are not at all common for server-to-server communications.

In my perfect world, I would replace API keys with certificates and use mutual TLS for authentication.

▲

zzo38computer 3 days ago | parent | next [-]

I would also use mutual TLS; in addition to improved security (on both sides), it also allows for many additional possibilities, such as partial delegation of authorization, etc. (If not everyone wants it, it can be made an option rather than mandatory.)

▲

pixelatedindex 3 days ago | parent | prev | next [-]

IME, OAuth flows are pretty common in S2S communication. Usually these tend to be client credential based flows where you request a token exactly like you said (static key in Authorization), rather than authorized grant flows which requires a login action.

▲

cyberax 3 days ago | parent [-]

Yeah, but then there's not that much difference, is there? You can technically move the generation of the access tokens to a separate secure environment, but this drastically increases the complexity and introduces a lot of interesting failure scenarios.

▲

pixelatedindex 3 days ago | parent [-]

I mean… is adding an OAuth layer in 2025 adding that much complexity? If you’re scripting then there’s usually some package native to the language, if you’re using postman you’ll need to generate your authn URL (or do username/passwords for client ID/secret).

If you have sensitive resources they’ll be blocked behind some authz anyway. An exception I’ve seen is access to a sandbox env, those are easily generated at the press of a button.

▲

cyberax 3 days ago | parent [-]

No, I'm just saying that an OAuth layer isn't really adding much benefit when you either use an API key to obtain the refresh token or the refresh token itself becomes a long-term secret, not much better than an API key.

Some way to break out of the "shared secret" model is needed. Mutual TLS is one way that is at least getting some traction.

	▲	JambalayaJimbo 2 days ago \| parent [-]
		Refresh tokens aren’t necessarily long lived, you can force the client to exchange for another refresh token.

▲

nostrebored 3 days ago | parent | prev [-]

In your perfect world, are you primarily the producer or consumer of the API?

I hate mTLS APIs because they often mean I need to change how my services are bundled and deployed. But to your point, if everything were mTLS I wouldn’t care.

	▲	cyberax 3 days ago \| parent [-]
		> In your perfect world, are you primarily the producer or consumer of the API? Both, really. mTLS deployment is the sticking point, but it's slowly getting better. AWS load balancers now support it, they terminate the TLS connection, validate the certificate, and stick it into an HTTP header. Google Cloud Platform and CloudFlare also support it.