3

We have an Azure resource app whose APIs we want to expose for access by a client app on Azure. The two apps are on different tenants. The users accessing the APIs (Office 365 account holders) are on different tenants.

The whole set up works when we manually provision a service principal on the tenant that is trying to authenticate from the client app against the resource app. By that I mean they are able to log in using their Office 365 account and are shown the consent screen.

If we do not provision a service principal on the AAD tenant of the user trying to authenticate, we get this error:

AADSTS65005 - The app needs access to a service <service> that your 
organization org.onmicrosoft.com has not subscribed to or enabled. Contact 
your IT Admin to review the configuration of your service subscriptions.

It is not feasible for us to provision a service principal on every tenant that is accessing our app (resource app). Is there something we are missing? Are we using the right flow?

user3440125
  • 31
  • 1
  • 2

2 Answers2

3

You can find help for your scenario here: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-devhowto-multi-tenant-overview#understanding-user-and-admin-consent. (Scroll down to Multiple tiers in multiple tenants)

In the case of an API built by an organization other than Microsoft, the developer of the API needs to provide a way for their customers to consent the application into their customers' tenants.

The recommended design is for the 3rd party developer to build the API such that it can also function as a web client to implement sign-up:

  1. Follow the earlier sections to ensure the API implements the multi-tenant application registration/code requirements

  2. In addition to exposing the API's scopes/roles, ensure the registration includes the "Sign in and read user profile" Azure AD permission (provided by default)

  3. Implement a sign-in/sign-up page in the web client, following the admin consent guidance discussed earlier

  4. Once the user consents to the application, the service principal and consent delegation links are created in their tenant, and the native application can get tokens for the API

Basically, all of the parts that your app needs must be present as service principals in the customer's tenant. This is a requirement of AAD.

The only way for that to happen is for an admin to go through consent for the API and app separately, since they are registered in different tenants.

If they were registered in the same tenant, you could use the knownClientApplications property in the manifest to allow consenting to both at the same time.

juunas
  • 54,244
  • 13
  • 113
  • 149
  • Hi Juunas, I am trying to do a very similar thing. Would you be able to help me please? I have my question asked here: https://learn.microsoft.com/en-us/answers/questions/575269/the-app-needs-access-to-a-service-39apiappid39-tha.html – Rafa Ayadi Oct 03 '21 at 16:17
1

In my case, I am exposing my own API and trying to access this API from my other Application (Client Credentials mode), I removed the default permission on both of the app(consuming app and api app) - "Azure Active Directory Graph-> User. Read" since I thought I don't need that but that caused this problem "The app needs access to a service .... that your organization has not subscribed to or enabled. Contact your IT Admin to review the configuration of your service+subscriptions.

I got the clue from the answer of @juunas - point 2. Thx Juunas

Thiru
  • 407
  • 5
  • 7