Azure AD App Creation, mind the new portal!

Hi,

You might have noticed but in the recently added Azure AD section of the Azure Portal (portal.azure.com), the App creation experience seems to have changed compared to doing the same operation from the old portal. From the old portal, when one create an app of type Web as a global admin, the following sequence occurs:

  • The app is created
  • A service principal is created
  • an oauth2PermissionGrant is created

as an example, if I create the app named

  • oldportal

, the following piece of information (shortened) will be found in Azure AD:

The app itself:


{
"odata.type": "Microsoft.DirectoryServices.Application",
"objectType": "Application",
"objectId": "ad3240a5-3dca-4244-ab85-a70388dc65ed",
"deletionTimestamp": null,
"appId": "64fbb87d-81db-4c20-867a-83baf4531675",
...
"oauth2Permissions": [
{
"adminConsentDescription": "Allow the application to access oldportal on behalf of the signed-in user.",
"adminConsentDisplayName": "Access oldportal",
"id": "e3f8b5d3-8315-4188-a9d1-a991314542cc",
"isEnabled": true,
"type": "User",
"userConsentDescription": "Allow the application to access oldportal on your behalf.",
"userConsentDisplayName": "Access oldportal",
"value": "user_impersonation"
}
],
...
},

its corresponding servicePrincipal

{
"odata.type": "Microsoft.DirectoryServices.ServicePrincipal",
"objectType": "ServicePrincipal",
"objectId": "a30b3023-fcff-4b56-9eb3-b446c10aff23",
"deletionTimestamp": null,
"accountEnabled": true,
"appDisplayName": "oldportal",
"appId": "64fbb87d-81db-4c20-867a-83baf4531675",
...
"oauth2Permissions": [
{
"adminConsentDescription": "Allow the application to access oldportal on behalf of the signed-in user.",
"adminConsentDisplayName": "Access oldportal",
"id": "e3f8b5d3-8315-4188-a9d1-a991314542cc",
"isEnabled": true,
"type": "User",
"userConsentDescription": "Allow the application to access oldportal on your behalf.",
"userConsentDisplayName": "Access oldportal",
"value": "user_impersonation"
}
],
...
},

and more importantly, the oaut2PermissionGrant:

{
"clientId": "a30b3023-fcff-4b56-9eb3-b446c10aff23",
"consentType": "AllPrincipals",
"expiryTime": "2017-04-08T01:22:48.3417564",
"objectId": "IzALo__8Vkues7RGwQr_I_fc8LhgZ4pNrMeRv3utNbA",
"principalId": null,
"resourceId": "b8f0dcf7-6760-4d8a-acc7-91bf7bad35b0",
"scope": "User.Read",
"startTime": "0001-01-01T00:00:00"
}

Why is the latter the most important step? Simply because it drives the consent experience. Thanks to this step, your users don’t have to consent the app to use delgetate permissions when consuming a resource on your behalf. In this example, the resourceId is the id of the User.Read delegate permission of Azure Active Directory.
When creating the same App from the new portal, there is no such AllPrincipals consent created for you, meaning that all your users will be prompted to authorize the App to use its delegate permissions against the target resource(s). You can drive the consent experience programmatically or via PowerShell but this change is a huge one and is not documented for the time being (at least, I couldn’t find a trace and justification).. If you want to consent for all your users, you’ll have to implement the admin consent manually the following way:

  • Grab the Authorization endpoint of your app from the portal
  • Add to this URL, the parameters clientid= and prompt=admin_consent
  • Logged in as a Global Admin, accept the consent, this will create a oaut2PermissionGrant per requiredResource for all users (AllPrincipals)

I don’t know whether this is a bug/limitation or a feature from the new portal but long story short : pay attention which portal you use when creating an Azure AD App as what is done behind the scenes is completely different!

Happy Coding

Advertisements

About Stephane Eyskens

Office 365, Azure PaaS and SharePoint platform expert
This entry was posted in Azure Active Directory and tagged . Bookmark the permalink.

One Response to Azure AD App Creation, mind the new portal!

  1. Pingback: Alternative to Azure AD Premium’s Azure AD Privileged Identity Management (PIM) | Stéphane Eyskens, Office 365 and Azure PaaS Architect

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s