New Azure AD application doesn't work until up

Question

I have created a new application in Azure AD using the AAD Graph API. (code)

Unfortunately it doesn't let my client access the requested resources until I have been to the application's configuration page in the Azure management portal and made a cosmetic change, and then saved it. After removing the change and saving again, it still works. The application manifest files before the change + change back steps and after them are completely identical (as in diff.exe says they are the same).

When comparing the JWT tokens returned when the application authenticates, it shows that the post-change access token includes the "roles" section. The entire "roles" section is not present in the access token returned before saving the application in the management portal.

So it seems the Azure management portal does "something" to the application when saving changes. The question is what it is, and can I do the same using the AAD graph API?

Answer 1

Apart from RasmusW's answer above, there a few more things that you might have to do depending on what you are trying to achieve.

1. If you want delegated permissions to work, you also need to add an Oauth2PermissionGrant into Oauth2PermissionGrants collection at the root level. This should have clientId of caller's SPN ObjectId, ResourceId of called SPN's object Id. The Scope value of the Oauth2PermissionGrant is key. It should have space separated values. Each value here comes from the 'Value' property of the Oauth2Permission object on the target SPN.
2. Additionally you may also need to be in appropriate DirectoryRole e.g. Directory Readers.

Answer 2

There were several issues. Some bugs in the backend on Azure, which have now been fixed, and also some missing calls to the API which I didn't know were necessary. Thanks to some very helpful people at MS Support, we were able to get it to work.

When creating an application, you need to do the following:

1. Create an application object.
2. Setup the RequiredResourceAccess for the application, ie. which permissions the appliation has to Azure Graph API etc. This is what is configured in the portal's "permissions to other applications" settings. You can get the necessary GUIDs by configuring the permissions manually, and then looking in the application's AAD manifest file.
3. Create a service principal for the application.
4. Add AppRoleAssignments to the service principal.

The final part is what I was missing before. Even though you have configured RequiredResourceAccess on the application object, the service principal still needs the AppRoleAssignments to actually have permission to access the resources.

When creating the AppRoleAssignments it is a little bit tricky to figure out which PrincipalId to assign, since that is the AAD ObjectId of the service principal for the other resource.

Here is a snippet for adding the AppRoleAssignment to access the Azure AD Graph API. client is an ActiveDirectoryClient instance, and sp is the ServicePrincipal for my application:

// find the azure ad service principal
var aadsp =
     client.ServicePrincipals.Where(csp => csp.AppId == "00000002-0000-0000-c000-000000000000")
     .ExecuteSingleAsync().Result;

// create the app role assignment
var azureDirectoryReadAssignment = new AppRoleAssignment
{
    PrincipalType = "ServicePrincipal",
    PrincipalId = Guid.Parse(sp.ObjectId), //
    Id = Guid.Parse("5778995a-e1bf-45b8-affa-663a9f3f4d04"), // id for Directory.Read
    // azure active directory resource ID
    ResourceId = Guid.Parse(aadsp.ObjectId) // azure active directory resource ID
};
// add it to the service principal
sp.AppRoleAssignments.Add(azureDirectoryReadAssignment);
// update the service principal in AAD
await sp.UpdateAsync();

My experience is that you need to wait a short time, maybe 2-3 minutes, before the newly created objects are valid in AAD, and then you can authenticate using the new application.