App registrations set up for Microsoft AppSource monetization

Question

Scenario

Our company is developing a full stack solution that integrates our SaaS product with Microsoft marketplaces (AppSource & Azure Marketplace). It has similar infrastructure to the SaaS Monetization Sample, with two Azure app registrations as follows -

Back end/API app reg (Multi tenant)

• Exposes API scopes in order to allow access from front end
• Retrieves publisher access token for SaaS Fulfilment API
• Expect no corresponding enterprise application in external tenant

Front end/Client app reg (Multi tenant)

• Allows clients to approve required API permissions, including backend scopes
• Allows MSAL authentication
• Expect corresponding enterprise application in external tenant

---

Expected multi tenant behaviour

1. An external user signs into the front end web portal for the first time within tenant
2. The user is redirected to sign in page, prompted to select their account. https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?client_id={frontend-app-id}&scope=api://{backend-app-id}/{backend-scope} {other-permissions}&...

Sample sign in page

3. Once user has selected their account, they are prompted to grant admin approval for permissions defined in front end app registration.

Sample permission request page

4. Upon approval, the front end enterprise application is created in the external client tenant, including permission that are requested in front end app registration "API Permission" page including the back end scopes.

---

Problem - current external tenant behaviour

1. User visits front end (same as step 1 above)
2. The user is redirected to the log in page as expected
3. The user is stuck in a self-redirect loop of the following pages, no enterprise application is created at any point.
   • Log in page (https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?client_id={frontend-app-id}&scope=api://{backend-app-id}/{backend-scope} {other-permissions}&...)
   • Log in "reprocess" page (https://login.microsoftonline.com/common/reprocess?ctx=...)
   • Front end url (Loads root url /, attempts to call a backend API endpoint but fails with 401, no authorization header)
   • Log in page ... (repeat above steps infinitely)

At no point above is an enterprise application created within the tenant.

No error on console or network log aside from the 401 in frontend portal.

When inspecting the user sign-in logs in Entra, this is the error we got -

AADSTS500011: The resource principal named api://{backend-app-id} was not found in the tenant named {external-tenant-id}. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant.

Judging by the timestamp and number of attempts, this seems to be thrown whenever the user attempt access to front end portal.

---

Configuration Details

App Registrations

We have enabled bundled consent by adding frontend app reg as Authorized client applications in "Expose an API" and knownClientApplications in Manifest.

The scope that is exposed by backend app reg is then added to the frontend API permission and granted admin consent.

Frontend MSAL

Authority is set to common.

Redirect URL is registered in frontend app reg.

Using Authorization Code Flow with PKCE.

---

Additional details

Our company has actually published a live AppSource offer with the app reg setup deployed from the sample project mentioned at the start, and the production instance has been working with customers.

We have confirmed that only frontend enterprise application is created in a working customer environment, and the API call made in portal works as intended.

However when we deployed a new instance of the solution as part of investigation to this issue, we found that the new instance is experiencing the exact error as follows -

AADSTS500011: The resource principal named api://{backend-app-id} was not found in the tenant named {external-tenant-id}. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant.

I have confirmed that the new app registrations has been set up identical to production version and follows the documented set up for bundled consent. Plus it is deployed by the same PS script that deployed prod.

This indicates to me that the problem might not be the configuration of the app regs, but something during the provision of the enterprise applications, however I am not sure what could it be.

---

My questions are:

• What could be the possible causes for the infinite self redirect? And what would be the correct configuration?
• What exact configuration allows the back end scopes to be approved? Does adding the back end exposed scope to front end app reg API permission suffice?
• Does my general understanding of the app registration configuration and intended log in behaviour seem correct? e.g. is the backend supposed to be single tenant, and no enterprise should be created

Many thanks!

Answer 1

Hello Matthew Wong,

I tried to test the same in my environment like below. Please verify the configurations:

Created an MyBackendApi and MyFrontendApi by selecting "Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)" to support multi-tenant users and Microsoft personal account users.

In MyBackendApi , exposed an API, added scope and add Authorized client applications that is add MyFrontendApi ClientID:

In MyFrontendApi, configure the redirect URI:

Also, in MyFrontendApi, configure API permissions and make sure to grant admin consent:

I used the below endpoint to authorize users.

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?

&client_id=FrontEndClientID

&response_type=code

&redirect_uri=https://jwt.ms

&response_mode=query

&scope=api://BackEndClientID/access_as_user openid offline_access

&state=12345

&code_challenge=xxx

&code_challenge_method=S256

Signed in with another tenant user:

Another tenant user signed in successfully:

Hope this helps!

---

If this answers your query, do click Accept Answer and Yes for was this answer helpful, which may help members with similar questions.

If you have any other questions or are still experiencing issues, feel free to ask in the "comments" section, and I'd be happy to help.