Service Principal Not Created when Scopes include ones that Require Admin Consent

Question

I have currently setup an app registration which requires two permissions. One that a user can consent to and a second that requires admin consent. The purpose of this client application is to allow users from other organizations to access the application (to complete an integration into our system).

When testing authentication to the app from a different organization. we found that the service principal for our client app is only created in the other organization's Enterprise Application if the initial request is successful and does not contain any scopes which require admin consent. If any admin-consent scopes or included or the ".default" scope is included then the user is shown the "admin consent required" notification and the service principal is not created. This flow assumes the user is not at admin.

The only workaround I could find was to first authenticate the user with only a scope requiring user-consent (Like "User.Read") and then sending a second auth request to get all the required scopes. This means the user would have to enter their credentials during the first login which is not ideal.

Is there a better way to handle this situation?

Answer 1

That's the expected behavior. If you want to make sure the app is properly provisioned, use the admin consent endpoint (and inform the customer that admin consent is required): https://learn.microsoft.com/en-us/entra/identity-platform/v2-admin-consent#request-the-permissions-from-a-directory-admin