Search code examples
oauth-2.0jwtopenid

How to properly authorize nested microservice calls


I want to understand the best practice for authorizing nested service calls. The scenario is a client calls some service A to perform some operation. Service A then needs to call another service B on behalf of the user, so it calls service B. Service A then calls another service C. What I want is:

  1. service B to be able to authenticate and authorize the request made by service A
  2. service C to be able to authenticate and authorize the request made by service A
  3. service C to be able to prevent it being called by service B on the user's behalf

Assuming I want to use OpenID Connect tokens, what is the appropriate flow and token content to support the above 3 requirements?


Solution

  • Good question and the answer is related to areas of data and OAuth scopes.

    Access tokens are designed to be passed around between microservices and you should not (by default) need to run new OAuth flows every time APIs call each other, which adds complexity, leading to multiple problems.

    Instead each API should validate the JWT and check scopes and claims that makes sense to that API's area of data.

    A good design is to ensure the following:

    • Tokens used by internet clients are confidential
    • Tokens used by APIs can contain rich claims and be forwarded

    See these 2 articles for some further info:

    On your point 3 there is a privilege there and it depends on the scenario - eg it could be a different subdivision of your company - in which case a different token might make sense.

    Most dynamic authorization should use claims though - there is a Claims Best Practices article following on from the scopes article above.