How Nested App Authentication can be setup in azure.

[glr0221]

Hello team microsoft,

Thank you very much for always responding to my inquiries. They have been truly helpful.

For today, I would like to ask your help in confirming a process flow I have in mind.

A. An addin developer (company A) creates an addin which uses NAA-SSO. A.1 In his addin code, he does not specify the scopes his application needs. A.2 Next he creates an SPA registration in Entra/Azure. A.3 In the Azure registration, the dev adds all the needed permissions/scopes by his addin.

B. A customer company (Company B) wants to install the addin created by company A. B.1 Company B does not want any popups for his end users. B.2. Company B then installs (centralized deployment) the addin manifest.

Questions :
What does company B admin do to add Company A's addin in their list of registered addins in Azure? What does company B admin do to consent to all the addin's listed permissions in Azure? Is it all right for company A to not declare the scope/permissions in his code since it is already listed in the app's permission list?

I hope this flow makes sense to you.

Thank you.

[ElizabethSamuel-MSFT]

@glr0221 Thanks for your questions. Tagging @mattgeim to take a look.

Thanks.

[mattgeim]

There should be no issues with this - there are a few paths, which both end up being the same (admin consent):

1) The developer can construct an admin-consent URL and share it - more docs here: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/grant-admin-consent?pivots=portal#construct-the-url-for-granting-tenant-wide-admin-consent

2) If the add-in is being deployed by the admin, which in your example above is the case, there is a link that will be provided in that experience that goes to the admin consent experience.

In both 1 and 2, the consent would be done using the .default scope, which uses the scopes listed in the app registration on Entra. You can read more about that here: https://learn.microsoft.com/en-us/entra/identity-platform/scopes-oidc#the-default-scope

Feel free to close this issue if this answers your question, @glr0221 - or let us know how we can help clarify / additional details if we did not.

Thanks!

[glr0221]

Thank you @mattgeim . Looks like option 1 is the route for me. I still need to test then get back to you as soon as possible. Thank you again.

[glr0221]

@mattgeim in a totally different subject, is it possible, that the application ID be abused? For example, consider the following case :

1. Company A creates an addin and then registers default permissions for the app in Azure.
2. Company B installs the addin and then consents to the default permissions for everyone in his or her organization.
3. Malicious Company C then creates a different addin, uses the msal-browser library and uses the entra ID registered by Company A.
4. Company D then installs Company C's malicious addin, thinking it is Company's A's addin. They consent to the permissions because the permission splash screen shows the name of Company A's addin.

Is the above flow possible? How does the entra/azure id registration link up with the actual addin it is supposed to work with?

Thank you very much.

[mattgeim]

Company C doesn't control the registration, and Company A defined the redirect URIs, so redirection of auth requests containing the response will go to where company A defined - company A webservices hosting the add-in. The Entra ID docs and information would be the best resource for learning more about that part of the platform. I've linked to an Entra ID article that may be of help about security with many best practices: https://learn.microsoft.com/en-us/entra/identity-platform/security-best-practices-for-app-registration

I'm going to close this issue, but feel free to re-open if needed.