1

I have a DotNet Core WebAPI living in my own Azure AD tenant. This WebAPI is secured via AzureAD V2 (!) BearerToken authentication. This API is called by an Angular SPA authenticated via OIDC (AzureAD v2) using @azure/msal-angular following the tutorial at https://learn.microsoft.com/en-us/graph/tutorials/angular. Everything works fine with users from my own tenant. But when logging in with a user from another tenant I get the following error:

"AADSTS650052: The app needs access to a service
(\\\"https://mytenant.de/AngularDemoApi2\\\") that your organization
\\\"myorganization.de\\\" has not subscribed to or enabled. Contact your 
IT Admin to review the configuration of your service 
subscriptions.\r\nTrace ID: 9597578e-7e48-49b2-85be--b5a1ee14300\r\n
Correlation ID: 30d4caf2-e3ca-4d7d-84b5-564d428e4e69\r\n
Timestamp: 2019-06-13 15:40:46Z|invalid_client"

I have tried to following some examples to make the WebApplication and the WebAPI multitenant but all the examples seem to be outdated and/or not relevant for V2 of Azure AD. WebApplication and WebAPI have set

"signInAudience": "AzureADandPersonalMicrosoftAccount"

in Manifest. WebAPI has App Uri in the form of

https://mytenant.de/AngularDemoApi2"

I guess that I need to give users from other tenants somehow permission to access the WebAPI in my tenant but I don't know how.

Edit: When I choose to expose the API directly from the app registration of the SPA it works like a charm. But this approach does not seem to be right because each exposed API would have the same audience ("aud" claim, the same audience as the SPA application). In my example above I have a separate app registration - one for the SPA and one for the API. This way each API would have it's own audience and it will also be mentioned in the consent screen.

May be someone could explain how to configure it correctly?

Dirk Schiffner
  • 11
  • 3

1 Answers1

0

I had the same problem, and for me the solution was to add the client as an "authorized client application" to the WebAPI's app registration in the Azure portal.

This will show up in the service app's manifest as a section in the following form, where appId is the application id of the client app, and permissionIds contains the ids of the scopes requested by the client app, which can be read from the "oauth2Permissions" section of the manifest:

"preAuthorizedApplications": [
    {
        "appId": "523ca2d4-680b-4ef4-8a8c-3f3486693cf7",
        "permissionIds": [
            "35e5e006-83c5-4f37-a3bf-c048ee8c8600"
        ]
    }
],

In your case, you might have to first register the Angular SPA as a client application in order to get a client id. This is described in this quickstart.

Björn Jarisch
  • 311
  • 4
  • 8