CODEWITHSUNDEEP
apiidentityserver3openid-connectoauth-2.0
danijels
danijels

Reputation: 5291

Design considerations for OAuth2 secured APIs

I'll give a scenario as a premise for my question:

At some point, developers decide it is time to refactor invoicing out of customers API into a new Invoices API which now requires the scope "invoices". For the Customers API to return expected results to the CRM client app, it will now have to call on Invoices API and get that part of information out to the calling app. So passing on the token won't work because of the new scope requirement.

What is the best approach for the Customers API to keep returning the expected results to the CRM app without breaking change of requiring the CRM client app to add new scopes?

One approach would be for Customers API to authenticate as client credentials trusted subsystem but how will then Invoices API know about the initiating user? The idea here is to separate the functionality without breaking it for existing client applications.

Upvotes: 0

Views: 90

Answers (1)

ranieuwe
ranieuwe

Reputation: 2296

Using a multi-hop or act-as granting system could help you. If I understood correctly your scenario is: Client -> API1 -> API2

If you want each layer to have his own scope (you do according to your description) then act-as tokens will help you.

A very good summary of this is available in IdentityServer samples issue #182. You'll find an example of that scenario in their Git repository.

Upvotes: 2

Related Questions