How do you authorize a AzureAd native client app in tenant other then the owner of the app?

1
votes

I created a AzureAD native client app which uses ADAL with UserCredentials (It will eventually be a headless multi-tenant windows service which is why I'm trying to use user credentials instead of other flows) to authenticate to AzureAD. This app communicates with a multi-tenant WebApi. I can run the app fine when using an active directory user which owns the app or even with user from a different directory within the same tenant. However, if I use a user from a completely different tenant I get the following:

Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException occurred Message: Exception thrown: 'Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException' in Microsoft.IdentityModel.Clients.ActiveDirectory.dll Additional information: AADSTS65001: No permission to access user information is configured for '******-****-****-****-************' application, or it is expired or revoked.

The client ID returned is the same ID that was assigned to the native client app when it was registered in same tenant as the WebApi.

It sounds like this tenant needs explicit permission to access the native client app. For now this is just a test app, so it's not in the gallery. I can't see a way to add a native client app created by one tenant to a different tenant. At least not without adding it to the gallery if that's even possible.

  1. Are native client app's supported in the Gallery?
  2. Is there a way to register a native client app in a tenant other then owner of app without publishing the app to the gallery?
1
c#azure-active-directoryadal

1 Answers

0
votes

As of today, native apps aren't supported in the gallery - but it would not make a difference in your scenario. Native apps need to prompt a user for consent in order to be used against a tenant other than the one in which the app was originally created. That excludes the use of UserCredential. Furthermore, given that consent for native apps is recorded in the refresh token you receive the first time, you'll be able to run the app without showing any prompt for 90 days max. Once the refresh token expires, the user will need to be prompted again. Today, the only way of avoiding the flow described above is to recreate in the target tenant the same setup that the application gets in its original creation tenant, that is to say creation of a serviceprincipal and associated entries in a permission table. Those operations can only be performed by an administrator of the target tenant. I believe the directory has in the pipeline some improvements that will make this much easier, but I have no dats or details to share ATM. Sorry!