Authenticating service-to-service calls

Authentication and authorization Senior Python 3.13+ PostgreSQL 17+ Reviewed By Best Latest Apps

Pick the fix

The billing service accepts any request with header X-Service: orders. Fix?

Options
Hint 1 of 1

Can another caller set that header?

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A Require mTLS or a signed token proving the caller is the orders service, and check its permissions

Correct. Identity is verified, not asserted.

A header is something the caller says about itself; any client can set it. mTLS or a signed token is proof checked with cryptography, and permissions then limit what that identity may do.

Why not the others?
  • B Rename the header to something secret. Still just a claim anyone can send.
  • C Allow only requests from the private network. Any compromised workload there can call it.
  • D Log the header. Logging isn't authentication.

30-second answer

Don't trust the network. Give each service an identity and verify it on every call: mutual TLS with short-lived certificates (often issued automatically by a service mesh or SPIFFE), or signed tokens from an internal issuer using the OAuth client credentials flow with a narrow audience. The receiving service checks the caller's identity and what it's allowed to do; a user's identity, if needed, travels as a separate verified token.

Practise saying it · 30 s. No recording, just a timer

Service identity.

Say your answer out loud, then check which of these points you covered:

  • No implicit network trust
  • mTLS with short certs
  • Client credentials tokens
  • Least privilege per call

Deep dive

Cloud workload identity (IAM roles for service accounts) avoids long-lived secrets.

Rotate credentials automatically; certificates of hours or days, not years.

Authorize per operation: service A may read orders, not delete them.

Log the calling identity with every request.

Common mistakes

  • Trusting any request from inside the VPC.
  • One shared secret for every service.
  • Forwarding user headers that any internal caller could forge.

Senior take & follow-ups

Zero trust inside, workload identity via mTLS or client-credentials tokens, least privilege.

Follow-up questions

Think of your answer first, then open the hint.

  1. mTLS or tokens?

    Show hint

    mTLS proves the workload at the connection; tokens carry claims and scopes. Many systems use both.

  2. How does a user's identity travel?

    Show hint

    A signed token from the edge, verified by each service.

Related questions

Suggest a fix if something here is wrong or out of date.