Best Practice for Managing Scopes in Microservices Architecture: Minimizing Scope Creep, ensuring audit trails

Help
,
1

Hey there,

I’m working with an app that needs to peek at orders, so it’s rocking an orders:read scope. Now, the twist is, to fulfill the order reading request, the order service gotta chat with another microservice about customers, needing a customers:read scope.

Here’s the crossroads I’m at:

  • Should I arm the app calling the order service with both orders:read and customers:read scopes and just forward the token along, OR
  • Just hand orders:read to the app, and let the order service itself snag a Machine-to-Machine (M2M) token with customers:read when it needs to, OR
  • Maybe there’s a clever third path I haven’t thought about?

The thing about option one that bugs me:

  • It feels like I’m giving the app more power than it needs, letting it directly access customer info, which isn’t the goal.
  • If the order service evolves or the scopes it needs change, I’d have to update permissions for every app that talks to it, which sounds like a maintenance headache.

And with option two, my head-scratcher is:

  • How do I keep the original token’s context when the order service uses an M2M token to reach out to the customer service? I don’t want to spawn a new M2M token every single time a different app makes a call to the order service.

Would love to hear your thoughts on this and if there’s a smoother way to handle it. Thanks a bunch!