1

I have an Api in Azure that 3rd parties should integrate with. Each client app (app registration) represents a company and should only access that company's data, the same way a user would only access it's company's data. My problem is that there's no user present when getting the access token through client credentials.

My initial idea was to look at the "oid", "sub" or "azp" claim and map that to a "service account" kind of user with access to a specific company. But when I need to access downstream Api's, those claims are lost.

I tried using the on-behalf-of flow, using the GetForAppAsync method in the Microsoft.Identity.Abstractions namespace, hoping that something would pass through pointing to the original caller but I've not found anything yet.

I'm thinking that I might approach this the wrong way, since no information I've found so far points to this being a common solution.

This comment on a feature request seams to be exactly what I need but the feature request is closed and there's another comment saying it's not available to 3rd parties. https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/2130#issuecomment-719094803

This issue is also also the same but was solved by creating a dummy user and getting a token with ROPC, which is not recommended by Microsoft. https://github.com/MicrosoftDocs/azure-docs/issues/53334

Does anyone have any input on similar issues? How would you solve identifying a client application so that you can restrict data access?

Erik Särner
  • 1,037
  • 6
  • 8

1 Answers1

0

OBO for service principals is not supported. You have to keep using client credentials for calls between your API to any downstream API. You can pass any company specific identifiers as part of your downstream API request. Eg. https://downstreamapi/v1/companydata/1. You would enforce per company authorization rules in your API. Eg. client1 can request companydata for company 1 and 2 but not 3 or 4, etc.

AlfredoRevilla-MSFT
  • 3,171
  • 1
  • 12
  • 18
  • Thanks, that's unfortunate. We lose a bit of the niceties of authorizing the roles when we need to pull information out of the token and passing it on the side to a downstream api. – Erik Särner Apr 11 '23 at 08:15