16 Implementing service identity

 

This chapter covers

  • Understanding what service identity is
  • Enforcing service-to-service authorization directly within the application code
  • Exploring infrastructure-level approaches to delegate identity enforcement
  • Choosing between application and infrastructure-level strategies

If you’ve ever tried to debug why one service is refusing to talk to another, only to discover it’s because the caller was impersonating someone else, you already understand why service identity matters. In a world where machines talk to machines more than people talk to people, knowing who’s calling isn’t just a nice-to-have.

The days when we could trust everything inside the perimeter are gone. The perimeter is gone. The services are multiplying a lot, and every call in your system should be treated with suspicion. Service identity is to bring back order in the chaos. It’s the badge each service wears to say, “Yes, it’s really me, and here’s the cryptographic proof.”

16.1 What service identity is

Service identity is the mechanism that allows systems to determine who a service (app) is. Just like user identity helps us determine who a human is, service identity does that for apps in a system. Without a reliable way to identify services, authorization, auditing, and secure communication become guesswork.

16.1.1 Exercises

16.2 Implementing service authorization at the application level

16.2.1 Using the OAuth2 client credentials grant type

16.2.2 Using API Keys

16.2.3 Using custom authorization logic

16.2.4 Exercises

16.3 Implementing service authorization at the infra-level

16.3.1 Exercises

16.4 Answers to exercises

16.5 Summary