Ask HN: How do you approach service-to-service authentication? | Hacker News Reader

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

1 pointposix_monad4 comments

Services often need to talk to each-other, but how should they control access?

In an ideal world, callers can prove who they are to services and services only grant access to a minimal set of consumers. There should be low boiler-plate for maintaining service identities and things like token revocation, secret rotation, etc. should be "easy". Bonus points for avoiding vendor lock-in.

What approach do you use for securing service-to-service access?

View on HN

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

Yes, this is a reasonable approach, but how are certificates deployed and managed?

How do we deploy a list of certificates that a service should accept?

How do we do certificate rotation and revocation?

You can use a configuration management tool but you can also just have a bundled archive that is deployed and extracted with SSH. Here's one example: https://community.chef.io/tools/chef-habitat

Reply on news.ycombinator.com