Ask HN: How do you approach service-to-service authentication?

If both services are created and managed by you then you have these possibilities:

- API Key (quick & easy with reasonable security)

- OIDC (OAuth) (client now "pretends" to be a user, or acts on behalf of a user)

- Client Key Authentication (can be quick & easy if you have infrastructure in place)

All three approaches suffer from a common problem: secrets management. When using an API Key, it's the API Key itself that's the secret needing to be managed. When using OIDC the password is the secret needing to be managed. When using Client Key Authentication the client key is the secret needing to be managed.

Generally-speaking, you don't want to put your secret into your codebase and check it into git (or whatever source control system you're using).

How you manage these secrets depends on what platform you're on, and the languages and frameworks you're using or even whether your organization has setup a secrets vault. There's a dizzying number of options for managing secrets. Regardless of which route you go with managing secrets; these are the three main strategies you can use for securing your APIs.

The standard solution is to use digital keys and signatures. There is no need to reinvent the wheel here, just use the standard cryptographic constructions to verify that the requests are from trusted sources, e.g. https://medium.com/@georgwiese/hash-based-digital-signatures...